Session Initiation Protocol (SIP) WG

Minutes edited by Keith Drage.

Based on notes by Bruce Lowekamp, Dale Worley, Ben Campbell, A.C. Mahendran and Spencer Dawkins.

Meeting chaired by Dean Willis and Keith Drage.

Slides presented included in the proceedings.

SIP session 1

Agenda bash and current status

The note well statement was displayed

Slides: SIP-1.pdf

Note takers were identified. Thanks to Bruce Lowekamp, Dale Worley and Spencer Dawkins for taking notes for session 1.

It was identified that there was expected to be an ad-hoc SIP session on the security issues that were being found with RFC 3261, in regard toSIPS usage.

The agenda was agreed with the insertion of a quick slide from Gonzalo Camarillo on SIGCOMP activities.

The following SIP RFCs were identified to have been published since IETF#65:

RFC 4458: Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) – AD sponsored informational
RFC 4483: A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages – Proposed standard
RFC 4485: Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) – Informational
RFC 4488: Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription – Proposed standard
RFC 4508: Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method – Proposed standard
RFC 4538: Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) – Proposed standard

The following SIP internet-draft was currently in AUTH48:

draft-ietf-sip-identity-06

The following SIP internet-draft was currently in RFC editor's queue:

draft-ietf-simple-event-list-07 (although this was developed in SIMPLE it was submitted to IESG via SIP to cater for the SIP change process)

The following SIP internet-draft are currently with IESG

draft-ietf-sip-mib-11
draft-ietf-sip-e2m-sec-02

The following SIP internet-draft is ready for IESG

draft-ietf-sip-answermode-01

The following SIP internet-drafts are in working group last call

draft-ietf-sip-connect-reuse-05
draft-ietf-sip-gruu-09 (REVIEWERS REQUIRED TO FINISH as only two WG members identified they had fully reviewed the draft – this will be the first document to go through the full review process identified by the WG chairs to the list)
draft-ietf-sip-fork-loop-fix-02

