Session 1,
0900 Open Meeting
-- Chairs
Note Well
Agenda Bash
Announcement: NITs
Announcement: Guidelines
Charter and Status Discussion
We did get a lot
of stuff into the RFC Editor queue since
SIP SCTP revision is needed (post IETF last call)
Have missed a few
milestones since
Do not expect to close WG in September :-}
Non-invite transactions for WGLC? Yes.
What is the “SIPPING 16” mentioned at VoiceCon? This is mythology – pay no attention to the Bigfoot sightings – will issue a draft saying “there is no such thing” – OK? Should this be expedited as RFC-Editor submission? Let’s start with a draft.
0915 Content
Indirection -- Dean Willis
draft-ietf-sip-content-indirect-mech-04.txt
Looking for an official editor going forward.
Have corrected some errors that made it all the way through WGLC.
Open issues:
- Do we need content expiration? Do we have to update RFC 2017 to add it?
But the server can remove the resource when it expires anyway – point was to tell the client that the resource could go away, not to tell the server to do anything – this helps with trust relationships, and with passing keys around.
We’re discussing changes since IESG review (proposed last week). There is no MIME reviewer – we go to IETF-TYPES mailing list.
Hash (should be BASE64-encoded) – is this OK with MIME people? Need double quotes? Yes, needs to be quoted. “Hash” doesn’t tell you what kind of hash is being used – name it (MD-5, etc.).
How to reject on of many media types? 415 rejects entire payload. RFC 3359? allows rejecting non-critical content.
Section 5.10 should be removed, for a couple of reasons.
0930 Body Additions? – Rohan Mahy
Can we allow intermediaries to add bodies? This is a restriction removal.
Typical applications – logging, policy, NAT/FW traversal, request history, location conveyance.
Media/bandwidth/codec restrictions is a requirement coming from 3GPP community. Some of this requirement goes away when you can subscribe to resources that aren’t session-related, but not all of them go away.
Some of these discussions involve topology-specific details (sometimes you go through an intermediate device, sometimes you are end-to-end).
Is NAT/FW traversal still needed if we have STUN, ICE?
Henning has proposed request history using headers, so body addition isn’t required in this proposal.
Location conveyance includes adding location body for emergency services.
Explicit policy fetch works great when policies don’t depend on who you call, or depend on dynamic properties like load, and don’t need to muck with INVITE most of the time.
Full redirect doesn’t work with middleboxes, doesn’t work with GRUU – actually, does work with some middleboxes, but not with others.
Triangle redirect doesn’t work with policy requirements of many organizations.
Lots of problems with trapezoid redirects (lots of extra RTTs, etc.). This may never matter in real network paths.
We have a lot of things to coordinate when we add bodies, because it affects a lot of abilities of the protocol.
Policy gets more complicated when we have more than two proxies involved (the “pentagram” model, etc.). This is adding a lot of complications, and we aren’t ready to use policy as justification for adding bodies.
Proposing (in a non-invested way) a “foreign piggyback” model – results in fewer RTTs, but does require addition of bodies by non-adjacent proxies.
Full piggyback isn’t where we want to go, because there’s no way for users to consent to modifications by proxies.
We aren’t changing one line in an RFC, we’re changing a lot of lines in the security considerations section. This is not a small thing. And we’re not just talking about adding bodies, we’re talking about modifying and deleting bodies. This is a slippery slope. It solves a subset of request history needs, not all of them.
Why isn’t foreign piggyback model symmetric? Client has relationship with adjacent proxy, not with others. There are lots of race conditions that are involved here. Different applications have different security considerations – we have to solve all of the problems, and may not have the same solutions for all of them.
Adding bodies blows our integrity checking – we have to do this body-by-body, a body can be removed, etc. There is a security model for SIP today, and we’re changing the security architecture of this protocol. That’s a major change, and we’ve had so many problems with the specs in this area already. S/MIME doesn’t help, because of downgrade problems.
What’s the way to move forward here? We need resolution. Can this be solved before session policy, request history, identity? But we need to solve all of the problems in a cohesive way.
1000 Connection
Reuse -- Rohan Mahy
draft-ietf-sip-connect-reuse-02.txt
Two motivations – efficiency and connectivity (outbound-only connections, etc.).
There’s an architectural problem at the root here – URI doesn’t provide an appropriate context for what we’re trying to do. If you get the URI from the server you’re talking to, this problem goes away.
This is similar to GRUU mechanism – we’ve got a user agent, with multiple connections, and we want to route to a single instance. The addresses we have aren’t the addresses we’re used to in SIP.
1030 Authenticated
Identities -- Jon Peterson
draft-ietf-sip-identity-02.txt
draft-ietf-sip-authid-body-03.txt
Auth-ID body is
done, sip-identity hasn’t changed since
Is retargeting acceptable?
Does separating local/non-local contacts work?
Does interaction with GRUU and connect-reuse work?
Also need examples.
On retargeting:
This doesn’t change what you can do with SIP.
Redirection isn’t THAT bad – TLS works well for HTTP-style redirection, while S/MIME only solves forwarding cases. Do we want to look more like HTTP, or more like mail?
We have a number of e-mail pains due to the e-mail architecture (spam, phishing, etc.)
We’re doing a lot of retargeting to non-local URIs (3G, for example).
Would like to do security without S/MIME – TLS is penetrating, nobody is really doing S/MIME (and would this change?).
3GPP has different ways to do identities anyway.
Forwarding services work today – it would be a shame to break this. We need a program reentry point because we have lots of ways to “come back” today.
There are lots of ways to control the experience of forking on UAC that don’t work on proxies.
We have some contacts that only forward, and others that only redirect, and this breaks things.
“Benefits” of retargeting – control, privacy, speed, FW/NAT traversal – and the last benefit is the real benefit.
“Drawbacks” – response identity problem, request-history, no caller consent, unnecessary transitive trust, low-level protocol weirdness (loop classes that require Max-Forwards, “spiraling”).
Does non-local retargeting go away so we can get identity? Don’t want security property downgrading – more choices allow more downgrading. If identity is critical, we’ve got to go there – not with a flag day, but we’ve got to go there.
Does this contradict caller preferences? Jonathan thinks “no”.
This doesn’t mess up request-history (after thinking about it a while).
Do all the applications work? Extra RTTs are OK.
Need to make requirements so we can make sure we meet them.
Cost-benefit from a speed perspective is subtle (and probably small as well). Almost all forwards are local forwards, and almost all phone calls have local forwards today.
“The main thing is to make sure this actually works in a practical sense, and I’m not there yet.”
RFC 3261 limits recursion – but was this text ever coherent? Would we clarify this text?
This probably will slow down call setup in wireless domains, but it’s not unreasonable for retargeted calls to be slower. SIGCOMP helps here, too.
RFC 3261 is pretty clear on who can muck with Request-URI – this should work.
It’s nice to be sensitive to the concerns of the wireless community, but we shouldn’t dork with the security architecture to accommodate restrictions that we may not have in a longer timeframe.
Cullen and Jon think this is the only way forward (after trying other stuff) – what do others think? Is this reasonable? Is the proposal mature enough to get field experience? There’s a huge chunk of the room that doesn’t understand the work and isn’t comfortable with the draft – right? 40 readers, most understand the problem – lack of comfort is fuzzy – we’re not sure what the impact of security tradeoffs will be in all cases. We’ve already blessed transitive trust – we’ve got too many security alternatives now. Under what circumstances do we invoke certain mechanisms – that’s the problem I’m having. Now that this work is affecting the base protocol, people who haven’t been following this work are starting to get interested – and this is a good thing.
1100 GRUU --
Jonathan Rosenberg
draft-ietf-sip-gruu-02.txt
URN equality – we don’t mandate a baseline URN scheme – can use registrar equality rules, otherwise lexical equality.
GRUU/425 – establishment-of-service attack/ramp-up attack limits scalability of system during avalanche restart to carry 4 message exchanges.
Does keeping old registration violate GRUU uniqueness property? Multiple ROUTES to a single INSTANCE. But how many useful GRUUs do you need? Prefer automatic overrides of old registrations. There are use cases that apply (multiple connections for high availability). We’re not being entirely consistent between GRUUs and aliases. Who needs to know when a registration is overridden? Need one RTT to figure out what’s going on in order to construct the right registration anyway – can’t change this. Can add expires=0 to remove these registrations explicitly.
If we have multiple registrations, we need to think about forking for a while, especially when we get errors. Retry in parallel? In series? Some combination? Depends on the nature of the error. Can be fixed, but complicates things.
Expires=0 works unless you know you’re the same instance and you’ve forgotten the registration state – is this a meaningful think to worry about?
Aren’t we reliving E-tag with XCAP? Possibly.