[Sip] Minutes, SIP Working Group, IETF 55

["Dean Willis" <[e-mail]>]

Also posted at:
http://www.softarmor.com/sipwg/meets/ietf55/minutes/minutes.html

Edited by Dean Willis [e-mail] 
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.  

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip