> -----Original Message----- > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED] > Sent: 31 July 2008 11:22 > To: Elwell, John > Cc: Uzelac, Adam; Cullen Jennings; SIP IETF > Subject: Re: [Sip] Thoughts on SIP Identity issues > > Is this an ATTACK though? I don't think it is. [JRE] I am not sure. But the important thing is that the user be aware that there is intervention, i.e., that any media security is only as far as the domain that does the conversion.
John > > One of the points of dispute at the mic is whether or not > 'unauthorized' > changes to signaling constitute an attack or not. I don't > think we have > a very clear definition of what aspects of the request are really and > truly ones that are authorized to be changed, and which are > not. We've > tried to draw this line at headers/body and also outline > certain headers > which are and are no immutable. However, those were based on > the model > of which parts of SIP a PROXY needed to modify and which it > didn't, NOT > based on whether a modification of that header would truly be > an attack. > > I would assert that the following is an important litmus test: > > Modification of a portion of the SIP message is an 'attack' if > and only if it results in an experience for the end user > which defies > their expectations. > > Put in the contrapositive, if a change is not noticeably by the end > users because they get exactly what they expected, then its not an > attack. Nothing bad happened, so why would it be an attack? > > Another way to think about this, is the following litmus test, "If an > intermediary consistently makes this modification, is it likely that > some users will open trouble tickets with their IT department > to report > a problem?". If so, the modification is an attack. If not, its not. > > Modifying a message to cause it to be dropped clearly is an attack, > since user expectation is that, if I make a call, it > succeeds. So if a > packet is consistently dropped, my calls consistently fail, > which defies > my expectations. > > As another example that is more complicated, consider > changing codecs. > In one way, codecs are invisible to users. Indeed, a change > of codec for > purposes of transcoding will allow a call to succeed when it might > otherwise fail, and is thus beneficial to users and not harmful. > However, a downgrade of codecs - for example, removing > wideband codecs > from a codec list - is harmful and noticeable to users. If I have a > softclient with iSAC and I call someone else who does too, but we get > only g729, frankly, this is noticeable to the users. Indeed, one can > imagine that if a user of such a soft client sometimes gets > wideband and > sometimes not, they may ask the person on the other end of > the call if > they also have a softclient with the wideband feature, and if that > person does, not understand why there was no wideband for the > call. In > this case, modifications of codecs can be considered an > attack without > some indication to the user why they are not getting wideband. > > Thanks, > Jonathan R. > > > > Elwell, John wrote: > > Adam, > > > > Thanks for your support. However, I do not accept > transcoding as a use > > case. To perform transcoding the service provider needs to > decrypt and > > re-encrypt, and therefore DTLS-SRTP will be terminated at the > > transcoder. Therefore the service provider will indeed need > to re-sign > > the SIP request (the certificate fingerprint will have > changed, among > > other things), and the user will see that media is secure > only as far as > > the service provider. I think this is the correct outcome. > > > > John > > > >> -----Original Message----- > >> From: Uzelac, Adam [mailto:[EMAIL PROTECTED] > >> Sent: 30 July 2008 12:06 > >> To: Cullen Jennings; Elwell, John > >> Cc: SIP IETF > >> Subject: RE: [Sip] Thoughts on SIP Identity issues > >> > >> I believe that the problem statement (and associated use > >> cases) that John presented in the WG session are valid. I > >> think it was unfortunate that those use cases couldn't be > >> discussed more in the WG session. This email appears to me > >> simply John trying to further the discussions to bring out > arguments. > >> > >> One particular note I would like to share - given a comment > >> at the mic regarding 4474 working as designed and desired - > >> is that there are situations (good, bad or indifferent) that > >> necessitate changes in the SDP. John cited media steering as > >> a use case. Another use case is media steering for > >> transcoding. Use case below: > >> > >> Ent A--->SSP1--->Ent B > >> > >> In this use case, Ent A and SSP1 have established certain > >> "rules of engagement", like G729, 2833, t.38, etc. Ent B and > >> SSP1 have established their own "rules of engagement", for > >> instance G711 for voice, inband DTMF/FAX, etc. Being there's > >> no common denominator for the media, the SDP in INVITE > >> "steers" to a device that can trancode. > >> > >> Another use case, would be for those SSPs that have Lawful > >> Intercept requirements. Steering the media to something that > >> will can intercept should that be a regulatory obligation. > >> > >> Adam > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >> Behalf Of > >>> Cullen Jennings > >>> Sent: Tuesday, July 29, 2008 7:21 PM > >>> To: Elwell, John > >>> Cc: SIP IETF > >>> Subject: Re: [Sip] Thoughts on SIP Identity issues > >>> > >>> > >>> On Jul 29, 2008, at 17:53 , Elwell, John wrote: > >>> > >>>> Flawed argument 2: > >>>> The problem exists when we go through service providers. Service > >>>> providers use only E.164-based SIP URIs. We can't do > >> anything about > >>>> E.164-based SIP URIs. Therefore we can't do anything to > >> address the > >>>> case > >>>> where the request goes through service providers. > >> Therefore there is > >>>> nothing we can do. > >>> > >>> Hmm, I don't think anyone made quite that argument. > Personally, I'd > >>> rather spend time thinking about the problems that were presented > >>> today in the meeting than repeat previous discussions. > >>> > >>> Cullen <with my individual hat on> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use [EMAIL PROTECTED] for questions on current sip > >>> Use [EMAIL PROTECTED] for new developments on the > application of sip > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > [EMAIL PROTECTED] > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
