Minutes, SIP, IETF 60

Edited by Dean Willis

Session 1, Wednesday, August 4, 0900-1130

Agenda modified to substitute discussion of body part modification instead of resource priority..

Topic: Status of Working Group

Discussion led by chairs. Slides presented.

Discussion of Non-Invite Transaction Drafts: <>Consensus reported that two Non-Invite drafts are ready for WGLC: draft-sparks-sip-nit-problems-01.txt and draft-sparks-sip-nit-actions-01.txt. The chairs are to arrange for WGLC.

"SIPPING 16": Proposed that the WG should prepare a document denying that there is some set number of possible SIP features. Discussion centered on whether or not this should be an RFC. Resolved: We will sart with a draft and consider it as usual.

Topic: Content Indirection

Discussion led by Dean Willis acting as Editor. Slides presented.

Issue: Editor. Volunteers were requested to replace Seann Olson, who is not able to contribute at this time. Eric Burger volunteered.

Issue: Do we need content expiration? Do we have to update RFC 2017 to add it?  Rough consensus seem to be to retain this function, as it was present for WGLC and IETF LC. The document editor is to discuss the addition on the ietf-types mailing list and determine whether a change to RFC 2017 is needed.

Issue: Hash format. Consensus that the hash parameter should be named, as per "hash-sha1". The hash value shall be wrapped in double quotes. The editor is tasked with reviewing the hash parameter on the ietf-types list.

Issue: Partial rejection of content. Noted that some RFC (3359?) allows rejecting non-critical content. The editor is directed to clarify this in the text, potentially discarding confusing section 5.10 text .

Topic: Body Part Modification by Proxies

Discussion led by Rohan Mahy as Author. Slides presented.

Background of problem presented along with use cases and a variety of topologies including triangle, trapezoid, and local as well as foreign piggybacking.

Discussion was heated and active. This is clearly a controversial topic.

Notable points from the discussion:
  1. This is related to the policy discussion.
  2. Modification of bodies has a significant impact on the security model, and seems to require that S/MIME be applied on a per-part basis rather than per-message basis.
  3. Having individual body parts signed by different entities is problemactic.
  4. Any solution is going to have to address a large number of uses cases.
Discussion will continue, with no consensus recorded at this time.

Topic: Connection Reuse

Discussion led by Rohan Mahy as Author. Slides presented.

The main issue seems to be around identifying a specific connection in a manner suitable for use as a reference. The URI doesn't provide adequate context, except in the case of a GRUU which is instantiated by the element using the reference.

Discussion will continue, with no consensus recorded at this time.

Topic: Authenticated Identity

Discussion led by Jon Peterson as Author. Slides presented.

Issue: Retargeting vs. Redirection. The proposed approach effectively denigrates retargeting in cases where identify functions are performed by the retargeting element. Noted that this isn't all bad -- redirection offers a majority of the capabilities needed, without the problems introduced by retargeting including response identity, multiple forking response resolution, and so on. However, it does NOT provide some of the benefits, including proxy control, proxy-facilitated NAT traversal (especially with connection-reuse), and privacy control.

Does non-local retargeting go away so we can get identity? Don’t want security property downgrading – more choices allow more downgrading. If identity is critical, we’ve got to go there – not with a flag day, but we’ve got to go there.

Specific aspects discussed include:
  1. Does this contradict caller preferences? Jonathan thinks “no”.
  2. This doesn’t mess up request-history (after thinking about it a while).
  3. Do all the applications work? Extra RTTs are OK, although they'll chafe the wireless community.
  4. Need to make requirements so we can make sure we meet them.
  5. Cost-benefit from a speed perspective is subtle (and probably small as well). Almost all forwards are local forwards, and almost all phone calls have local forwards today.
  6. “The main thing is to make sure this actually works in a practical sense, and I’m not there yet.”
  7. RFC 3261 limits recursion – but was this text ever coherent? Would we clarify this text?
  8. This probably will slow down call setup in wireless domains, but it’s not unreasonable for retargeted calls to be slower. SIGCOMP helps here, too.
  9. RFC 3261 is pretty clear on who can muck with Request-URI – this should work.
