SIP Notes, March 20, 2006

Reported by Steve Donovan


Evaluation of minutes. Second day meeting is busier, may move items.


GRUU and Outbound WGLC. Certs and End to Middle mechanism stalled in WGLC.


First talk is on Connection Reuse. Vjay Gurbani. Reved to -05. Added statement that this is for peers w/direct connection. Removed stuff that was overlapping with outbound. Editorship includes Rohan, Vjay and Brett. Removed section which caused problems with DNS SRV. Reuse done using IP:port as the index. 


Jonathin commented that an implication is that you can’t open TCP from ephemeral ports. Vjay tried to explain that that is not the case, but Jonathan was unconvinced. Point taken offline.


Problem with using virtual proxy. Can you identify which node in the back you are actually be connected to. May interfere with the chance to use this with blacklist. Mic opened for comments. Rohan: The table mentioned on previous topic – mapping of Host:port to handle can cause problems in virtual host – do you have a list? Doesn’t feel that there have been sufficient comments to address this cleanly. 


Second issue with virtual host. Client 1 connects to a.com, Client 2 connects to b.com. There are some issues with connection. Is this important enough to deal with? Jason Fischl: clarification : does client 1 mean here a proxy? Yes. Question on virtual host to the audience – have you done virtual hosting name based or IP based – seems to have been responses of both types. There are really two things here – are they done name or IP based? Comment made by ??? that if TLS, must be name based. Fischl: do we really need an extension to the protocol to do this? Should the IETF do this? Do we care enough about the number of TLS connections between servers? Response: The reason is to check where things are going if there are different port numbers used. Rohan: Port open on 5060, expecting internal here. Another one is behind an ephemeral….I don’t understand what Rohan was saying here. Asked who “gets it” – few (<12) hands. Asked for implementers – just a single digit number.


Cullen on Outbound. Work that is being edited by Rohan and Cullen. Much improvement since the last IETF because it had too much stuff – this is more about simplyfiying and talking about a small portion. What does the ua and simple proxies need to do. Still allows the other uses to be done, just not described in this document. SUBSCRIBE is now available and supported as a normal usage. Instance ID definition moved from GRUU to outbound, flips dependency. Flow-id replaced with reg-id. Problem: configuring the outbound-proxy-set was too hard. Suggestions were SRV based and config framework based solutions. Cullen wants to leave as is and leave this to other drafts. JDR: I agree and think the work there would be needed for high reliability, should be there not here. Nils: Does not like the configuration stuff in the UA. Would like statement that implementor is free to not use but use another mechanism instead. Cullen: I wasn’t assuming the user will type it in – I want to let other users do it. Nils: currently no way to do this. JDR: This is out of scope for this document. Hirsham: agree that work is out of scope for this document. Adam Roach: Me too Adrian Georgescu: DNS based mechanism is ok but can be used in other places, but can be in another document. Another one was mentioned, no comments. NAT keepalives for TCP is next open issues. Hirsham: have we agreed for UDP? Cullen: I thought that stun was the solution for UDP? Rohan: Not only choice but we will use it for UDP – concesus achieved here. Francois Audet: If ping is choosen, that can be used for UDP as well. Possible methods: use ping that looks like SIP but is not processed as a SIP message. Response quickly generated without and sort of processing. Argument is that this in infeasible to fully analyze that no harm ever done. Alternative: use TCP keepalives. Statement about which OS can do this – not true in the draft anymore, can be done on some OS. Some cannot, some programming environment can’t. Problems. Double CRLF reply with double CRLF. Backwords safe. May not reply, but there could be CRLF sitting in the buffer. Still need stun for UDP. Last alternative is stun. Works the same, do protocol mux on this. Francois: the Ping really isn’t SIP since it used differently. Also the CRLF and Ping mechanisms should likely both say they work too, so mischaracterization of the Stun as being only one. JDR: STUN already done on both UDP/TCP for ICE. The precedent set in MMUSIC for doing this. Thinks they are different protocols with different purposes. If it is SIP, it should be SIP, so you should just use STUN. RJS: Me too Ben Campbell: I’d rather have same for TCP/UDP. Rohan: PING has been anectdotally reporte to work in various places, but this could be hard to check that it works in all cases. Moves to axe the PING method. Prefers CRLF but would be ok on STUN. Adam Roach: There were cases pointed out that don’t work. Proxy that rejects may cause problems so doesn’t think we should do it. Vjay: Keepalive can be squashed by routers. Hisham: Too much work to do STUN – vendors argue that it takes 6 mo to year to desploy. Jason: Rule out keepalive as too hard to do since some don’t support. Thinks either is trivial to implement but experience shows that the ping is less efficient than STUN. Philip Matthew: Worried this isn’t robust enough for P2P. Feels STUN may be more robust. Brian Stucku: keepalive worked well with many stacks and had good performance, so shows it is good – relative to other transactions it is faster than other points. Not a proof but shows it will work. Both STUN or ping end up looking like a new protocol, so it is indifferent. Mondatti keep proxy to proxy option open. Francois: Worried that CRLF can cause problems if one is lost. If we go stun, need more text about how to do this without fully having to understand StuN for the client side so that phone vendors will do this on the phone side. JDR: 3489bis has a different profile so this is partially finished. Cullen: Need something besides OS keepalives – not sufficient. Put to floor – all agree. Rohan: people in favor of ping didn’t answer Adam’s proxy objection : a proxy that challenges all requests may get this and it will declare the client an attacker after a while. Cullen: reiterate : notes must say that we can use the keepalive, just what do we do if we can’t – not that we disallow that. JDR: Standards bodies are for finding the right thing, not just something that works. Derek McDonald: Size calculation of STUN vs. PING – size was a magnitude smaller on STUN. Rohan: The issue is what the server must implement. Will they be able to do this. Cleint difficulty is less relavent. RJS: There is a great deal of implementation in the wild of implementation by example. Using SIP in a strange way is likely to cause some issues since they may handle it in the normal way. Not as likely with STUN. Cullen: UDP using STUN vs. PING: 5 for PING, many many for STUN. TCP – will allow the keepalive if you want on client, server must use one or the other. For TCP : <5 for CRLF, less for PING, many many for STUN. 


