[Sip] Draft minutes for IETF 66

Ok, folks. Here's the first pass at the minutes for IETF 66.  Please  
excuse the HTML, but it seems to be fashionable for the proceedings.

They're also webbed at:

http://www.softarmor.com/sipwg/meets/ietf66/notes/minutes-sip- 
ietf66.html

Please respond with any corrections on the list.

Session Initiation Protocol (SIP) WG

Minutes edited by Keith Drage, with Security Breakout edited by Dean  
Willis

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.