| Topic | Discussion Leaders | Reading List | My
Notes |
|---|---|---|---|
| Agenda Bash, Announcements and Status | Chairs | This Doc | |
| Outbound | Rohan Mahy | draft-ietf-sip-outbound-04 | Have identified a STUN UDP DOS
esposire in current draft - when STUN response indicates changed mapped
address. Can cause amplification - Jonathan doesn't agree (2x doesn't
seem like a serious amplification problem). Can solve this by having
timer apply (it's not in the current draft). Cullen doesn't worry about this attack because there are so many other attacks to worry about. Wireless has problems anyway without security. Two separate issues on STUN discovery - support and validating support. Draft says STUN support is "configured" (whatever that means). Do we need another way of discovering? Could define other mechanisms later... without slowing this document down. Robert Sparks asked about proxy-require - but this helps with validation, not with discovery. Francois Audet said his feedback was that something will turn this on or off, not worth delaying to define something too complicated anyway. Bob Penfield - Jonathan was proposing STUN=keepalive, right? I really like this one, because configuring in the phone is key to getting deployment anyway. Validation concerns are about confusing next-hops with misconfiguration, especially for TCP. Is this a problem? Robert thinks we need proxy-require OUTBOUND, not SIP-STUN. That would solve this problem, too. Hisham - if we don't solve LR problem won't solve this. Cullen agrees. Jonathan - how can we make progress if the people on opposite sides aren't in the room? Hadriel - don't do this, not needed. Robert - who has read the draft and agrees? a few. Bob Penfield - if you put this in the service-route, I'll be happy. Jonathan - but what I'm supporting for service-route is change and incompatible with 3GPP. Don't hold up this document for validation. Do you have to REGISTER before you send STUN? No, but we could require this. Dale Worley - may be tied to validation issue - may not be independent. Is keepalive=stun sufficient with no validation? Francois - what is the problem? You said you supported STUN but you don't. Why worry about this? Rohan - can't stick stun=keepalive in all URIs everywhere - can't be handed by DHCP to entire network. Jonathan - add cautious words and then move on, don't hold up document while we work this out. Don't wait on service-route. Heshem - is the problem that you'll crash a server? No, just that you may lose framing, especially in TCP. Ben Campbell - lots of ways to misconfigure UAs. Robert Sparks - this version is better than the previous one, it's important, people are getting their teeth into it, don't hold up the draft. Rohan - looks like we have rough consensus in the room to go forward. How many flows (minimum)? We said MUST REGISTER to each outbound proxy. Could this be a SHOULD? Proposal is to change to SHOULD. Jonathan - SHOULD with caveat - don't violate unless you are protecting short battery life, etc. Dale - one registration tends to cause participation in avalanche restart problems - need to say "be careful". Additional discovery semantics - we don't have requirements for this, can't begin to include in a current spec. Rohan will ignore request unless told otherwise. Registrar sending to edge proxy over same connection - text is incredibly confusing, even to Rohan authoring text. If you can help, please contact Rohan. How does registrar actually know edge proxy supports outbound? Proposal is new parameter ("ob") (same as RFC 3261 style). Robert Sparks - thinks this is OK - don't have time to discuss in meeting, please talk to Rohan. Re-registering with same REG-ID - Dave Oran has asked for a SHOULD that would accommodate a private use case, but Dallas hum was that WG was uncomfortable with replacing flows - but people have been more comfortable on-list. Need to recalibrate here. Jonathan - new draft almost forces replacement. If two registrations are equal, one must replace the other. Will go back to "SHOULD replace flows"? Cullen asked for positive indication. Various shows of hands are for MUST, with one strong objection. Jonathan did a rant on "not a MUST, it's true by definition". Erkki pointed out that registration refresh has to go over original flow ("duh, and thank you"). 410 response code is wrong ("permanently gone") Should use 480 instead ("temporarily gone") because the flow went away (not the resource). |
| Outbound Discovery | Miguel Garcia for Erkki Koivusalo |
draft-koivusalo-sip-outbound-discovery-02 | Problem definition,
requirements, solutions, evaluation and specification - all in one
small document. Agreed new service type, at cost of five new NAPTR service types. Need to synchronize with OUTBOUND. Should synchronize with PROXY-FARM as well? Set up number of flows in this draft or in OUTBOUND? Rohan has proposal (not sent to list yet) - could DATA URI be used with number-of-flows in DNS? Henning - concerned that we are dispersing configuration information 17 places with no architecture, ad hoc. Why not put it all in DNS and forget the configuration framework that's not going anywhere in five years anyway? Jonathan - concerned 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. Adopt as WG draft? Will take this to the list to discuss. |
| Outbound Midcall Issues | Kevin Johns | draft-johns-sip-outbound-middialog-draft-00 | Presentation includes several
use cases. Looking for feedback from the working group. Rohan said GRUU draft does have some overlap here - should describe how to do outbound mid-dialog requests. Jonathan disagrees - Path is not replaced in GRUU. Document is needed, but not in GRUU. Dean - put this in OUTBOUND? Cullen - this was violently discussed in Vancouver. Dean - is a real problem, don't have consensus on how to deal with it. Keep working on the problem? Rohan - is this for everything, or non-GRUU, or ... need to figure this out soon. |
| Connection Reuse | Vijay Gurbani Rohan Mahy |
draft-ietf-sip-connect-reuse-05
draft-gurbani-sip-domain-certs-01 |
Draft is essentially complete,
need text on virtual hosting. Cullen - what text? Would like to get domain-certs work done first. Web model for Web works for SIP, to certain extent, but there are corner cases. DNS: in certificates are a problem. EKR - other problems? TLS isn't designed to work without a fixed name in the certificate, don't do this, it doesn't work. Henning - either buy specific certificate or wildcard - is that what you're trying to accomplish? EKR - no matter how many servers you have in your farm, they have one name. You can fight that, but you'll lose. Jon - I know we have problems in 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. Dale - 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. Multiple names solves this problem - is that the answer? Jonathan - 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. Cullen - "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? EKR - 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. Dale - 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. Vijay likes two names in a certificate, too. Domain name in the certificate has to match the host you're talking to, otherwise you're talking to someone else. Dean - like domain keys for SIP. Jon - 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. Jim Fenton - 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. EKR - 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. Brian Rosen - propose we end conversation here. Wildcards can work, we have enough of a solution, let's stop with that. How do servers authenticate clients? From, Via, ... name in certificate. Cullen - the name it pulls out of a certificate is the right answer - based on a name, doesn't have to match anything. Jonathan - make that look like client-server, just in other direction. This is the only algorithm I could come up with that works. Have to separate authentication from validation. Vijay - proposal normatively updates RFC 3261 in lots of places. |
| Topic | Discussion Leaders | Reading List | My
Notes |
|---|---|---|---|
| Agenda Bash | Chairs | This Doc | |
| Location Conveyance | James Polk | draft-ietf-sip-location-conveyance-03 | Open issues... Moving all requirements to appendix. - just later in the document, needs to be consistent across documents. Will carve out a "basic operation" section without normative text, matching flows for each scenario in Section 1. Sections 4 and 5 restructured to be per-element behavior for compliance with RFC 4485. Reduce the text in section 2 (artifact of in-a-header vs in-a-body discussion a year ago). List applicable/non-applicable SIP methods in the Abstract? Adam - agree that leaving this out and saying "applies to these types of things, may apply to others" is fine. Don't rule stuff out of scope in this document. Jonathan - proposed using this in REGISTER during ECRIT yesterday. Hisham - too much text in the abstract for a complete list. Keith - just need to be clearer about pull vs push in Abstract - will say this more clearly on the list. Hannes - just improving Abstract text, not changing scope of dcument. S/MIME encrypt in all cases initially, and back off if error encountered? Not comfortable increasing setup time. Henning - S/MIME only works 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. Include a base64 PIDF-LO equivalent in Location header? Goes against previous guidance from ADs and chairs since Vienna? Hannes - no, this isn't actually what we said "no" to. Jon - all the alternatives are bad. Henning - DATA URL with MIME type and base64-encoded whatever - no technical reason this wouldn't work, maybe efficiency reasons to do this. Dean - will this work with UDP? 30-percent expansion. Keith - please have this discussion on the list. Jon - not the size, it's the layers, when we stick body stuff in headers. Don't want a deep rant because we've had them. Motivation is to let middle boxes dork with bodies that we won't let them dork with as bodies. Need a lot more consideration than "is this possible?" Hannes - current approach, SIP proxy can only attach a reference, then need to retrieve PIDF-LO, and that takes time. Henning - message body should not be used for call routing and should not be modified, and this is exactly what this is doing. James is amazed that we have consensus on not using bodies for routing. Rohan pointed to Boston interim. Should location be allowed in responses? Is HTTP required to be used by a location receiver in order to derefence? Will get more reviews and rev doc soon. Keith - 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 | Jason Fischl | draft-ietf-sip-saml-00 | Moved to WG document, addressed
Vijay feedback. Example assertions, added references and restructured document. Normative considerations... Meeting only trait-based AUTHZ requirements? If so, doesn't need to meet requirements of several other documents (sip-payment, SIP CPC, SPIT). SAML assertions in SIP header by VALUE? Discussing on SIP-SAML. Jonathan - covers requirements, sent detailed review recently. Couple of issues - binding of SAML assertion to SIP call itself, because SAML assertion more long-lived than SIP call. - maybe misunderstood, but Jason will look at list comments. Hannes - want call-ID, etc. in SAML assertion? Jonathan worried about swapped assertions from previous calls made by same SIP entitiy. Jon - problem is that we're doing something besides just delivering a cert - it's a signature over data. Jonathan has use case for SAML assertion reuse that shouldn't have worked, but will talk about this on the list. Jonathan - Identity-Info reuse is backward-compatible issue with SIP-Identity. Jon - making SIP-Identity fix in AUTH-48 to allow CID, etc. allow broader choice of URI schemes. Need a way to disambiguate URIs. |
| Certificates. Arboreal Rodents Or Fruitless Canine Vocalization? |
Jason Fischl | draft-ietf-sip-certs-01 | How many people have reviewed
document? Will implement? Lots of people have reviewed, are
implementing or will implement. Will go to WGLC in a couple of weeks - if you're going to scream, do it really soon, onlist. |
| Hop Limit Diagnostics Is my bunny sick? |
Scott Lawrence | draft-ietf-sip-hop-limit-diagnostics-03.txt | Request gets included in the
body of a 483 "too many hops" response? Cullen - document hasn't been adopted by WG yet, has NOT been through WGLC. It's on a list to be added with a milestone. Return for other unrecoverable errors? Would be useful for several 400s and one 500 (502 bad gateway).. Jonathan - happy to do this, not sure if I agree with this list. Generally for proxy-related errors, and for protocol-related failures, not for policy-related failures. Use Warning header for something besides SDP? IANA registry says "used for SDP". But this isn't what the RFCs said, and Henning and Jonathan can't remember any grand architectural justification for the IANA restriction. Would make more sense to reuse than pick something else for religious reasons. Specific Warning code (currently using 399)? EKR - encrypted body? Returns sipfrag of headers, not body. Robert - use another header. Scott - seeing SDP-style problems with things besides SDP. Could add IANA considerations that make this change. 399 says "do not take automated action" - traceroute would be obvious thing to do. What is limit on response sizes? There is no documented limit Scott can find on response sizes (request sizes, but not responses). Concern about fragmentation and resulting loss. Dean - this has to be resolved in order to progress. Don't do fundamental limits in diagnostic draft! There is an old one in this area on congestion safety... Why not strip older information off? This is allowed. Could also strip off mirrored headers. Concern about not being reversable (NAPTR choices, etc.). Jonathan - 3261 didn't have a lot of experience with sizes - picked 1300-byte limit on requests and pray that responses aren't too much bigger. Is this assumption still true? Many SIP assumptions are not true any more... Hadriel - need limit, much larger than request because of Record-Route, etc. How to get fragments through NATs and Firewalls. Could retrieve indirectly? Some responses get quite large (488, etc.) - may not even want all this stuff, let proxy store and diagnostics retrieve? Is there a likelihood of connecting HTTP seventy hops away? Not a completely useless response if it tells you to stop retransmitting... Jonathan - in loop cases, seriously limited to 200 byte additions. Last hop before UDP to TCP will be at the size limit. Not an obvious answer on this. Keith - question was actually "when we get the charter, is this document ready for WGLC?" Answer is "no". Scott will start at least two threads on topics raised in this meeting. |
| Connected Identity | John Elwell | draft-ietf-sip-connected-identity-00
draft-elwell-sip-tispan-connected-identity-01 |
Need for option tag to indicate
UAS support for Indentity header field in mid-dialog requests? Will anyone support id-change without supporting connected-identity? How to behave if From header Identity is not the one authenticated UAC is allowed to assert? Left to local policy, may be different for mid-dialog requests. Just add a note saying this? Francois - reasonable but applies to Indentity draft, too, right? Jon - blanket note in SIP-identity about local policy, but isn't after every paragraph. Mandate UPDATE for reinvite exchanges? Fewer messages, but offer-answer exchange could be signed. Up to implementors, but implementors have to deal with the damage. Rohan - anyone who can do SIP Identity will have no problem with UPDATE... Heard one voice against this, but nothing during the meeting - will require UPDATE support. Mandate SDP offer in UPDATE? Not necessary, but could be signed. Robert - to be useful, signing has to be mandated, that's crazy. Allow but do not mandate. Dan Wing - agree with Robert, just need a way for this to be possible. Open issues - To header in response differs from the request? No 3261 warning that this might be allowed in the future. Opinions - wouldn't be useful/wouldn't harm anything. Results in TISPAN connected identity draft requirements for two identity deliveries. Thought mailing list consensus that this was acceptable, started at this point (rightly or wrongly). Uses PAI for first identity, To in response, but requires To header change in response, can't be authenticated without connected-identity draft. How to handle at PSTN gateway? how does gateway know that 200 OK to INVITE will be followed by UPDATE request with revised/authenticated URI? Add option tag? Overload previously-discussed option tag? Five options mentioned in draft. Add tag and mandate UPDATE? Or do nothing? Jonathan - conflicts with coexistence draft, but have fundamental beef because TISPAN doesn't get to define nature of TO header. This is total violation of IETF SIP change process. These fields have well-defined meanings for years. It's a process issue - help from liaisons? Keith - will respond on list, but this doesn't redefine PAI - it just says some value ends up in some header under some scenario and that's useful. Jonathan - doesn't make any sense. Identity is person who made the call. Causes massive interop problems, booming business for SBCs, but should be able to return a call based on headers, and that won't be true in all cases. Keith - caller and network can pick different identies in From and PAI now - TISPAN is trying to make use of what's allowed. Jonathan - yes, they CAN be different, but that doesn't mean you can pick the definitions of the differences. And I haven't even started the rant on the requirement they are working with. John - network doesn't know anything about identities on enterprise networks. Andrew is now as upset as Jonathan... Dean - I think enterpise PBXes work the way John is saying whether this draft goes forward or not. Jonathan - are we mandating that all enterprise callbacks go to the operator? Brian - this says "end user or end system" in the current approved text. Hadriel - asserted identity has lost its meaning, this is a problem for us, too. Dean - separate body of work to solve this problem, need more requirements and analysis to state the problem. Adam - don't codify shortcomings into new mechanisms. Cullen - this is putting a billing identifier in, right. Would 3GPP approach work? There is a real interop issue with other systems because of differences in uses. Don't have liaison in the room, but can work this with liaison. Brian - you have this exactly right. Started out with PAI as charging vector and it failed. May not want end user's identity shown to end users. Have been asked for this by customers. Martin - identity of user, billing number, trunk identifier. Not registering every user, not practical. Do correct values for Identuty header field need to be shown? Cullen - 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, didn't have the same answer... |
| Security Flows | Robert Sparks | draft-ietf-sip-sec-flows-01 | Matching certificates rules
aren't adequately captured. Remember this document is not normative. Jon - should refer to 2818 rules as often as we can, but 2818 is informational, and this is already biting drafts now. Will be better when IESG gets downref rules down. Lots of implementations match wildcards in DNS names, this is an education issue... |
| Fork loop fix | Robert Sparks | draft-ietf-sip-fork-loop-fix-02 | Have mostly been stripping text
out, but worked on 3261 text and found issues. Don't do look detection unless you see yourself in the Via stack earlier? Do not plan to include this optimization - no one spoke against this. Lots of "why?"s on computed hash - all route values, Call-ID, To, From, Proxy-Require, Proxy-Authentication. Jonathan - 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? |
| Feature list for advance specification | Robert Sparks | TBD | Just getting started, with WIKI
for inter-SIPit interop issues and information, will be used brainstorm
first set of features. Will do this maybe by San Diego. Henning - newtrk discussion - do progression efforts make any sense at all? Will be proposal about what to do with progressing vs bis-ing at PS soon. Jonathan - "compliance to 3261" must/may/should is absurd, need help here, there is value, whether we go to draft or not. Henning - more interesting for implementors. |
| Hitchhiker's Guide | Jonathan Rosenberg | draft-ietf-sip-hitchhikers-guide-00 | Adopted as WG item. Removed SIP family of specifications text. Redefined what's in scope (MIME, SDP), what's a core spec. Added conferencing topic area, telephony specs, minor extensions. Reference [42] is Hitchiker's Guide book, there's a towel reference. When is this document done? After we turn the lights out? A year and a half away for five years? Split or keep together and revise? Spencer likes keep together and revise. Jeff - 4510 all went out as one big chunk for LDAP, but maybe there is experience here. Sohel- change the name? need official-sounding name? Jonathan disagrees, but cultural reference is not offensive. Will ask about splitting on the list. If there's something missing, please let me know. |
| SIPS: Guidelines | Francois Audet | draft-audet-sip-sips-guidelines-02 | First document on SIPSEC agenda. More we dig under this rock, uglier the problem becomes. We have a big problem, not sure we can fix them. Jon - does anyone think there's NOT a problem? General derisive laughter... |