It was observed that few participants in the room displayed confidence in their understanding of the problem or the proposal, and that further study would be a Good Thing.

Topic:  GRUU

Discussion led by Jonathan Rosenberg asAuthor. Slides presented.

Issue:  URN Equality. Consensus indicated to use lexical equality where a specific quality function for a URN is not specified and known to the element.

Issue: Ramp-up problem. The current text requires that registrars refuse registrations resulting in a conflict, after which restarting devices that caused the conflict can remove the old registration before trying to re-register. This reduces the capacity during a restart by a factor of four over simply overwriting the old registration. Proposals include overriding the old registration, or keeping both contacts. Several alternatives and issues were discussed, with key comments including.
  1. Question: Does having two registrations for same instance violate a critical GRUU property?
  2. Worry: Keeping both might contribute to another avalanche restart problem, and is more complicated<>
  3. <>Preference: (Paul K). prefers overriding oldregistration.Comment  (Rosenberg) - Ok to have multiple routes/connections for an instance, so #1 above is "no".
    4. <>
  4. Question: (Rohan) Could we use a flag or special response code to tell the registering mobile than an existing instance has been overridden and that something odd must have happened?
  5. Worry:  Multiple contacts with the same instance id complicates the way proxies handle certain errors. Complicates a lot of  things.
    6. <>
  6. Comment:  (Sparks) - Sounds familiar with Etag and XCAP.
No consensus observed on the ramp-up issue.

Session Two, Thursday, August 5 1300-1500

Topic: SIP MIB

Discussion led by Rohan Mahy as Chair.

Proposals to close 3 of the 4 known open issues were made on the list. One issue remains. Rohan propsoes that the MIB functions related to configuring SIP UAs be deleted, as we have a seperate UA configuration framework. Some elemenst would remain, but as read-only. The group indicated a consensus to proceed with this approach.

New issue raised: We added an application index to all these tables. The problem is to define application name may end up in the same name repeated. Is this legal? The problem is that the same application is an instance of the same application. RFC 2788 seems to say one entry per application. The MIB spec is restricted in the name. A suffix to the application name may solve the issue, although this point is not agreed. Follow up on the list.

Topic: The History of History and Voicemail, A Diatribe by Cullen Jennings

Discussion led by Cullen Jennings as Amicus Curae, with slides presented.

Two solutions for users with voice mail.
1.    History: proxies retarget include information about where and why they retargeted.
2.    Voicemail uri: proxies figure out what services they want voicemail to provide and tell the voicemail the voicemail to do that

Slides: A long list of drafts that request this issue.

Slides: reviewed the history of changes in voicemail-uri.

Proposal: The possibility of using both: Cullen indicates that both seem to be needed and not mutually exclusive..

Recommendation: chose something now: History, URI, Both. The recommendation is to use both, since the do different things and they
work together.

Rohan, as chair: We are already doing History. So the question is: we do History alone or we do History AND URI.

Poll: Anyone implementing voicemail URI? No answers.

Suggestion by Dean as Chair: to take voicemail URI as an individual submission heading to informational RFC, and proceed with History as planned in the working group. There seemed to be general consensus to proceed with thsi approach.

Topic:  Request History

Discussion led by Mary Barnes as Author. Slides presented.

Mary goes through the changes from -02 (see slides)

Issue: Section 4.1 has normative statements that appear to overlap with the normative ABNF. Resolved that the author will make the text explicative rathen than using requirements language therein.

Broader review is now desirable. The author feels that the document is ready for WGLC, and there seems to be a consensus in the room  to proceed with last call.

