Minutes prepared by Dean Willis, based mostly on notes by Tom Taylor, without whom we would cease to report.
SIP Working Group met at IETF 51 for two long sessions, a total of 5 hours of meeting time. The revised agenda was completed, with the exception that several of the Rosenberg drafts listed in conjunction with alternative views were not discussed in detail. Instead, Jonathan addressed only the significant differences between his approach and the alternative presented.
The WG also scheduled three adhoc after-hours sessions: 1) Security, 2) Privacy and Outbound Services from Non-Adjacent Proxies, and 3) Firewall Traversal. A fourth adhoc on call Control was proposed by Rohan Mahy, but the proposal was withdrawn before the meeting.
Slides are posted at: http://www.softarmor.com/sipwg/meets/ietf51/slides/
Work Plan status
-----------------
Approximately half of the extant SIP drafts have been tentatively moved to SIPPING. The managed Last Call process is now starting to flow, and it looks like we'll be able to work through the backlog. We have a near-term requirement to reset several milestones, which will be executed on-list.
REFER Method
-----------------
This is part of the "call control" work, which addresses call transfers and thrid-part all control. The existing draft draft-ietf-sip-refer-00.txt was recently split off from the "transfer" draft. Open issues: 1) The "referred by" information is similar to the Remote-Party-ID of the Privacy work. Can these two share a general mechanism? 2) The draft defines a crude integrity mechanism for referred-by, but this should use a general-purpose header integrity mechanism. Consensus to advance draft by deleting integrity mechanism and referring to SIP Security work. 3) The MIME-type of the REFER body remains unresolved, and a number of security questions were raised with various proposals.
Replaces Header
-----------------
This header indicates which call leg the call leg mentioned in a REFER is to replace. This work is fairly mature, and no issues were raised.
SIP Events
-----------
Issues with authentication, 1) DoS attacks, and amplification, 2) Forking, 3) Record-Route, 4) Expires, 5) event package names, and 6) Call-leg correlation, 7) partial-vs-full state transmission were raised.
1 ) DoS/Amplification: Each SUBSCRIBE produces one response and one notification, which could make a 2-to-1 amplifiier. Consensus to define general "anonymous" authentication mechanism in bis.
2) Forking: No technical problems preclude support for forking of SUBSCRIBE if forking of INVITES is supported.
3) Record-Route: current draft's wording seems ambiguos and has resulted in variant interpretations. Consensus to clarify in revised draft.
4) Expires: Current draft overloads Expires header in NOTIFY to indicate when subscription will expire. This is an overload of header. There is a proposal to use a new header, Subscription-Expires, which may offeer semantic advnatge in subscription migration. Weak consensus for propsal.
5) Event Package Names: Debate is to whether to allow private event package names. Consenus seems to be to establish IANA registry on a first-served basis, no RFC or expert review.
6) Call-Leg Correlation: Question is how to correlate a NOTIFY -- is it with a "call" or a "call leg". This is mostly an issue on whether or not SUBSCRIPTIONS are initated within an extsing call leg. Current draft correlates with a call leg, but this may not solve all cases. Conensus to examine removing prohibition on mapping between notification and specific call as to whether this affects existing implementation semantics.
7) Partial vs. Full State transmission: Most interpretations of existing work seem to indicate that NOTIFYs will contain full states (SHOULD). State deltas may be important for many applications, but are problemactic in constructing full state because of possible missed messages. Consensus to consider body versioning techniques for state deltas.
Early Media
-------------
Many open issues, primarily with telephony interworking and QoS. Fundamental architecture issue is that early media is "forced" not "offered", and as a consequence we have no effective negotiation mechanism. This all seems to derive from need to map PSTN behavior exactly, and can be resolved if different user interface is allowed. There will be a lot more discussion on this topic.
NAT Friendliness
------------------
Current proposal includes several techniques for symmetric and semisymmetric NATS, including new SIP Translate header with semantics of "I don't know where I am, please use the address and port this came from". Consensus to split into at least two drafts, including Translate header (question: do we need a charter adjustment or new milestone declared here?) and seperate "NAT detection protocol for RTP" to be pursued outside SIP.
SIP SRC Indication
-------------------
Propsal to include source IP address in port in SDP describing sesion, and to expicitly differentiate RTCP port information. This would allow building SIP ALGs and firewalls much more easily (esp. "line" as opposed to "cone" binding devices), as much less information would have to be deduced. It also reduces the opportunity for RTP port spamming, as attacker would have to know source IP and port as well as SSRC. However, it poses complications for current simple-NAT proposals. There will be further discussion of this topic.
Extended HTTP-type-Authentication
-------------------------------------
Discussion included drafts from Rosenberg and Undery. The basic idea is finding ways to get more mileage, such as mesage integrity protection, out of digest autnetication techniques already specified in SIP. This has all sorts of open isses. Furtehr discussion moved to Security ad-hoc and to mailing list, with no clear consensus reached in the meeting.
Proxy-Supported Negotation
------------------------------
Idea is to determine whether at least one proxy in signaling path supports a specific feature. Existing negotiation technique can detect if ALL proxies in path support a feature. There has been ongoing list debate as to whether this is needed. Consensus reached in meeting that no requirement for this behavior, such as a specific application, has been identified and that work on the approach can be deferred until such time as a requirement has been identified.
Reliability of Provisional Messages
-----------------------------------
Alternative mechanism to 100Rel proposed. List discussions had been inconclusive. Consensus from meeting that proposed alternative offers no significant advantage in general case.
Session Timer
--------------
Two open isses: 1) New draft allows lower-bounding on sesssion-timer. Current proposal is to overload session-expires, with suggestion to establish new error code like 422-Minimum-Session-Expires. Consenus on proposal for new error code. 2) Absolute vs. relative timers. Consensus to deprecate absolute timers.
SIPbis Open Issues
--------------------
A bug tracking system is being used to track the large number of open issues in the bis draft. The meeting discussed several issues and attempted to get consensus for various propsed resolutions.
1) Issue 7: Allow CANCEL for non-INVITE methods. Current spec has muliple interpretations. Weak consensus to clarify indicating use of CANCEL only with INVITE.
2) Issue 10: Use of maddr: If client sends INVITE using maddr paremeter from route, should it strip the maddr off of the generated request URI? Consensus is yes, as documented in rfc2453-bis-03.
3) Issue 11: Record-routing for mid-call methods other than INVITE. This is intertwingled with Issue 138. Conensus is to allow mid-call record record-route on a case by case basis.
4) Issue 138: Forking of non-INVITE requests: Consensus to allow forking for non-INVITE methods on a case-by-case basis.
5) Issue 20: Mixing unicast & multicast in offer/answer . If offer SDP contains uni, can response contain multi? Proposal: general rule: answer should be something offeror can do. Hence don't send multicast in respons to unicats. If required, re-INVITE. Conensus to acdept proposal and add scenario to conferencing models draft.
6) Issue 23: dynamic PT reuse. SDP usage in 2543 says you can't reuse a dynamic PT number used previously for a different codec type. This limits number of codecs in a call to 127. It should be possible to reuse a PT once the transaction in which it was used has been completed. Consensus that this is not yet an issue for SIP and therefore there is no need to change.
7) Issue 146: Reuse disabled streams. SDP usage spec says once you have disabled a stream by setting port = 0that hat stream cannot be reused. This is important to maintain exlpicit ordering of codecs, but means the SDP size keeps increasing in on-off hold operations. Proposal: cannot remove disabled stream But if new one added, can take disabled stream's slot within SDP. No restriction on media type. This preserves ordering without increasing size of SDP. FID discussed as possible solution, but this doesn't seem to work completely. Further discussion is required.
8) Issue 58: Rejected mid-call SDP in 2xx: Question is what to "fall back to". Proposal to use general approach of using some signalling means to say that previous session description should be rtetained. Jonathan will consider in revised draft.
9) Issue 133: on-hold indication: Current SDP usage for on-hold is to set address/port number of all 0. This turns out to break RTCP, is IPv4 specific, and is generally ugly. Proposal to use a=inactive for non-sending codecs and a=sendonly for sending codecs, and preserve backward compatibility by accepting but not sending all-zeroes. This may have implications for QoS, and requires further analysis.
SIP Security Work Plan
------------------------
We are beginning to see common themes in security questons that suggest a possible path for generalization. Proposal to seperate discussion of "outside" vs. "inside" attacks and advance independently. This would include basic "outside" defenses like IPSec and TLS in rfc2543bis. The HTTP-derived authentiation mechanisms would be reqtined in bis, and all other security considerations seperated. Individual extensions would be constrained from proposing cryptosolutions pending general solutions.
Work Program: Develop Threats and Requirments draft. Finalize base requirments in bis and feeze. Define framework for popular auth mechnisms and focus on simple scheme provising UA-Proxy and Proxy-Proxy protections aliged with SRTP and SDP work.
updated 13 Dec 2001 13:23:08 -0600