Is this an ATTACK though? I don't think it is.
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