Mary presents an analysis of History-Info vs robust security:
comparison with draft-ietf-sip-identity-02 and
draft-ietf-mahy-sipping-add-body (see slides).

Mary also presents an analysis of History-Info versus Privacy.

Discussion ensued, with key lements being:
  1. Jon: People are much confortable with the request portion than with the response portion in the request identity draft. Suggest to split<>the request-identity in two drafts. Considering to work on two optionsfor request-history as well, since they are incompatible.<>Rohan: transition mechanism that the P-Asserted-Identity to thegeneral internet. 
  2. Jon: the request identity draft just says that a proxy cannot add a body.<>Keith: we need to solve the ientity stuff before the history, not the other way round.<>
  3. Rohan: is is sufficient to say in history-info that a proxy that retargets to a non-local then it should redirect. This will work. Other mechanisms may be specified later. If a proxy want to convey history-info securily, then you can redirect to TLS.
Rohan is to send text to  Mary as per above.

Topic: Connected Party -- who am I talking to?

Discussion led by Cullen Jennings as Author. Slides presented.


Problem description in the slides.  Possible solutions:
1) update of state in the dialog;
2) transfer to a new user.

Noted that 1) has two
subsolutions:

1a) Update To or From, although is not compatible to 2543.
1b) update with a new header, body, AIB, etc. Compatible with 2543, but a 2543 phone will not update its display.

  1. Jonathan: With respect to 1A, I hope people are not using To and From as the primary source of information for the user.
  2. Rohan: WRT solution 1a and 2543. A 2543 implementation will return 481. To and From are useless today.
  3. Andrew: don't depend on To and From headers, the UA will not use them.
  4. Jon: email contains From and To headers, and they are useful and intuitive. They can be forged, and that's why we need identity, and this is approach taken by identity, making them meaningful. it requires a lot of motivation to make the to/from header less meaningful.
  5. Jiri: In forwarding scenarios across different domains, there is not traces of the original sender.
  6. Keith: the problem is reusing a header for different usage. This is the problem why we end up with so many identities.
  7. Rohan: the semantics of from/to: To is a semantics of to which you address the dialog. Cullen suggests the semantics of to who you are communicating. The identity work addresses part of this correlation.
  8. Rohan: if we go with 1a and do not change the To header, someone has to change a bunch of stuff in Section 26 of 3261 to indicate how to do things now with  S/MIME. 
  9. Hisham: ok to change To/From, if you authenticate the user you don't authenticate the To/From. If I want to change my name, I can re-INVITE to change my From. 
  10. Cullen: sort of agree with Hisham. right now we don't have a mechanism to change the name. Solution 2 is about INVITE/Replaces, not about REFER.
  11. Jonathan: Think about the way many people visualize billing systems toay --  the billing system charges the user on INVITE and BYE. This is wrong. The billing system should take information about "what happens" during the call, and figure out that information when the call started/ stopped.
  12. Jonathan: don't understand the serious security issues (see slide, solution 2).
  13. Rohan: replaces has requirements for authorization of the replacement,and the way to do it is to look at the Referred-By header and correlated.
  14. Jonathan: a solution: GRUU + cryptographicly random grids
Chair: I think I sense a developing consensus to look at the cryptographic technics of the GRUU and the dialog usage. Poll of the room about the possible solutions: Room prefers support for Replaces with GRUU and cryptographic randoms (solution 2). If that does not work, then try a new header (solution 1b).


Topic: SIP State Update

Discussion led by John Elwell as Author. Slides presented.

Proposed: Treat the contents as clarifications to existing RFCs as bug fixes and add similar clarifications to authid-body and future drafts.

Discussion: How does this related to the previous presentation. Do we need to put this on hold until we resolve the previous proposal?

Chair proposal: Bring the list of bugs, one at a time, to the mailing list, so we can get attention focused on each and work through it.

Topic: Making S/MIME Work With Certs

Discussion led by Cullen Jennings as Author, with slides presented


