AGENDA:
Monday, November 8 Session
--------------------------
+0 Agenda bash and Status - Chairs
Seven RFCs since last IETF, including PUBLISH
WGLC - GRUU, non-Invite-Transaction
Some things are late
Proposing new milestones
- two REFER drafts - two different milestones?
Rohan has new sponsor and new e-mail address
+15 Connection Reuse
Rohan Mahy, Cullen Jennings - draft-ietf-sip-connect-reuse-03.txt
Non-trivial security problems with existing digest-based reuse mechanisms
Now support reuse of mutual-authenticated TLS connections
Cullen has an open issue (the only one on the table)
Based on Via: header with ;alias
Certificate could contain multiple domain names URIs
Cullen suggests basing the alias on the TLS peer value
Vulnerable to DNS cache poisoning, but easier to do
Rohan suggests going with existing proposal
Q: Why not create aliases for all the names?
A: Still need to verify that any Via sent-by is something we are actually connected to using TLS
Q: Cullen thought he was suggesting ignoring the names in the certificates
Q: What about delegated domain names ("edge.example.com")?
A: Currently prohibited to present an "example.com" cert from "edge.example.com" anyway
Q: Does alias still make sense anyway?
A: It's really a hint that the requester is asking the other end to do something - what if it's not present?
Q: Would you ever want to NOT reuse a connection?
A: Server balancing proxies ending up with uneven traffic distribution?
A: We're taking over a DNS loadbalancing function here
Verify the sent-by corresponds to existing connection? Usually (not always) we don't use sent-by now.
Q: We're going to have proxy farms all the time, we're going to want to reuse connections, this breaks reuse
A: Set up an alias for every interface on the farm?
Q: Isn't this assuming a federated model when you come up?
Q: This is trashing all of DNS loadbalancing - weighting, etc. This is too black or white. I was thinking of a greyish black.
A: Not NAPTR (anything else?)
Can we get scenarios that give us guidance on the shade of grey? This stuff is NOT in the current requirements.
Jonathan taking action to provide scenarios
Cullen - lots of problems between UA and proxy - firewalls, etc.
Proxy keeps track of "connection" (whether TCP or UDP fcur-tuple).
TCP keepalive every periodic number of seconds? CRLF? REGISTER? New message (PING)?
Q: CRLF doesn't generate an application ACK - have to wait for TCP keepalives - we had this in a deployment
Q: REGISTER is horrifically expensive - not a general solution
Q: What's the reason for deciding that TCP behavior isn't OK for a TCP connection?
Q: Punting a TCP connection while it's still retrying requires closing and reopening - during congestion? wrong answer
We think we can check unacked bytes in most(?) socket interfaces and use CRLF
UDP keepalive - same problem plus small residential NAT rebooting can't be detected (still respond to PINGs)
Use STUN? No objections in the meeting
Redundant connections? Need a unique device id in the registration
Allow this?
Q: Doesn't contact URI say you reached the same thing?
A: But contact URIs don't have to be unique
Q: Need to focus on the goal - not the mechanism
A: Need to make sure we don't allow hijacking secure connection with a parallel connection
Quick Reconnect? to reduce proxy load on avalanche restarts, etc. - the limiting factor on scaling most deployments
Don't add load when the proxy is most loaded!
+30 Identity - Jon Peterson - draft-ietf-sip-identity-03.txt
New version of the draft, removes response identity text, added examples
Added text on privacy and providing identities for telephone numbers ("punting until later")
Identity-Info schemes: allow CID? DNS URLs? but don't be TOO generous (interoperability problems)
Q: What's the mandatory-to-implement scheme? RFC 3840 already has "schemes I support" - forking problems, etc.
Q: Does everyone implement CID URI? apparently not, at least not the people in the room :-)
A: CID is getting us close to requiring multipart (actually, we're just on the bandwagon with other reasons)
Q: How do we tell people we don't know what they are talking about?
Q: "Use any URI type?"
What's the relationship to the -certs draft? We're concerned about required modifications to installed base
Rohan - normative dependence on -certs not a good thing
Shopping for response codes? can't dereference Identity-Info, don't like your certificate, bad Identity in From field...
Do we need three new response codes? We only have 100 4XX response codes, so ...
Room concensus is three new response codes
Q: we're assuming use of global PKI. It's harder than it looks
A: but it does work for the WWW today, and no root or trust model is mandated by the draft
Q: but on the WWW, users are making choices. In this case, proxies are making choices. That's harder.
Q: Is "don't like your certificate" a provisional response? No, it's final.
Jon believes it is possible for servers to make these decisions in some scenarios.
Look at message-identity draft - it's 44 pages of analysis about how we got where we are today!
+60 GRUU - Jonathan Rosenberg - draft-ietf-sip-gruu-02.txt
General problem - what should gruu specification say about sips and gruu?
Want to avoid two two registrations to get a sip and sips URI for the same resource.
Existing spec allows upgrade from sip to sips (resource must be the same for both schemes)
Assume both don't have to exist, but if they do, they must point to the same resource.
If contact is sip, GRUU is sip URI, but server creates sips URI, too.
If contact is sips, GRUU is sips URI, but server does not create sip URI.
Does this work for everyone?
Q: if sips URI is created and then used, we may/may not be able to tell a connection is secure. This is bad.
Q: creating sips GRUU is implicit behavior (client didn't request this)
A: creating a sips GRUU doesn't mean much - don't have to create a TLS connection, etc.
Q: problem is that if we're not doing TLS, we may be doing something else (present or future protocols)
Q: The recipient can do the same upgrade to sips anyway.
Q: Does this require unnecessary resources on the server?
A: We have the same problem with people trying to connect to people who don't support SIPS now
Q: When we register, do we see sip and sips URIs?
A: Depends on what you send as the contact URIs. Should work the same as AOR registrations
Jonathan to add text reflecting his proposal
Connection reuse/GRUU reuse has been problematic - when we have multiple connections, we get wrapped around the axle
Allow multiple contacts in a GRUU for redundancy (all to the same instance)?
Q: If my TCP connection dies and comes back, is my connection-id the same? If so, it's not a connection-id...
Q: If I'm hosting these things, how many do I know to create?
A: Maybe just two, but this is provider policy - does the client know how many interfaces it has? Maybe...
Who understands the issue here? a critical mass - please send e-mail to list/Jonathan and chairs
Conflict Resolution - current spec requires since contact per instance, which helps avalanche restarts
Does AOR map to a GRUU? how does edge proxy know it should record-route? Should not record-route if client uses GRUU
- this happens in IMS architecture, for instance
200 OK contains Supported: GRUU EP? Remove record-route on response
Q: Shouldn't edge router be authoritative anyway and route without GRUU?
A: IMS proxy may be in a different domain (HSP and VSP domains) - spiral is expensive - don't use GRUU in these cases
* (resumed here)
Does GRUU map to AOR? AORs map to contacts, so do you redirect to a GRUU or to a contact?
You get different proxy behaviors for AOR->GRUU and GRUU->contacts
Q: If GRUU was just a higher-priority contact, would that solve this problem?
A: Would depend on the logic of routing
Proposal: AOR -> GRUU -> contacts? Register and refresh up the chain, AOR -> GRUU mapping disppears when GRUU contacts disappear
Q: This is the wrong direction, we're going to explode. Enumerate new behavior reflecting GRUU extension
We have a real terminology problem with contacts and connections - sometimes they are headers, sometimess not
Cullen - we're confused, we need a room with a white board
Q: Should reg-extension be merged with this draft?
+80 Content Indirection - Eric Burger - draft-ietf-sip-content-indirect-mech-05.txt
05 draft provides optional content, content-disposition entity header now a MUST (from SHOULD)
Using hash, not base64
Q: too many colons?
A: Eric will check
Open Issues -
e-tags and content-ID? work this week
URI scheme negotiation - full negotiation needed? ("yes" = hack SDP, out of scope)
+95 History Info - Mary Barnes - draft-ietf-sip-history-info-04.txt
Added protocol structure text as descriptiove
Added text on scenario when TLS not available
Some editorial changes
Should -> MUST for applications lacking History-Info and privacy impacts
Updated response processing to reflect privacy
Added text for reason header in response
Added appropriate characters for escaped example URI
Have identified indexing error, 480 timeouts should be 408s, missing quote on "Busy Here"
WGLC ends on November 29
Feedback, especially with text, is always appropriate, especially now.