Minutes, SIP WG, IETF 55 Edited by Dean Willis dean.willis@softarmor.com Notes recorded by Andrew Bender and Mary Barnes and Vijay Gurbani Meeting held Tuesday November 19, 1930-2200 in Atlanta, GA, USA Agenda Bash -------------- No objections raised Status and Charter, Chairs --------------------------- New co-chairs Rohan Mahy and Jon Peterson introduced. Status of work items reviewed by Rohan Mahy. 11 of 19 charter items reported complete. New RFCs issued include 3310, 3311, 3312, 3361. Identity and Privacy and AuthID Open Issues, Jon Peterson ------------------------------------------------------------ Draft-peterson-sip-identity-00 split into 2 WG documents, which were discussed seperately. Document draft-ietf-sip-authid-body-00.txt -------------------------------------------- Status: A specification of a MIME body that could be used as an authentication token. Now relies on either message/sip or message/sigfrag Discussion: There was discussion around whether Call-id should always be a must as there are scenarios (Referred-by and 3pcc) that need a flexible mechanism for correlation. There was a proposal that it should be Call-id unless you provide another mechanism for replay protection. There was discussion and agreement that it is always deterministic and clear when you don’t want to include call-id. There was also discussion around the vulnerabilities of NOT sending the Contact header, with the suggestion that if the AIB is intended for use inside a Dialog, then a Contact should be a MUST. Conclusion: Jon will address this in the draft. Document draft-ietf-sip-identity-00.txt --------------------------------------- Status: Now defines status codes and practices for providing an authentication token (which might be auth-id body, or could be something else). An AuthService authenticates user agents, creates some sort of authentication token (as a MIME body), adds token to messages. Document describes 3 ways that body can be added to requests: 1) (Essentially) Redirection (push body back to UA), 2) Auth Service acts as B2BUA, and the optimal mechanism 3) Content-Indirection Discussion: Point 1: Why a header can’t be used for the mime body. Given the S/MIME direction it really has to be a body. Point 2: Long term identity versus short term identity solutions (as described in the past). It was questioned as to how the multiple identities in the “short term” document would be supported. It was discussed that the support of this has to do with how the token is structured. There are 6 headers, 3 musts, 3 shoulds and optionals. It wasn’t believed that it’s necessary to define the Multiple identities explicitly in this draft. But, this discussion is a reasonable one to have. The concern expressed was that although there are multiple identity headers, there aren’t clearly defined semantics. Proposal: Discussion of this topic should continue on the list. Point 3: Normative support for AIB. It was agreed that a normative statement is needed for interoperability. You need to define the scope if it’s negotiable, etc. This gets into the downgrade attack issues, etc. There was concern that this might limit extensibility of the mechanism, however, Allison highlighted that the minimum mandatory to implement should be specified and that should not limit SIP’s future. Document draft-peterson-sip-smime-aes-00.txt ------------------------------------------------- Status: Recommends changing required encryption for the SIP profile of S/MIME from 3DES to AES. Why deal with this now? Because S/MIME for SIP has yet to catch on, better to fix now. Lower footprint of AES might also help foster S/MIME adoption. Additonal advantage: Same encryption algorithm as TLS (AES). Discussion: There was a proposal to add this as a 3261 bis bug, but it was highlighted that this is of much greater scope than a typical 3261 bug. There was also a concern raised over obsoleting parts of an RFC, however, Allison highlighted that it’s an accepted practice to update parts of RFCs with another RFC. It was suggested that occasionally writing a roadmap makes navigating the RFCs easier. Conclusion: Seemed to be general WG agreement for this to be a WG document. Content Indirection Open Issues, Sean Olson ---------------------------------------------- Issue: use of size parameter in content-type - this can be used instead of content length header richer negotiation of indirection per mime type security issues- sips/smime, access control, revocation / invalidation Proposal(s)- * use standard size parameter* * recommend s/mime and or tls * acl and negotiation are out of scope for this document... should be solved for sip in general * suggest wglc Discussion: why do we need size? Should it be madatory or optional? Conclusion: should make optional, as it may not always be possible to know the real size at the time of the indirection. Issue WGLC 2 weeks after changes published if there are no objections on list. RFC3261 Open Issues Jonathan Rosenberg ---------------------------------------------------------------- Group decided not to discuss at this time as the author indicated all open issues had been adeuqately discussed on-list. Caller Preferences Open Issues, Jonathan Rosenberg ------------------------------------------------------ Slides presented on open issues. Briefly reviewed Changes since last revision with the biggest change being the Require-Contact. A draft on related scenarios should be published shortly. Issue#1: Forced Parameter If a UA doesn’t say anything about a parameter, it still matches a rule with that parameter. Proposal: Add a parm to Require Contact rule that explicitly says whether it MUST match. No arguments against proposal raised. Issue #2 AND within single feature tag In some cases, you want to specifiy that a UA has to support multiple values for the same feature tag. Current mechanism is to use multiple values of the Require-Contact header field Proposal: keep as is. No arguments raised against proposal. Some discussion held about differences between multiple occurences of the same value vs. multiple values. Issue #3: Weight q-values based on amount of overlap Proposal: develop q-value algorithm which weighs based on amount of overlap; can be done in RFC 2533 framework. Discussion indicated that we need to develop a metric for the amount of overlap, and that in order to prevent spiral problems where each parameter has a differnet q-value, we must compute q-values automatically based on the amount of overlap. There was also discussion on exact match as a limiting case. The argument was made that whereas RFC2533 implies that partial matching is impractical in a general case, we believe we have enough constraints to be able to solve the problem within the given scenarios. Issue #4: Merge Require, Accept Contacts Require and Accept Contact are similar Proposal: Merge back into single Accept-Contact header field and define should-match parm which if contact predicate doesn’t match, causes it to drop. No arguments raised against proposal. Discussion: Similar to Issue #1. Issue #5: No one cares There has been little feedback on this draft given that it is widely referencec. Proposal: Rewrite intro to give it a bit more spark, explain better the power of the spec and that it is truly providing "one number" service. Discussion: lack of comments does not equate to lack of interest. It may be that this is just not contentious anymore. Issue #6: Priority semantics Proposal: work through use cases and express in draft. Discussion: priority semantics may be out of scope, since this is really a callee rather than caller issue. Proposed that this should handled through CPL. Issue #7: Implicit compatibility mechanism Skipped… Issue #8: Escaping Sadly, RFC 2533 syntax for feature tags uses characters not permitted in token (slash and colon). These characters are in use. Proposal: Use characters allowed in token, but not in feature tag, to represent those characters; bang gets mapped to colon, single quote gets mapped to slash. Conclusion: Although, there was lots of discussion on alternatives, none were deemed reasonable, so will go forward with proposal. Discussion: Could we have only one escaping mechanism? Point: There will be not translation that occurs. we are just renaming feature tags in the token codespace, and there is never a decode. Path Forward: Proposal: One more rev with these issues. Question: Ready for WGLC? Poll taken, general consensus recorded. Question: What about use cases? Should it find a home somewhere? There was some discussion on what to do with the use cases, with the general consensus expressed that the use cases are useful; whether they should remain in a separate doc, be put in an appendix of this doc or merged with other call flows is still undecided. Conclusion: 2 week WGLC after proposed changes. SIP Guidelines Open Issues, Rohan Mahy ------------------------------------------- Issues: Notion of CANCELs and provisional responses for non-INVITES currently conflicts with RFC 3261, that you must specify processing in new drafts. Does this causes more harm than good? Discussion: There was discussion around exactly what’s currently in RFC 3261, with Rohan suggesting that there’s never a good reason to receive Cancel for a non-INVITE. However, Robert S. highlighted that there is one. If a non-INVITE times out with no responses, the SRV draft is written that the endpoint fails over. Immediate provisionals are BAD for non-INVITE. Sending a provisional before a transaction times out can prevent some problems. There are really two different problems here: provisional responses, and CANCELs for non-invite messages. The discussion continued around TCP introducing additional problems and the importance of separating the 100 Trying from the discussion of provisionals. Conclusion: Robert to start list discussion on this particular topic once draft is available. SIP Session Timer -- Jonathan Rosenberg ------------------------------------------ Changes from last rev: * Rewrote overview of operation * 422 response causes you to retry with same call-ID and bumped CSEQ like 401 * Clarified that mid-dialog re-INVITE w/o session timer cancels session timer Issues: * Many complaints and limited interest * No defined requirements, not entirely clear the problem that is being solved. Proposition: only useful application is cleanup of state in proxies * Is it too complex for that usage? Proposals: * Redefine the scope * Keep the scope, but clarify the wording * Keep the scope, but pursue a completely a new design * For example, just use the dialog package! Conclusion: Concensus appears to be option 2 – keep the scope and clarify the wording. Discussion: There was some discussion around the lack of requirements, which is likely what leads to many of the problems in understanding the draft and finding issues therewith. Proposal: Draft should have a reasonable statement of requirements in the draft, including some which are not already there. Discussion of previously discussed alternatives, including the suggestion that this solution could align with RTSP and use the PING method. There was also discussion around support of this in other methods, however, it was highlighted that that introduces the need to maintain state. Question: Who would support this draft? Medium hum vote support Question: Who would support if it were enhanced (that wouldn’t support otherwise)? Even smaller hum vote. Question: How many people violently object to moving this draft forward as-is? No objections. o Final Conclusion: Jonathan will clarify the current version and submit for going forward and WGLC. SIPS URIs, Jonathan Rosenberg --------------------------------- Basic problem (SIPS URI): Text is a bit confused on whether its e2e or hop-by-hop Additional problems: Mixed cases – SIPS URI in Contact 200 ok if it ws nowhere else? Solution Need to come to agreement on the high level behavior, from there the detailed behaviors will flow Discussion: There was some discussion around the requirement for using SIPS. The general problem is with the double Record Routing. It was highlighted that there needs to be one place that properly describes record routing that can be re-used by compression, SIPS and transport. It was highlighted that (for compression) the double record routing works okay because there is not currently a scenario that needs to change something in the response. Robert proposed that you can use this abstraction to highlight that the link characteristics on either side are different. And that, SIPS may introduce additional constraints. Proposal: Robert will specify this general mechanism for multiple record routing. The specific cases where the issues have been identified in RFC3261 with different characteristics should reference the general mechanism. Conclusion: Go forward with Robert’s proposal and update the text in RFC3261 appropriately to make use of this mechanism.