Issue: Fetching credentials: options are
  1. use notification
  2. use config framework
  3. use https

Discussion follows.

Several points were raised.
  1. The trick to make this deployable is to have one certificate per domain instead of a certificate per user.
  2. Tieing the lifetime of the certificate with the lifetime of the subscription solves a bunch of problems.
  3. Using HTTS to fetch a certificate could avoid a bunch of SIP messages.
  4. Jonathan: we can do this with zero call setup delay. buddylist provides a context to get certificate from my buddy. You can add a flag to a presence document "hasCert".
  5. Rohan: if I received a signed message from someone I don't have a certificate, for then HTTPS is better. From deployment perspective it's easier.
  6. Jonathan: this is easier to deploy with SIP. In which way the is the HTTP solution superior to the SIP solution?
  7. Maintaining a large number of subscriptions is server side state. The HTTP solution has no server side state. However, we already have the subscriptions for the buddy list. The subscription solution offers immediate notification of certificate revocation. However, the short subscription timer in certificates cannot be used, since it is expensive to generate certificates.
  8. Note that fetching the cert does not require TLS -- certs can be sent safely via plain HTTP.
  9. If HTTP is used, how does one compute the HTTP URI? SRV may already solve the problem.

Further discussion deferred to list.

Chair: we have a lot of dependencies on making S/MIME to work. There is strong consensus to make this work. Proposed to make this a WG item. Poll to the room indicates strong consensus to adopt this as WG item. Chairs are to work this out with the ADs.

Topic: How offer/answer interacts with multipart/alternative in SIP

Discussion led by Cullen Jennings, with slides presented.

The problem of first trying a secure call and then the insecure, is that the secure call is prioritized (e.g, if the voicemail implements secure, S/MIME, SRTP, the voicemail will always answer).

Proposed Solution: Content-ID in each multipart entity in the offer and a Content-Reference in the answer.

AD: This is probably in the scope of the MIME WG.

Issue: do we need a Require header. Proposal: yes

Points raised:
  1. Jonathan: If I do SRTP I need to encrypt the SDP. Better to start with the problem statement. The problem: I cannot use SRTP because it is a backward compatibility problem.
  2. Cullen: the solution to the bid down attack is to use auth body and encrypt everything.
  3. Jonathan: Second problem statement: Due to the consequences of sending secured multipart, the nonencrypting UA will reject.
  4. Dean: problem 1) can be defined as "how to find out if the other party can do SRTP". Solution: multipart. Alternative: send an offer encrypted, if rejected, send offer unencrypted, but what happens with forking in that case? Multipart is probably cleaner.
  5. Jean Francois: the number of alternatives is big (encrypted voice, non-encrypted audio type of things). This may increase complexity and size of the multipart.
  6. Dave: It should be possible to accept the session but reject the offer. Get a 200 OK, but sending something that "I want to establish the session, but there is something in the SDP that I don't understand".
  7. Hisham: yes, you can reject everyhig in the answer
  8. Hisham: Can you offer both RTP and SRTP as options?
  9. Cullen: the problem is that if you do SRTP you need to encrypt. the SDP.
  10. Aki: There may be inspiration for the Require: tag in  the the security agreement specification (sip-sec-agree).
  11. Jonathan: may need to look at preconditions as a solution.
  12. Rohan: backwards compatibility is an issue, so preconditions does nothelp.

Further discussion is deferred to the list

Topic: Using SAML for SIP

Discussion led by Hannes Tschofenig
Slides presented

No discussion due to time constraints.

Chair To-Do List

  1. WGLC draft-sparks-nit-problems
  2. WGLC draft-sparks-nit-actions
  3. Work with MIB team to delete UA configuration.
  4. Rohan to send text to Mary clarifying that proxy retargeting to a non-local destination will redirect instead. When this is incorporated into request-history-mech, the draft will be WGLCed.
  5. Get certs work on-charter and add milestone.