Meeting: SIPPING WG Interim Meeting Location: Bedford MA Date: 25-May-2004 Time: Afternoon Session, 1pm - 6pm Scribe: Paul Kyzivat [Editorial notes in [], significant points marked with **] [I noted a place or two where I think there were conclusions I didn't capture.] -------------------------- * Session Policies (Continued from morning) -------------------------- The session dependent policy draft, and the slides used here, were very confusing. Almost nobody in the audience understood them. A distinction was drawn between disclosing information and transmitting policy. Question whether better to use piggy backing on the invite for one and separate protocol for the other, or use same mechanism for both. Rohan Mahy presented some typical applications: - nat/fw traversal, - bandwidth / media /codec policy, - logging Some disagreement between Rohan and Jonathan Rosenberg about the definition of session dependent policy. Cullen Jennings made distinction of policy that isn't really session dependent, but that isn't told to you until you make a call to which it applies. Additional discussion on the scope of policies. ** Concensus that both session dependent/independent policies are needed. Rohan showed a "Triangle Redirect Model" and asserted that it is a good model when it applies. But he thought it often doesn't apply. Some disagreement on this. Gonzalo Camarillo thought this is wrong model because proxies only want to disclose policies to their own subscribers. Rohan then showed a Trapezoid Redirect Model which reputedly solves the problems. But he demonstrated many problems with it. Rohan then proposed Foreign Piggyback Model as better solution. Jon Peterson said that it must always be possible for a proxy to modify an answer coming back, which this model doesn't support. Rohan thought it is possible for proxy to send a suggested (partial) answer in anticipation, before the answer is send. ** Disagreement on whether enough can be done by anticipating responses or not. ** Major issue raised - the addition of body parts by proxies. Rohan thought this can be done safely. Jon thought it cannot and should not. Decided not to deal with this right now. Jon described use case with separate channel for policy exchange: that when a UAS receives an offer it, passes some info from it to a policy server, gets a response with some policy, and uses it to create the answer. He raised a question of whether this takes too long and has to be optimized. He asserted any reasonable solution to this will cost extra round trips over some protocol. He thinks if this is scoped down small enough (sdp of less) then it is solvable. Audience asked if there is agreement that having a separate channel for policy exchanges. [Scribe did not capture any sense of agreement, pro or con.] Somebody asserted there are three kinds of things that policy server wants to say: - This is what I want you to do - this is what you can do - this is what you can't do Rohan claimed this is getting too complicated. Dean thought we are reinventing MGCP over sip. He provided the most profound insight of the day: "There are many ways to skin a cat, but a potato peeler is not the right way." Jonathan thought we need metrics for comparing the approaches and suggested not trying to solve the general problem (too hard) and instead focus on what we really need to solve. ** Gonzalo agrees to produce a new draft discussing use cases with pros and cons. Allison Mankin noted that 3GPP has wanted wanted this [session policyh mechanism]. Suggested existing cases where SDP is being rewritten should be a source of use cases. --- In the midst of the session policy discussion, Rohan presented the "Contact Correlation Problem" - how does the sender of a message know that the contact address it reaches is related to the AOR that was called. He raised it as justification for proxy addition of bodies to requests. ** Massive disagreement over this problem. Jonathan claims it is fixed by sips, while Rohan thinks not. Disagreement over this. Cullen proposed change to 3261 requiring responses over TLS to come over a connection that is authenticated (details not caught.) The contact correlation problem discussion ended for lack of time without resolution. There were several issues to be captured, but the scribe missed some. ------------ * Exploders ------------ Gonzalo dropped a bombshell regarding security considerations. These had been brought up recently by Jon Peterson in anticipation that this will be an area director hot button. Apparently the exploder work had been identified as a potential source of spam. (Since the IETF is in process of trying to dig itself out of the email spam problem it doesn't want to create a new one.) (Dean explained that wgeb he first heard about this issue from Jon a couple of weeks ago he went thru stages of anger, denial, ... and finally acceptance. He hopes the rest of us will get there too.) A new requirement has been levied on the work: destinations must agree in advance to receive messages from an exploder. And the exploder must be be used to explode requests for permission to explode. So original requester must first request, one by one, permissions to explode. Example given - a PTT server could be used as an attack tool. Not just spam, but even as a DOS tool. Need to prevent this. There were many concerns from the audience that this would render ad hoc lists useless. However there was some rebuttal that this need not be the case, as long as there is a large list of potential targets that have already opted in, and the ad hoc list is viewed as a way of subsetting that larger list. Suggestion that this can be made to work, even for ad hoc lists, by having one list of authorized recipients and another of who to really explode to. In this case you would typically attempt to get exploder permission for people in your address book as soon as they are added. Ted Hardie said that for this to be effective, must change the sip architectural model from one of any:any messaging, to one of communication between consenting parties. It doesn't have much to do with exploders, because any kind of spam that can be done with exploders can also be done without exploders. Dean said we can only control what we control. So we can control how exploders work, but we can't control how spammers work. Ted thought we could consider this is the first instance of a new direction for sip. Jon Peterson said there are other actions we must do that are separate from this draft. Specifically, how a recipient can distinguish requests from Foo vs requests on behalf of Foo from an Exploder. Aki Niemi can't see how this can work, given that most people will opt in. Gonzalo observed that opt in isn't just for an exploder, it is for messages from a particular exploder on behalf of a particular sender. Dean described a truly ghastly solution based on subscriptions. Jonathan proposed another solution. [Won't try to explain here.] General sense was that there could be workable solutions. ** Question was raised if this kind of mechanism should be mandatory to implement or mandatory to use. Allison said at least mandatory to implement, and very hard to go beyond that. Jonathan observed that we don't have anything in our bag of SIP tricks to support opt-in functionality across sip, and that perhpas we should go build that functionality. Discussion topic switched to the subject of how to pass the list - uri parameter or header field. Jonathan argued in favor of both sides. Finally argued in favor of uri parameter. Cullen wants to use a mechanism that works - doesn't think uri parameters currently work. Rohan suggests using the grid parameter to pass the list reference. ** The subject of parameter traversal was captured as an additional topic for discussion at this meeting. {But it didn't come up again this day.] [Not sure of overall resolution on exploders. General sense that we have made a great deal of negative progress on exploders.] -------------------------------------- * Identity: draft-ietf-sip-identity-02 -------------------------------------- Presented by Jon Peterson. New co-author Cullen Jennings. Change since last version - replaced body with header. Jon says goal here is to do something light weight enough that it will be widely implemented. Rohan objected - said only reason to switch to headers was so that something other than endpoint can insert/consume information, and that it would be more natural to permit proxies to add bodies. Jon said yes, he believes main diff between header and body is that body is end:end and this is an assumption on which sip is based. Rohan disagrees. No humms taken but there seemed to be substantial disagreement in the room over this point. The new version signs headers, but doesn't provide copy of them. So you can tell if things have changed, but you can't reconstruct what they were. So this is less versatile - auth-id-body still needed for other applications. However the new approach works better than the old in some ways, especially for responses, though response identity is still tricky. Jon explained an identity issue - how to know what happened when I called A but reached B. Two issues - Knowing it is B vs A, and knowing who caused B to be reached rather than A. Jonathan asserted it is impossible to distinguish valid retargetting from invalid retargetting. Jon said point is to provide sufficient info so that it is possible for users to know what is happening and have a chance to decide. A feature of Jon's draft is that a retargetting to another domain is handled as a redirect. This was intended to ensure the UAC knows about redirects. Jonathan also thought it was good that retargetted requests go back to the caller. Then it is safer to include body content that is only intended for the callee. On redirection will have chance to change content. ** However John Ellwel pointed out that there is no assurance that 3xxs will go back to the UAC - proxies can recurse. ------------------------------------------- * Identity: draft-jennings-sipping-certs-03 ------------------------------------------- Cullen Jennings presented. Jon's identity draft provides identity, but doesn't give e2e s/mime encryption. draft-jennings-sipping-certs-03 has now been modified to use Jon's new identity approach. Discussion of why two bodies are needed for secure offer/answer - why not just use ALT to offer both RTP and SRTP? Rohan pointed out that the SRTP must be encrypted to protect the key exchange, while the RTP offer should be left unencrypted so that communication with endpoints that don't support encryption is possible. Then discussed *how* to offer both RTP and SRTP: - two SDP bodies, both with offers, both to be responded to - two sdp bodies that contain alternative offers. Use the one you want. Rohan proposed using the alternative form: Content-Disposition: session Content-Type: multipart/alternative [unencrypted offer of RTP] [encrypted offer of SRTP] ----------------- Misc. Open Issues ----------------- Hold: interactive flag in dialog package: Jonathan wants to split to two independent attributes. One is an automaton that never sends a BYE. The other is a media attribute - whether media is being monitored. Rohan finds this unuseful. [Don't believe there was any conclusion.] [THE END]