Session 1: Thursday 1300-1500 Grand Ballroom C
|
Topic |
Discussion leaders |
Reading List |
Discussion |
|
Agenda Bash and Status |
Chairs |
this document |
No agenda bashing noted. Very little response to CERT WGLC. Does anyone care about concent framework? Something like 30 people raised their hands - please go READ it! |
|
Outbound |
Rohan Mahy |
Substantial number of changes based on feedback plus non-controversial suggestions on the list. Late change - 410 Gone was wrong, 480 Temporarily Unavailable was wrong. 430 Flow Failed means exactly what it says. Added a "stable flow" timer - declare a flow "stable" when it's been up for 4 minutes, if restarting a flow that is not stable, wait some period of time before retrying. (helps with avalanche restart problem. Issue - no mention of rport at all in the draft. Will add text explaining that UA must put rport parameter in Via and send from port it's prepared to receive on. Jonathan - does disagree, this is obvious. There's a SIPPING document on NAT considerations. This is about SIP working, not about media working, there's more work to do here. Rohan - this will make something that's obvious to us, obvious to others. In addition to adding text on RPORT, will add informative reference to NAT scenarios document. Issue - verify outbound support on first hop, or on all hops? Jonathan - we haven't explored this area very much. You can end up in cases where you do want to extend outbound across administrative domains (enterprises and ISPs, for example). Only require checking for register and first hop proxy? Christer - with current scope, only supporting NATs in certain places, don't see need for addition, agree with registrar/first hop. No objections to this suggestion Rohan will make the suggested change. Issue - Rohan assumed max-flows parameter was out of scope, but visited network could specify more URIs in outbound-proxy-set than home registrar is prepared to handle. Return a max-flows header parameter in registration response? With what response code? Jonathan - increasingly convinced that visited proxy is a horrible idea (see IMS). Don't like the idea of yet more things that we have to negotiate. Would rather have a normative requirement about a minumum that everyone must support. Hadriel - is there a way to say "use only this proxy?" You'll try all the URIs you got in the SRV entry. Andrew - Max-flows that come from one place? Christer - home proxy has no clue how many URIs are provided by the visited proxy. Rohan - two URIs isn't a huge burden. Are people going to have significantly more than two? Andrew - three networks, two proxies in each, total of six URIs. Hadriel - some people seem to have a problem with two URIs... Jonathan - defer this to discovery process? Christer - can discuss this more, but this isn't part of discovery process. When it comes to additional functions, this can be a recommended value. Need recommended reponse code any time the home proxy has too many URIs. This could be 431, call it recommended value. Rohan - max-flows is a requirement? Humms seem to be in favor of deferral. Andrew - then we get a response code? Rohan - expect to do that on the list. Issue - Detecting instance-id binding rules. Can't tell if registrar used old or new binding rules. Proposal - ignore this, and fix later if we need to. Jonathan - from ICE discussion - UA sees that edge process isn't helping, could request public addresss/port and include that on its own behalf. Cullen - think of instance-id but not reg-id. Don't take this to the list, decide now. Decision - no change now, will fix problems if they occur. Issue - 3GPP has several requirements that outbound fixes, but don't want to use the flow-token behavior applicable to generic UAs on public Internet. They want separation of binding behavior and flow-token behavior, because their IPsec UDP uses several flows. Proposal - leave draft as is? relax flow-token language slightly, or replace reg-id with two new parameters? Jonathan - suggest relaxing language, this is needed for high-reliability stuff. Rohan - these are flow-id tokens in the PATH header, not RECORD-ROUTE. Dean - not going to conclude in two minutes - take this offline? We'll cut into GRUU. Christer - wrong to say 3GPP doesn't want to use flow token - this is about relaxing the text. Biggest requires is don't use NAT keepalive in cases where it's not needed (IMS). Rohan - anyone who would strongly object to relaxing language? No voices in the meeting. Jonathan - what happens now? Revise document, WGLC with parallel reviews, before Christmas. |
|
|
Domain Certs and Connection Reuse |
Vijay Gurbani |
What identities get stored in X.509 certificats for SIP clients and server. Two issues to solve - authoritative way to express purpose of the cert, way to identify host for the cert. Don't break names into SIP and DNS schemes. Use OIDs to enunciate the purpose of the certificate. Jonathan - there is another solution that doesn't fill up the DNS, Dean - two proxies that reuse connections - does Jonathan's suggestion remove texts that allow that? Jon Peterson - in our best interest to keep our certs as similar as possible to deploy more quickly. Requirements that don't match what you do today worry me. Scott Lawrence - I may want to use a certificate for a connection that doesn't go through the proxies. Cannot do the normal web thing of looking up the name in the cert and make sure they match. Jonathan - missing each other completely, doesn't have anything to do with draft I wrote. Cullen - trust chains don't have anything to do with DNS, glad to try to clarify this. This stuff is about SIP with TLS. Want to make sure we all agree on text. Scott - what about the name? That's the name we have in the certificate. EKR - all you can do is extract the name from the certificate and compare it to what you started with. You're assuming that you have many names, not sure why this is so. Jonathan - with Jon, don't like we have this multilayer construct that CAs have to understand. Scott - no way to order SIP certs from a CA. EKR - issue 1 is a node that starts don't SIP on behalf of a domain. Several quick comments, followed by "that's what extended certificates are good for" Jonathan - if we WANT to have a cert that's different, that's OK, I'm objecting to REQUIRING a cert that's different. Jon - offline it at this point, not going to finish in this room. Dean - chair proposal - please send heated comments to mailing list, will try to schedule WG conference call in next couple of weeks. Connect reuse - 07 is fairly complete. Cullen has identified one new issue, "TCP behavior contradicts Outbound". Jonathan - the problem is that I was only fixing mid-dialog failures, and then we used the mechanism for something else. Vijay - this draft didn't even talk about NATs because outbound wasn't around when it started. Cullen - the reason we took the NAT stuff out is because it didn't work.. Jason - is reducing the number of TCP connections between big proxies in the middle of the network where there are no NATs worth doing this work? Sense of the room is about 5:1 opposed to continuing this work. Hadriel - there is value when you have lots of small transactions. Is it worth this? Don't know. Keith - looks like people are not interested in doing this work here. Will confirm on the list. |
|
|
SIPS Guidelines |
Francois Audet |
Francois reminded us that this document is identifying options for improvement, not specifying improvements. Two revisions after 02 - one from Franois, and one from mailing list discussion. Call flows have been completely rewritten from 02 - please check closely. Dean sent trail balloon for "BCP for secure operation" on mailing list
Please look at To-Do list. Do we need new mechanisms, and why? Do we need to deprecate SIPS:? Dean - SIPS to PSTN is just as bad as SIPS to SIP. EKR - really are two pieces, intertwined. Would like you to call me using TLS, would like every proxy along the way to use TLS. Don't care about the syntax. How to put a secure URI on your business card? Key point is media, and this has nothing to do with media security. Eric - since SIPS doesn't do what we need, why not take it out? Problem of SIPS on derived connections is just not solveable (PSTN). Paul - what are the exceptions to SHOULD? If people aren't doing SHOULDs, we're holding out a false promise. Cullen - what you need to implement vs what you need to use - we don't distinguish here. I have a clear phrasing of SIPS as "all the way to the UA", but B2BUA doesn't count. This is a tool we use for other things. Dean - is it a BCP for an SBC to terminate SIPS onto SIP? Cullen - SBC terminating SIP onto SIPS would be great. Don't pretend that SIPS means anything beyond the UA. ??? - IMS with IPsec between SIP entities. Jon - this is not Francois' draft, it's everyone's draft. Heartened by consensus on at least some of the propose BCP priinciple Dean proposed. Wouldn't be opposed to PSTN termination of SIPS. Hadriel Kaplan - want to write a BCP, go right ahead, but people who don't agree with ignore it. If network operators think SBCs can terminate SIPS onto SIP, they will. Only want to deprecate something because it's dangerous, not because it isn't used. Dean - point of BCP is to document operational recommendations. Hadriel - just seems funny to write a BCP that says "be good". Dean - more like "if you leave your door unlocked, people may just walk in". John Elwell - SIPS has to stop at the UA, but am concerned about SBCs. If B2BUA downgrades SIPS to SIP, that's bad. Keith - now we will revise the draft to reflect what we said in the room. |
|
|
GRUU and Supporting Drafts |
Jonathan Rosenberg |
"Top 10 reasons why a whale is like a GRUU"... Have done a significant review with almost complete document rewrite. Biggest change is Temporary GRUU. Weren't thinking of privacy in GRUU, but EU privacy concerns made GRUU undeployable. Some concern about renameing parameters, but URI parameter and option tags weren't supposed to have the same value, anyway. Scott - "temporary" isn't right. Jonathan - it's not anonymous, either. Please tell me the name... Scott and Jonathan talked about details of the T-GRUU lifetime. Do people have problems with the current draft? Scott - does registrar always provide two? Jonathan - SHOULD strength to provide two, allows network providers to have policies that don't allow anonymous users, etc. Keith - people think the privacy mechanism needs to be in the document, but not sure about the mechanism itself. Humm on parameter name change? In favor of GRUU-11 names? Small plurality in favor of GRUU-11 in the room. GRID removal and loose route - Don't rewrite Request-URI (and parameters), push Route instead. Solves lots of problems. Will discuss any problems in this draft tomorrow. |