Existing milestones were identified, along with new dates for the existing milestones (with the new separation of WGLC start dates and IESG submission dates for each internet draft being progressed to RFC.

In response to a question from the floor, this leaves 9 charter items the SIPWG currently has in progress. This was targeted at identifying when the SIP WG would complete its current work.

At this point the WG chairs identified the new WG items that were identified by the WG at IETF#65 and subsequent email activity which identified dates through to the end of 2007. These were still subject toapproval by the IESG as the WG chairs had only got the list to the IESG secretary late the previous week.

In response to another question from the floor as to whether the dates could be earlier (specifically for location conveyance), the WG chairs agreed that dates could always be earlier, providing the WG was satisfied that the document was actually ready. However the WG chairs stated that this represented their best estimate of what was realistic.

The WG chairs then conducted some polls concerning support for some of the current work:

Question regarding draft-ietf-sip-certs: Response to list poll was universally positive, but offline WG chair had had some negative comments. Is this leading toward implementation? Consensus: Yes, at least 5 implementations are expected from the room, and no one presenting objections.
Question regarding draft-ietf-sip-connection-reuse. Does it still provide any benefit. WG chairs identified there was a positive response to the list poll. However in the meeting one WG member questioned the value based on the limited number of scenarios where it provides real benefit. It purported to give CPU overhead benefit, which the speaker doubted. Additionally does not work through NAT and requires mutual TLS to work. Is it the highest priority for the minimal value it provides. A second speaker identified one advantage is that it states that any entity has to reuse the existing connection which is not currently stated elsewhere. Discussion deferred to agenda item on the topic.
Question regarding draft-ietf-sip-outbound: Should it be revised?

At this point the WG chair projected a picture of a strikingly flattened-looking squirrel on a flagstone patio. After the audience expressed some distress, he remarked that this is a natural phenomenon, the temperature at the time was 45 C and the squirrel is cooling its belly on the stones. Discussion of aboreal rodents ensues upon presentation of the agenda.

Question regarding draft-ietf-sip-outbound: Is it ready for WGLC? Consensus: There are a number of open issues that still need to be resolved.

SIP and SigComp (draft-ietf-rohc-sigcomp-sip-02.txt)

Gonzalo Camarillo presenting.

Slides: sip-3.pdf

Presentation on problem with compression and record-route. When receiving a request, how to identify the previous SIP hop that sent the request (in order to manage the compression status)? Plea for support in resolving this issue.

Outbound (draft-ietf-sip-outbound)

Rohan Mahy presenting.

Slides: sip-5.pdf

Slide 2: Currently when STUN response indicates change in mapped address, UA assumes NAT rebooted and reregisters immediately. There is no authentication of these STUN keepalives. UDP problem. On unprotected 802.11 networks, an attacker who can see the STUN request, can easily send a response with a different mapped address and will usually beat the real response. This causes UA and registrar (and intervening proxies) to do work. Can melt the registrar. Proposal to add timer delaying re-registration if binding appears to change more than seems reasonable in some period.

Discussion from floor:

3489bis (draft not yet submitted) mentions issue with forged STUN binding response in security considerations. Questioned as to whether this is really an amplification attack? Especially compared to problems with multiple responses to a single request.
don't care if we reapply the existing timer mechanism but don't introduce new ones. There are better attacks that can be applied.
Presenter offers beer for a better attack.
Reference to http://www.usenix.org/events/sec03/tech/bellardo.html

Conclusion: Do not add new timer.

Slide 3: Discoverting STUN support. Current text says that keepalive STUN support is "configured" (using a very broad definition of configure). Incompatible with current DHCP proxy discovery (but so is sigcomp) due to limitation of DHCP option. Do we need another way of discovering/probing for STUN support defined in this document? Options: provide DHCP capability, provide DNS based option, or provide some sort of probe mechanism within SIP.

Discussion from floor:

Suggestion of Proxy-Require, but this only allows validation, not discovery.
One speaker said his feedback was that something will turn this on or off, not worth delaying to define something too complicated anyway.
Another speaker. Jonathan was proposing STUN=keepalive, right? Really like this one, because configuring in the phone is key to getting deployment anyway.

Consensus was considerable support for the rule that "configuration information is enough to send STUN" but most would like some direct validation mechanism created.

Slide 4: Validating STUN support. Currently presence of keepalive=stun used as indicator its OK to send STUN requests. Some expressed concern about misconfiguration causing proxies that don't do STUN to get confused. More of a problem for TCP. Options: treat this as a non-problem; revisit STUN keepalives over TCP problem; don't send STUN until UA validates its OK, by including a parameter in reflected Path, but Path not always present; have UA try the request with a Proxy-Require: sip-stun; probe with OPTIONS. only way to validate keepalive=stun

next issue: validating stun support.

Discussion from floor:

Proposal that need Proxy-Require "outbound" would solve this problem rather than Proxy-Require "sip-stun".
If we don't solve LR problem won't solve this. Agree with proposal
any objections must explain why different than "lr" problem
Concern that the mailing list combatants on these issues are not present in the room; this will have to go to the mailing list. we should ask for positive assents.
Another speaker. Every other extension has a way to reject, this one doesn't.

Question put to whether document should be changed in respect of this issue. No consensus.

Back to validation (slide 3). More discussion:

Validation concerns are about confusing next-hops with misconfiguration, especially for TCP. Is this a problem?
Another speaker. If you put this in the service-route, I'll be happy.

validating:: third option on validating slide would render discovery moot (don't send stun until validated OK through parameter in reflected path)

Put to meeting: is the existence of a keepalive=stun in UA configuration sufficient to allow transmission of stun without further validation and progress document with that assumption? No clear consesus with very few responses. Take to a later discussion, and possibly on list.

Discussion:

It's the service providers, not the implementers who have a problem with this.
Another speaker (service provider) would prefer not to receive protocol (STUN) that it doesn't support rather than have to deal with it.
Proposal to add words of caution and admonition, but then let document o forward
Query as to real problem. Identified that can cause framing problem in TCP. However though that this may be self limiting.

WG chairs declare there is not sufficient consensus on either of these two issues (slide 3 and slide 4).

Slide 5: STUN keepalive definition. Proposal that STUN keepalive description is pulled into a separate section that can be implemented independently. No objection from floor.

Slide 6: How many flows (minimum)?: Current draft says (from Section 4.2): For each outbound proxy URI in the set, the UA MUST send a REGISTER in the normal way using this URI as the default outbound proxy. Proposed to change to SHOULD.

Discussion:

SHOULD must have caveat that violation can kill reliability.
Fine, but can't say "does no harm" because single flow causes more aggressive reregistration avalanche restart problems

Consensus: Agreed to change to SHOULD - but there should be strong warnings in the RFC of the dangers of not adhering to the requirement.

Slide 7: Additional discovery and semantics of outbound-proxy-set. Various proposals to discover or manufacture outbound-proxy-set or apply different semantics. We don't even have all the requirements written down for these proposals. Proposal: Can be addressed in future extensions without any changes to outbound. No dissent from floor.

Slide 8: Why does registrar send to edge proxy over same connection? Only needed if EP is in a foreign domain for authorization. Draft defines edge proxy obliquely as in a foreign domain, and other proxies as a disaggregation of a proxy/registrar. Incredibly confusing. Needs to be more explicit. Request made by presenter for assistance in providing text.

Slide 9: How to verify edge proxy support. Currently draft says that edge proxy adds a flow token to a Path header and forwards. No discussion about how the registrar decides that edge proxy actually did this. Proposal: edge proxy adds new parameter "ob" to Path URI to indicate it added flow token appropriately. Example: Path: <sip:token@ep.example.com;lr;ob>. If no token present, registrar ignores reg-id parameter, doesn't return Supported: outbound.

Discussion:

Will only be provided for first element. It is a Proxy-Require dodge. Thinks OK.

No time for further discussion in meeting so editor makes plea to discuss offline.

Slide 10: Presence of Supported: outbound. What does this mean? Today it means that the registrar supports outbound. Client can use this to understand that if it needs to cleanup old Contacts using RFC 3261 style matching. Proposals: clarify this in the text; only include Supported: outbound if any edge proxy supports outbound as well

re-registering vs replacing flows:

Discussion:

What happens when edge proxy supports outbound but registrar does not? Would the edge proxy change it's behaviour. Presenter doesn't see any need to do anything differently.

No objection from meeting.

Slide 11: Re-registering with same reg-id. Original intent of reg-id is so that UA can indicate if it wants to add a new flow or to replace an existing flow. Dave Oran asked for change to language (ex: SHOULD replace) to allow for a private use case. WG was later uncomfortable with idea of deleting/replacing flows. In Dallas seemed to have consensus to use most recent flow. Since then, many complaints on the mailing list about this, and no one motivating/defending previous choice. Problems with this: proxy can send traffic to the wrong place (for UDP flows); no way for registrar to delete state until registration expires; no way for UA to say it really wants to replace flow; harder to implement on registrar; not motivated by requirements. Options: leave draft as is; change back to SHOULD replace flows with same reg-id; say registrar MUST replace flows with same reg-id. Proposal: SHOULD replace flows.

Discussion:

keeping flows is very bad with amplification.
Surely registrar can get rid of state at any time.
new draft almost forces replacement. If two registrations are equal, one must replace the other. "not a MUST, it's true by definition".

SHOULD vs MUST:

SHOULD: some

MUST: more

OBJECT TO MUST: one

OBJECT TO SHOULD: more

WG chair: rough consensus on MUST.

Slide 12: Refresh registration on same flow. Erkki pointed out that registration refresh should happen over the same flow it refreshes. No issue.

Slide 13: Usage of 410 response Code. Adam Roach pointed out that semantics of 410 response code is inconsistent with our usage. Proposal: Use 480. No issue.

Outbound discovery (draft-koivusalo-sip-outbounddiscovery)

Slides: sip-7.pdf

Miguel Garcia presenting.

Problem definition, requirements, solutions, evaluation and specification - all in one small document.

Discussion:

proposal (not sent to list yet) - could DATA URI be used with maximum number-of-flows in DNS?
Concerns that we are dispersing configuration information to 17 different places with no architecture supporting this. Why not put it all in DNS and forget the configuration framework that's not going anywhere in five years anyway?
Concerns expressed about DNS approach, especially with mid-dialog failure - this won't work for mid-dialog failure, no way to express this in something as static as DNS. Getting k of N from a DNS starts to fail with the DNS design. Proper choices can't be expressed in DNS (choose one of first two and one of second two). DNS is too static.

Jonathan Rosenberg will write up description of alternative approach, after which the issue can be discussed.

Adopt as WG draft? No decision to be made at meeting. Will take this to the list to discuss.

Use Case for Mid Dialog Request Routing with Outbound (draft-johns-sip-outbound-middialog-draft)

Slides: sip-4.pdf

Sumanth Channabasappa presenting.

Explores enabling failover when middle boxes fail, and its interaction with the outbound flow mechanism. Presentation includes several use cases. Looking for feedback from the working group.

Discussion:

GRUU draft does have some overlap here - should describe how to do outbound mid-dialog requests.
Another disagreed. Path is not replaced in GRUU. Document is needed, but not in GRUU.

Question from WG chairs as to whether this should be placed in outbound. Pointed out that this was violently discussed in Vancouver and not agreed.

Consensus is that the I-D remains individual, because there is no consensus on the correct solution to this problem. Need to identify which problems need solving, and which ones should be left out.

Connection reuse (draft-ietf-sip-connect-reuse)

Slides: sip-8.pdf

Vijay Gurbani presenting.

WG chair identified that Vijay would present the current status of connection reuse, but then move on to an issues that he considered needing resolving in order to complete the work, which was where domain certificates came in.

A discussion ensued of Dean's facial hair and whether it has anything to do with the squirrel.

Presents current status of work. Draft is essentially complete, however need text on virtual hosting.

Discussion:

AD: what text is needed on virtual hosting – not confident it is possible to write this text? Editor would like to get domain-certs work done first.

When returned to the issue: Theory is that research on domain certificates will help solve the problem of virtual servers. No consensus as to whether this work has a future or not.

Domain certificates (draft-gurbani-sip-domain-certs)

Slides: sip-9.pdf

Vijay Gurbani presenting.

There is a significant open issue regarding how SIP domains are to be specified in certificates used by proxies for SSL. This issue interacts with practical issues regarding how certificates are obtained, how SSL operates, and the intended security assertions of SIPS/TLS.

Discussion:

Security advisor: TLS isn't designed to work without a fixed name in the certificate, don't do this, it doesn't work.
either buy specific certificate or wildcard - is that what you're trying to accomplish?
Security advisior: no matter how many servers you have in your farm, they have one name. Any attempt to do otherwise, you can fight that, but you'll lose.
AD: I know we have problems in RFC 3261 - is this one of those problems? Naming things are complicated because they are so arbitrary. We can try to support anything, but some things work better than others for TLS. The combination of credentials and domain names must make sense. TLS is oriented to the existence of a single host name. What is in the domain name must match the certificate (and the credentials they hold). Anything in the Record-Route header must match the domain names of the credentials.
usually people expect the name in the certificate to match the hostname. In this case, you're having the same problem - "how meaningful is it when they match"? Can accept broader "matches" if you're asking a user, but there are limits.
Presenter identified that the issue is what is a domain name. Is downtown.atlanta.com same as atlanta.com.
Others from the floor identified that the way to answer this is to do the multiple names in the certificate.
Would like to ride the web way and get certificates that match the host name. Could associate the connection to its name - makes record-route work correctly.
AD: "human isn't always involved in matching" - proxies connecting to proxies, etc. All the cases you're showing are easy to match. Do we really need subordination checking for names?
Security advisor: don't undertand SIP, do understand security. It's not reasonable to believe you have different security matching for different applications. Could have second name or wildcard in certificate - that's what I'd recommend.
sending INVITE to atlanta.com, told to go downtown.atlanta.com. What I want to know is that I got to someone who is authoritative for atlanta.com.
But, domain name in the certificate has to match the host you're talking to, otherwise you're talking to someone else.
Presenter likes two names in a certificate, too.
need something like domain keys from mail world applied to SIP.
AD: you have a route header because someone gave it to you. Should we talk about mechanics for an hour here? Could have SIP connection that you can trust, could have SIP connection where you can't trust - depends how you got it.
Dean - TLS connections aren't end-to-end, and have nothing to do with request URIs. Therefore the Route header has to contain this information independent of the Request-URI.
Issue has more in common with HTTP than you think. downtown.atlanta.com can get a certificate independently of atlanta.com, or could break relationship with no way for atlanta.com to revoke certificate.
Security advisor: CAs don't interpret domain names. Verisign doesn't ask apparent delegators about certificates for subdomains. Trying to assume that they do will fail - it failed in HTTP cookies already.
The guy you trusted put the URI in there.
Wildcards can work, we have enough of a solution, let's stop with that.

Back to presentation. How do servers authenticate clients? Which header does it use: From, Via, ... name in certificate.

Discussion:

AD: Cullen - the name it pulls out of a certificate is the right answer - based on a name, doesn't have to match anything.
Make that look like client-server, just in reverse direction. We have to separate authentication from validation.

Presenter – if we do this, then the proposal has to be to normatively update RFC 3261 in lots of places. Agreement from floor.

Document is currently an author draft, and will remain so.

SIP session 2

Agenda bash

Note takers were identified. Thanks to Be Campbell, A.C. Mahendran and Spencer Dawkins for taking notes for session 2.

Need to move a number of items which we failed to deal with on the previous session into this session, therefore we have shortened some of the original items in an attempt to catch up.

Location conveyance (draft-ietf-sip-location-conveyance)

Slides: sip-2.pdf

James Polk presenting.

Slide 2: Goal of the draft is to push UAC's location to another SIP element. PUBLISH is not pushing in this definition. Along the way, define SIP as a Geopriv “Using Protocol”, per RFC 3693. Incorporate the Geopriv defined PIDF-LO (RFC 4119) into SIP Messaging

Slide 3 & 4: Changes since last version.

Slide 5: Open issues requiring resolution.

Move the requirements to an appendix - this will stay in the RFC. Keith mentioned that the format needs to be consistent with other SIP documents. Only needs to move later in the document and take out the RFC 2119 text. Agreed.
Carve out basic operation section without normative text. Re arrange sections 4&5 into per element behaviours
Reduce the text in section 2. Agreed.

Slide 6: Open issues not sure about.

Suggestion to list all SIP methods this extension applies/does-not-apply-to in the abstract.

Discussion:

Don't want to rule anything out of scope. Could also see some cases where it even applies in SUBSCRIBE. Applies to these types of things, may apply to others" is fine. Don't rule stuff out of scope in this document.
Proposed using this in REGISTER during ECRIT yesterday.
Hisham - too much text in the abstract for a complete list.
Just need to be clearer about pull vs push in Abstract - will say this more clearly on the list.
Just improving Abstract text, not changing scope of dcument.

Conclusion: Will take to list.

Suggestion has been made: For location by value, S/MIME message body always used initially, and to allow a back-off to less secure communication if there is an error.

Discussion:

For emergency calls, not comfortable increasing setup time.
S/MIME only works when encrypted with public key of destination - don't know destination, much less public key. This sounds good but will always fail at least once and may fail in all cases - unable to communicate at all.

Conclusion: Good technical reason not to do this.

Suggestion: expanding the location header to allow a base64, PIDF-LO equivalent header value i.e. allow the PIDF-LO object to be present in a SIP header (probably, encoded in base64). This goes against past guidance (from both chairs and ADs).

Discussion:

What was rejected was to embed a PIDF-LO format.
AD: Agree that was bad. What proposal in this are is good?
Data URL allows for the location to be included in the SIP header. (MIME type and encoding. See no technical reason why it would'nt work.)
AD: Putting this sort of information in headers breaks the layering.
Useful where location information needs to be resolved into a PIDF-LO document.
Message bodies should not be used for call routeing. Headers should be used for this sort of thing.
Presenter of the opposite opinion.
Referred to minutes of Boston ECRIT interim.

Conclusion: WG chairs asked for the discussions to be taken to the list (including discussions on motivations for carrying this information in a header as supposed to the body). Also needs to discuss whether it will work with UDP.

Issue: Should location be allowed in responses?

Issue: Add a new requirement that HTTP is required to be used by receipient

for de-referencing location.

Both issues to the list.

Presenter requested more reviewers for the draft.

WG chair: new version needs to be ready for WGLC. If you have objections or technical comments, now is the time to say so, on the mailing list.

SAML for SIP (draft-ietf-sip-saml)

Slides: sip-10.pdf

Jeff Hodges presenting.

Slide 2: Status. Moved to WG document, addressed list feedback from Vijay Gurbani. Enhanced assertion example section; added references; changed order of scope and intro sections; moved use cases in appendix.

Slide 3: Issues: Is this spec a soution for only meeting the trait based auth requirements? Discussion about enabling SIP proxies to add SAML assertions to the - If so, only need to meet stated requrements in trait-authz-02 would not need to met reqs of other saml based drafts may need their own saml profiles, doesn't need to meet reqs of various SAML-based I-Ds eg sippayment, SIP CPC, SPIT.

SIP header by value.

Slide 4: Issues. Discussion about enabling SIP Proxies to add SAML assertions to the SIP header by value.

WG chair: Postive responses on the mailing list and therefore accepted as WG draft.

Discussion:

Yes, it covers the requirements. Concerns about binding of SAML asserting to SIP call. Some fields like Call ID etc need to be in the SAML assertions. Would like to have standalone binding of assertion to the call. Editor (and Jason Fischl) will check to make sure that it is covered.
That's a stronger check than any of the saml constraints. Problem is that we're doing something besides just delivering a cert - it's a signature over data.
Backwards compatibility issue referencing saml. Server does not know whether to provide a cert or a saml association.
Fix is being made in draft-ietf-sip-identity in AUTH48 to allow CID, etc. allow broader choice of URI schemes. Need a way to disambiguate URIs.

Conclusion: All issues need to be taken to list.

Certificates (draft-ietf-sip-certs)

Slides: sip-6.pdf

Jason Fischl presenting

A good number (lots?) of people seem to have reviewed the draft. A fair number are implementing or intend to implement. Will be at the next SIPIT.

Will go to WGLC in a couple of weeks - if you're going to scream, do it really soon, onlist. If you have any comments that will cause a revision, get them on the list quickly.

Hop limit diagnostics (draft-ietf-sip-hop-limit-diagnostics)

Slides: sip-0.pdf

Scott Lawrence presenting.

Contrary to what the presenter initially said, this document is not in WGLC, as we are waiting for the charter approval. We have polled to see if it is ready, so we can put the question as soon as the charter comes through.

Issues raised during recent discussion:

Slide 2: whether "request message" should be returned in other un-recoverable errors (400, 403, 410, 414...). This is not the definitive proposal. The problem is this changes the focus of the draft. Text might say that if an error does not already specify a diagnostic or recovery mechanism, it could do this.

Discussion:

ok with expanding the scope of the draft to include this for other error message. Not sure if I agree with this list. Generally for proxy-related errors, and for protocol-related failures, not for policy-related failures.

Conclusion: No objections in meeting to explanding the scope to include other errors.

Slide 3: Is it ok to use Warning header for problems other than SDP? Should we

use a specific warning code be defined? IANA registry says "used for SDP". But this isn't what the RFCs said, and. Would make more sense to reuse than pick something else for religious reasons.

Discussion:

Proposal to put another header in the sipfrag rather than change the Warning header.
Henning and Jonathan can't remember any grand architectural justification for the IANA restriction. At that time motivation was mainly SDP. However, see no reason why we cannot reuse it for SIP.
Presenter: We're seeing non-SDP bodies for which Warning might apply
Will not object. However, text for registry document needs to be changed as well.

WG chair asks the SIP WG to think generally about other uses of Warning if we are expanding it to do this, and make sure all intended usages are covered.

Conclusion: Ok to using Warning header (to describe issues with bodies generally, but will need to change IANA registry text as well.

Comment from floor outside scope of this slide on how some intervening entity can know whether to pass on the contents on this or not, and whether the server knows such an intervening entity exists. Such hiding functionality is outside scope of current SIP work. Assumption is that there is no value in interoperator diagnostics if some hiding function provided at an edge.

Document currently uses Warning header 399, which implies no automated action, but some comments have been made that automated responses may be interesting.

Slide 4: Should a limit be set on response size? Very large UDP responses may fragement so much that no response reaches the request originator? Should that limit apply to all responses? If yes, what size? There is no documented limit Scott can find on response sizes (request sizes, but not responses). Do we need a response to say my response is too big? Presenter would prefer to duck this issue in this specific draft.

WG chair indicated that until this problem is resolved in some manner, then this draft will not progress.

Discussion:

We could trim off via's, etc. If UAC needs them it can sip trace-route.
Presenter: Draft allows exactly that to occur is so wish. Could also strip off mirrored headers. Concern about not being reversable (NAPTR choices, etc.).
But repeating the message does not ensure the same path. Different path could create different error. Does not solve general problem of response size.
Possible useful things in congestion-safety draft
3261 did not limit response size because at the time, the responses were generally the same size as the requests, so the request limit mostly limited the response. Put lower than MTU size on the request, then hope the response did not grow beyond the MTU size.
Presenter: Is this assumption still true. Many SIP assumptions are not true any more.
need limit, much larger than request because of Record-Route, etc. How to get fragments through NATs and Firewalls.
Why not consider content redirection? Some responses get quite large (488, etc.) - may not even want all this stuff, let proxy store and diagnostics retrieve?
Presenter: Is there a likelihood of connecting HTTP seventy hops away?
If the response gets fragmented, we could get retransmissions that may be worse than not having the diagnostic info in first place. Not a completely useless response if it tells you to stop retransmitting.
Suggestion of a 200 byte limit for diagnostic information. The request limit was chosen assuming that responses would not usually add more than 200 bytes to request size. Last hop before UDP to TCP will be at the size limit. Not an obvious answer on this.

Conclusion: Document not ready for WGLC. Editor will introduce at least two threads on issues raised in meeting. No objection to use of Warning header. Message size must go to list.

Connected Identity (draft-ietf-sip-connected-identity, draft-elwell-sip-tispan-connected-identity)

Slides: sip-15.pdf

John Elwell presenting.

Slide 2: need for option-tag to indicate UAS support for the identity header field in mid-dialog requests? Saves UPDATE transaction after answer if the AoR is the same as To header. However yet another option tag. Will anyone support id-change without supporting connected-identity? Email suggestion to make it dependent on receipt of id header.

Proposal: Don't need new option tag

Conclusion: Proposal accepted – a new option tag will not be provided.

Slide 3: sip-identity is silent on how to behave if identity in "From" header field is not one that authenticated UAC is allowed to assert. Left to local policy, but this policy may be different for mid-dialog requests compared to initial requests. Just add a note saying this?

Proposal: Add a note to indicate that it is effectively left to local policy whether to reject or forward without identity header.

Discussion:

reasonable but applies to Identity draft, too, right?
blanket note in draft-ietf-sip-identity about local policy, but isn't after every paragraph.

Conclusion: Proposal to add note accepted

Slide 4: Should we mandate UPDATE for sending connected-identity rather than reINVITE. Could make 3311 mandatory to support if you support id-change tag.

Discussion:

what about implementations that don't do update?
who can deal with identity should be able to do update

Proposal: If you support this extention, you must support UPDATE extension.

Conclusion: Accepted

Slide 5: Should we mandate inclusion of SDP offer in UPDATE request? Not strictly necessary. But would be signed, in same way that SDP offer in INVITE request is signed

Discussion:

Only useful if you mandate signed SDP. Up to implementors, but implementors have to deal with the damage. Should call sdp in update out as something you can do, but don't require it.
just needs a way for this to be possible

Conclusion: Not required. It needs to be optional. Allow this if you wish, but do not require.

Slide 6: Should To header field URI in response be allowed to differ from the request? Body of opinion that says that this is an entirely different consideration from the one in Vancouver that led to decision to allow From header field URI to change in mid-dialog requests. No warning in RFC3261 that such a relaxation might occur in the future (unlike the From URI change). Body of opinion that says it would not be useful. Body of opinion that says it doesn't harm anything. TISPAN requirements.

Leads into requirements from slide 7, slide 8, slide 9, slide 10, slide 11, slide 12 (draft-elwell-sip-tispan-connectedidentity), e.g. TISPAN needs two identies each for caller and callee - one identity is used for billing, the other is used for call-backs. For caller's identities, the proposal is to use PAI (P-Asserted-Inentity) for billing-id, and "From" for call-back-id. For callee's identities, the proposal is to use PAI for one of ids, and there are a number of options for carrying the other identity - To header, "From" of a new UPDATE request from callee to caller, etc. Note written at same time as the identity coexistence draft was put out, so conflicts could not be dealt with.

Discussion:

TISPAN does not get to change what the

identity semantics mean without going through sipchange process. The P-Asserted-ID has well defined values, and TISPAN is trying to change that. TISPAN is not allowed to do this.
Keith: Does not redefine P-Asserted-ID - just says what will be put in P-AID.
Interop problems with lots of people taking different views. If each group redefines how identities are interpreted, nothing will interoperate
TISPAN is just saying that the From header says who the caller thinks he is, P-AID is who the network things he is. TISPAN thinks the different is useful.
PSTN does not know the difference, only that P-AID is an authenticated ID.
Using PAI for billing.
Have the understanding that PAI will be used for callbacks as well. P-Asserted-ID must contain a reachable AOR.
P-Asserted-ID has lost focus on what it means. Is being used by enterprises. Hard to know which one to trust.
AD: Can we use something like P-Charging-Vector to carry the billing. : This may imply we need a billing ID. Could the 3gpp charging related headers be used? There are real interop issues here on what to use for callback number and caller-id presentation. May need discussion with liaison. May need to spec a real charging vector. Not sure if he has captured the problem.
Agrees with that P-Asserted ID doesn't work as a charging vector. There are situations where this make sense when you want to change the callback number.
3 problems: who to bill, who to call back, what sort of subcategory of user is the caller a part of.

Proposal: Does the editor fall back and specify requirements around this in tispan-connected-identity? No. The proposed solution is separable and could therefore be covered in another draft and therefore it is separable from the connected identity issue.

Conclusion: Connected identity will proceed without this.

Further discussions on the mailing list on the TISPAN requirements.

Editorial question: Based on RFC 4485 requirement to show real identities, do we need correct values for identity header field, along with a real private key, etc. (as in identity).

Cullen Jennings: Please do this, hard to get this correctly and I'll do this for you because it's hard. Still getting this nailed with Jon in AUTH48 for draft-ietf-sip-identity, didn't have the same answer from two separate implementations.

Security Flows (draft-ietf-sip-sec-flows)

Slides: sip-12.pdf

Robert Sparks presenting.

Working on creating examples with automated tool. Otherwise getting them right is difficult.

Matching certificates rules aren't adequately captured; spread out and not completely clear. This document is not normative, so they will not be captured in this document.

WG chair asked if this fed into the security-guidelines draft to be discussed later in the session.

AD: Should refer to 2818 rules as often as we can, but RFC 2818 is informational, and this is already hitting drafts now. Will be better when IESG gets the downref rules completed.

Lots of implementations match wildcards in DNS names, this is an education issue.

On finishing generation of examples, he will shortly submit a draft for WGLC and publication.

Addressing the Forking Amplification Vulnerability (draft-ietf-sip-fork-loop-fix)

Slides: sip-11.pdf

Robert Sparks presenting

Slide 2: Latest version demonstrates the attack with one resource and one attacker, rather than multiple attackers. Reintroduces some of the motivational text in the security consideration section (based on conversations with Cullen). Updates the 3261 text on loop detection. Identifies open issues. Added notes to implementers pointing to common interop problems at earlier SIPits.

One Suggestion on mailing list not yet in draft: - Don't start loop detection until you've gone around at least once – wait until you see yourself earlier in the via stack. This is an optimisation based on normally not going to hit this. Requires extra logic which gives no major advantage.

Conclusion: WG agrees that this optimisation will not be included in the draft.

Slide 3: In the computed hash, why include all route values, callid, to-tag, from-tag, proxy-require, proxy-authorization headers? Call id, to tag, from tag don't need to be there as they are invariant. Proposal is to leave these out.

- why proxy require, proxy auith

Discussion:

we had reasons for all of these but not written down and no one remembers why. Can think of Proxy-Require justifications, but Proxy knows what header fields it would look at for routing purposes on additional passes - does it really?
Presenter: Normatively says anything you are using to compute route goes in the hash—would cover this case.

Conclusion: Will leave items out of hash computation unless something comes up in lists. Send specific issue to list.

Feature Creeps - Advancing the SIP Standard - Documenting the feature sets

Slides: sip-13.pdf

Robert Sparks presenting.

Task of identifying the feature sets to advance the standard. Work is just getting started. Want to avoid exponential explosion of must/should/may features, so slide 2 contains an example.

There will brain-stroming on this topic in global.sipit.net. Wiki will be used so anybody can participate. The expectation is to have an initial draft by the San

Diego meeting.

WG chair: Please send out invitation to enable participation in this effort.

Discussion:

Does progression effort make sense after newtrk discussion.
Presenter: Other things motivate this work as well. Building interoperability.
Need to make strategic decision on whether a bug-fix doc should become a 3261bis effort.
Presenter: Proposal on this coming out later. One motivation is to determine what was stable and what was still rough
Useful for feature compliance statements. "compliance to 3261" must/may/should is absurd, need help here, there is value, whether we go to draft or not.
Call flows more interesting for implementors.

Hitchhiker's Guide (draft-ietf-sip-hitchhikers-guide)

Slides: sip-16.pdf

Jonathan Rosenberg presenting.

Adopted as WG item. Removed SIP family discussion of specifications text; this is out of focus for the SIP WG itself. Redefined what's in scope for the document (MIME usage specific to SIP only, SDP stuff), Redefined what's a core spec – something that will be used for every call. Added conferencing topic area, telephony specs, minor extensions. Reference [42] is Hitchiker's Guide book, there's a towel reference.

Issue: When is document done? Proposal A: - Split core into a separate document, issue immediately; rest of it goes much later. Proposal B: Keep as one document, pick a point at which we decide to issue, revise later on. Suggestion: Proposal B

Discussion:

keep together and revise.
RFC 4510 all went out as one big chunk for LDAP, but maybe there is experience here. Roadmap which says this is LDAP, but with this document waited until all finished.
change the name? need official-sounding name?
Presenter disagrees, maybe people don't get the cultural reference but this is not offensive.

Consensus on A or B will be determined on the list.

Request for comments from editor.

SIPS: Guidelines (draft-audet-sip-sips-guidelines)

Insufficient time for detailed discussion and will be discussed further in the ad-hoc session to follow this meeting.

However WG chairs wanted to gain a view on the need for an informative document to explain what we have and what we mean. Document will not contain any normative changes, which would progress separately.

Discussion:

More we dig under this rock, uglier the problem becomes. We have a big problem, not sure we can fix them.
AD: does anyone think there's NOT a problem? General derisive laughter.
The more we get into this work, the more we will realize what less we have got!
Francois Audet: Third revision based on list discussion. Does not think we can fix this without normative fixes. Does not believe anyone has successfully implemented SIPS.

WG chairs: Any objections to proceeding with an informative document? Will ask ADs to add this to the charter.

There was consensus to add this to the charter.

SIP Security Breakout

Issue Framing by Cullen Jennings

We have an interesting problem, based on list review, but there's a lot to look at. Need to pick specific problems.

ICON for "secure phone call" - what does that mean? Some is "local policy". Encrypted media? Know who you're talking to? Knowing the person you dialed is the person who answered? Knowing no one snooped your signaling? Some binding between all these things - this is what the "hopping bunny" was about.
SIPS: URL does NOT mean ANY of these things.
What ciphers are acceptable?
Problems for SIP, AVT, MMUSIC...
Problems on TLS and SIPS: - bugs and unclarities, see Francois draft. May even have contradictions in specs, need to resolve confusion. A ton of people have "implemented" TLS and even SIPS: but not clear what works. "TLS across all the hops, or almost all, or anything..." Hard to define, retargeting, ... SIP goes one direction with retargeting, but SIPS: never thought about the other direction. Have to decide what we want to do. Have to be symmetric. "Secure" always TLS? See problems with IPsec...

Discussion commenced here.

Dean - current document problem - no way to know that all nodes complied to the spec in the middle.

Brian - we either transitively trusting or we aren't. We have to choose.

But we have requirements for end-to-end security, too.
Can we assume transitive trust?
Jon - if there's a SIPS URI that's signed, that's a comfort at the other end, but it's a small comfort.
Can we agree on transitive trust?
Simplifies scope but doesn't guarantee solution.

Jon - EKR suggested something like SIPS in the document (RFC 3261), and this was late in the process, threat model pretty much worked out but SIPS inserted quickly (too quickly? and carelessly). Probably a number of problems to address.

draft-audet-sip-sips-guidelines-02

"At best underspecified" and probably wrong. Started 00 to explain how we were right ("we're the IETF"), and every version of the draft gets worse.
Need to make some decisions pretty soon. People are developing this now. Implementations don't have that much to do with 3261.
Vijay - specific problems - upgrade/downgrade, transport=tls (deprecated). Can be implemented, but there are problems.
Six sections in the draft - meaning of SIPS, upgrading/downgrading, SIPS registration, SIPS dialog, transport=tls, a lot of other issues (GRUU, outbound, REFER, background).
Meaning of SIPS - TLS for each hop until terminating domain.
Jonathan - intent is that last link is secure (somehow).
Biggest problem is that we're not symmetrical for reverse path - in-dialog requests cannot work.
Does not mean a Padlock icon, requires Record-Route or things get dangerous quickly with SIPS Contacts.
Jon - issue was assumption that UA would not be able to accept incoming TLS connections - and assume that the reverse path would work the same way ("secure in some sense").
"Support SIPS" is "support TLS connection to remote first-hop proxy".
The part that's broken is that people assume UAs don't have to support SIPS. They do, in order to make outgoing calls.
Dean - Proxy is SIPS/SIP converter (in Dean's remembered vision).
Record-Route and Contact interaction is not limited to SIPS.
Jon - once we have outbound, we're in a position to do this right.

Discussion of suggestions from list: deprecate SIPS altogether, deprecate last-hop exception (not sufficient alone), explain the exception and fix the bugs that result. Draft assumes third choice, but lots of people like deprecating last-hop exception. People liked deprecating SIPS, too... Noted that we need to accommodate 3GPP here.

Do people think we should deprecate SIPS? More chaos, people have implemented SIPS. Juha said "broken for now" note until we fix it - Francois' draft is that note :-)

Don't think SIPS works at all on a business card, or in to/from. Can't use a padlock hop-by-hop.
What does "deprecate" mean? Telling someone that SIPS will almost never work?
EKR - point of SIPS is to provide given level of security. Does it work? Problem is TLS ending at proxy.
Scott - "SIPS is broken"? Want to be able to say a particular connection must be made over TLS. Sometimes, that's the only thing that works. Need to be able to say "secure" about particular hops.

Jonathan - we have many documents with "use SIPS" as security considerations for relationships between proxies and clients. That is reasonably useful, even if it's not end-to-end, even if you need to trust middleboxes.
Francois - can't deprecate, too pervasive.
What do we expect to get out of SIPS? Need to know this to know if it's useful.
There is a real threat being solved, preventing people snooping or modifying requests.
This is everywhere in the document set. "Use SIPS" is the "use IPSEC" of SIP.
Don't need to change the meaning of SIPS in this group. Need to focus on the real problems - last-hop, explanation Jon gave at beginning of the meeting.
EKR - wouldn't it be great if we had end-to-end security, or even integrity? In SIP, like it or not, trust model is that proxies can screw you anyway they want. With that, SIPS is useful, but not for lock displays.
Scott - agree with EKR, start by explaining the meaning of SIPS. Clarify whether it's about signaling, and how far. Doesn't cover media (which is what people actually think about, and a totally different problem). I want TLS protection until I get to something with the certificate that matches the request URI. I understand semantics are different but think this needs to be clarified. Francois has made a start at this.

Options - deprecate SIPS, explain what SIPS means, allow transport=tls.

We have consensus that we will not deprecate SIPS.

Transport=tls was formally deprecated, but no one believes this and many/most implementations still understand and will use this.

Allows for "best effort" hop-by-hop TLS usage. Endpoints that cannot have a DNS entry can't have own certificates anyway.

(Also need to add a transport=tls-sctp (like Via) - would be more consistent, too)

Jon is confused here. how to start supporting TLS for one hop? But this isn't about SIPS right now, right? We'll table this now.

Registration issue:

Some people infer "must use TLS on REGISTER", etc. from current documents.
Registration: AOR - SIP implies SIPS, this is a big problem since many, if not all, UAs cannot process SIPS URIs. New way to explicitly register SIP only?
If you only register SIPS, you haven't registered SIP - this is not symmetrical, either (more comfortable with upgrading than downgrading?) Is this broken? Not sure why we're indicating that you have only one or the other AOR...
Interaction with Outbound - create a TLS path to home proxy, so proxy can send either SIP or SIPS to you over TLS ) which is what you're asking for.
SIP and SIPS as separate registrations? Cullen - this would always work. Can we imply an upgrade path where one always implies the other? Which way?
Francois - not backward compatible. If you send SIPS to most clients you'll be in trouble. This is an AOR, right? It's equivalent to being a different user. Or at least using a different port.
Jon - great explanation by Jonathan but that's not in 3261 - Jonathan agrees, this is the way to move forward. "URIs are never equivalent" text does exist, but so does text that says both need to exist as aliases.
Francois - some people are thinking you should derive reachability from the transport you used for your registration.
EKR - SIPS means "TLS all the way somewhere". SIP means "maybe over TLS, maybe not", and can't expect people downstream to use TLS or it may not work.
Does it matter which AOR you use?
Jon - if you're registering a SIP URI, can't expect you'll be able to do SIPS.
Francois - if you don't use outbound, what does this mean?
Jon - use whatever channel you've got.
Francois - was assuming the opposite (SIPS would imply only SIPS, SIP would imply both).
Registration contacts - list explicitly all valid transports, using q-values?
Jonathan - clarifying 3261 without changing it, right? Pointless. Let's start over and do this requiring SIP outbound.
Jon - Outbound isn't done yet.
Jonathan - This is done first?

Proposal - write a standards-track document that fixes 3261 and requires outbound?

Keith - need to look closely at normative change process - do guidelines document PLUS fixing 3261 document.
Francois - need to agree on normative changes - then we can split.
Aki - I like SIP in contacts, to, from. With outbound, contact doesn't matter anyway. Don't put it in to/from/contact.
Paul - when do we get clarification? No one knows what it will take to fix this stuff (or at least not sure you're talking about the same thing).
Francois - don't pretend every statement in 3261 is correct.
Jonathan - we have 200 bugs in Bugzilla - why would we question this?
Jason - SIPS:transport=tcp?
Robert - what does that mean in a route header? TLS one hop away?
Scott - back to the current definition of how many hops you use TLS (until you reach the named destination domain).
Jonathan - have proposed change to location lookup - add route header. We screwed this up in 3261?
Scott - if you let UA register SIPS URI with non-SIPS contact, that's an explicit action on the part of the user.
Cullen - I think I agree here.
How to deal with Contacts in REGISTER, Record-route, contact in dialog...
Jon - hum on fixing 3261 instead of apologizing?
Francois - thought we were making a proposal to fix in next revision.

Next steps - to list.

Jon - need to know how this works with outbound in order to make recommendations.

draft-gurbani-sip-sipsec-00.txt

Do SIPS the way HTTPS works - end-to-end upgrade?

EKR - HTTPS blows through proxies, "get out of my way". Not what we're talking about now.
Cullen - if we didn't Record-Route, we'd get the same thing in SIP.
Cullen - Dean arguing for something that only works if there are no proxies. Interesting, scenario does exist, but this isn't the main case. This is why we don't encrypt headers.
EKR - 18 proxies between point A and point B are there for a reason, not just forwarding packets.
We'll talk about this more on Friday afternoon (at P2P-SIP).
Vijay - we talked about this on the list, and there are people who want their proxies to stay involved.
Cullen - most of the proxy twiddlings are in 3261 as threats, and the answer was "use end-to-end security".
EKR - this creates a generic NAT traversal server mechanism. Once you're in TLS, go crazy. There's like one proxy between you and an HTTPS server.

draft-srivastava-sip-e2e-ciphersuites-00

Led by Samir Srivastava

Slides presented.

Principle argument: Level of security is missing. SIPS is a mess. Should DTLS be considered as well?

Proposal: Extend Via to include Ciphersuites, define header for desired cipher-suites, secure protocol, etc.

EKR has an alternative solution - let TLS take care of ciphersuites at each hop, rely on mandatory-to-implement as common-denominator, trust proxies for mandatory upgrade/downgrade.
Jonathan - with EKR on this one, proxies can do so many things that are worse.
SS thinking of catching evil proxies more quickly, allow UAC to control ciphersuite selection.
SIP Security advisor says there's a hole in this. Would Security ADs pass this document?
EKR - current security is worse, right?
Dean - this catches stupid proxies. Evil proxies lie.
EKR - in TLS, your client has no control over what the server actually chooses, right?
Proxies doing DTLS to TLS need to know ciphersuites for other protocols.
Open issues - which solution to pick? Partial adoption with SIPS? Impact of renegotiation of ciphersuites needs to be analyzed?
Has anyone else read the draft? 5 or 6. Anyone who might implement?
John - I thought so, not so sure now if we're trusting proxies.
Dean - need a mechanism for Proxy A and Proxy C to keep an eye on Proxy B - this could be it.
Discussions about SIP and TLS don't state problems and then argue about details, so never come to conclusions. Need starkly clear statement of problem and benefit to users.

Conclusion: Please respin, focusing on problem statement, and we'll look at this again.