GRUU discussion: Jonathan – hoping this is the last discussion about GRUU. -06 in the archives. -07 submitted but did not show up in the archives. Removed instance ID, added dependence on outbound, but this doesn’t mean you need to have outbound to use it – only if you want multiple contacts for one instance, which is really only needed there. GRUU URI param like lr. Removed require for GRUU in 200 OK and associated mess for edge proxies. Removed stuff about e2e mid dialog. BIG change is removing the edge proxy record route stripping. Record route normally now. Home proxy rewrites and discards path. Presents call flow. Hint mechanism for the home proxy. How do we handle this for multiple contacts? Proxy remembers using record route stuff. Scott Lawrance  Question: why does it matter? Can’t a client handle it if it has multiple registrations? JDR: This sounds reasonable – I will make this optional in the text. Paul Kyzvit: Case that breaks this. When the mid dialog requests gets there and we discard the path. If we have two edge procxies and one home proxy, we lose that. JDR: That means this mechanism cannot be optional. JDR back to slides. Benefits. Slide proposing WGLC re-issue. Will make sure that -07 appears (with changes he made to the local version)


Vjay Gurbani : Uses of TLS in SIP. Goal: explore, look at test cases, compile list of open questions. Presented assumptions. Open Question 1  about authoritative proxy. Jon Peterson: How do you identify a canonical service. In SIP identity, the conclusion was that the mechanisms for routing tell us about the canonical authority. Mechanisms like DNS can be used there. JDR: The certificate is used to reject/accept – based on identiy presented. Cullen: Self signed certificates can be allowed/disallowed is not in the scope of the work Vjay is doing. Jon: should have an absolute correspondence between cert and message. Vjay: This is a proxy – only have the sent by. Jon: the sent by and from should match. This applies to virtual hosting in first presentation. ??? Is a node authorized to be a SIP proxy – identity or certificate flavors. Cullen: I think that almost everywhere domain name and certificate must match. The thing on the other name must have a cert for the domain they are responsible for. Scott Lawrence: Been working. Provision conclusion is you want the sip: name and the DNS fully qualified. Should be the same, but isn’t always. Different purposes – identifying the host, or asserting that it is authoritative for that domain. Rohan: If the peer is associated, you may need to be able to check. Can you compare the cert to multiple things? Cullen: generally works as get a cert for a domain and the like – doesn’t work with multiple domains on one cert. ROhan: I mean www.foo.com and foo.com. Vjay: open question 2. Mutual auth, Can 3261 do more on mut-auth? JDR: Bad idea, Cullen: idea is that PKIs from verisign are not secure so we use DNS to check. I think DNS is less secure. I see little gain. If you have a cert but dns is different, which do you believe? Cullen thinks that the CA is far, far more likely to be secure. Vjay: Quick overview of further points. Jon Peterson: This draft is the first one that covers some of these issues that have come up and we should not be dismissive oif this draft. TLS with SIP is unspecified. JDR: Need better specification of SIPS. Not volunteering to write but we need it. Charles Walker: comments on DNS vs. TLS Francois: I plant to submit a draft on this subject soon talking about how SIPS should work.


James Polk: Location Conveyance in SIP draft hasn’t changed since before Paris. Depricate the stuff that wasn’t pushing location. Changed the organization of the requirements. Removed full SIP message examples. Completed the ABNF. Deleted call for 425 response. Presents long list of open issues. Jonathan: Refresh error or syntax error? Francois: Current draft does not prohibit. JDR: Why not use a 400? James: Argument is that the location could be bad, not message. JDR: not clear that that is a new type Must be clear on the problem and the remedy. Two locations – how to do it? Brian Rosen: Can we have two instances of the header and body. Propose that is out of SIP and should be in geopriv. Asked for objections and got few. Jean Francios Mule: Comments about requirements that should stay and go. Will mail to James. Feels this WG should lok at the use cases here as to why two buddies.  James Winterbottom: Doesn’t feel that is enough to punt to geopriv, thinks it should be here. James: thinks this is a geopriv issue.  Jean Francois: Seems to not have right mechanism.