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.