[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Thoughts on SIP Identity issues
> 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, aFrom sip-bounces at ietf.org Thu Jul 31 06:25:43 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9E81F3A6C7A;
Thu, 31 Jul 2008 06:25:43 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 0073B3A6C7A
for <sip at core3.amsl.com>; Thu, 31 Jul 2008 06:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.58
X-Spam-Level:
X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id iHLMUkUbIQI9 for <sip at core3.amsl.com>;
Thu, 31 Jul 2008 06:25:41 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70])
by core3.amsl.com (Postfix) with ESMTP id 98E3C3A6AA2
for <sip at ietf.org>; Thu, 31 Jul 2008 06:25:10 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,286,1215388800"; d="scan'208";a="59892618"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
by sj-iport-1.cisco.com with ESMTP; 31 Jul 2008 13:24:54 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6VDOsan003599;
Thu, 31 Jul 2008 06:24:54 -0700
Received: from dwingwxp01 (sjc-vpn5-1269.cisco.com [10.21.92.245])
by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6VDOqCC009030;
Thu, 31 Jul 2008 13:24:53 GMT
From: "Dan Wing" <dwing at cisco.com>
To: "'Jonathan Rosenberg'" <jdrosen at cisco.com>,
"'Elwell, John'" <john.elwell at siemens.com>
References: <0D5F89FAC29E2C41B98A6A762007F5D0F266CD at GBNTHT12009MSX.gb002.siemens.net> <02829328-7B0E-41AB-B325-01246363D09C at cisco.com> <4DAE5E60BA49D8419D7C8832503F5FFC072817AF26 at EVS10.ams.gblxint.com><0D5F89FAC29E2C41B98A6A762007F5D0F26CCB at GBNTHT12009MSX.gb002.siemens.net>
<48919248.7060600 at cisco.com>
Date: Thu, 31 Jul 2008 14:24:51 +0100
Message-ID: <0ae201c8f310$d183a0f0$3675150a at cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acjy98g3RlyIh1r1TsKiDnkiV6zHcwAGHifw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <48919248.7060600 at cisco.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1377; t=1217510694;
x=1218374694; c=relaxed/simple; s=sjdkim2002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=dwing at cisco.com;
z=From:=20=22Dan=20Wing=22=20<dwing at cisco.com>
|Subject:=20RE=3A=20[Sip]=20Thoughts=20on=20SIP=20Identity=
20issues |Sender:=20;
bh=Y5mM7nHbGBTUP5YO4W7sWvcItm8aHCZ5jsaq1nm1++Y=;
b=XtSiL9QfUjlabRIn6TYpJvH4aG1cEGmpkpLPrWHJvIptRhv0uuryUlyHzI
nZbs/eHAf0VQ3RzsKeQgWaf0fzqIXwRGWb7mTR9otEcADyNX5ghZZmFm7k9B
Ranjonsq0/;
Authentication-Results: sj-dkim-2; header.From=dwing at cisco.com; dkim=pass (
sig from cisco.com/sjdkim2002 verified; );
Cc: 'Cullen Jennings' <fluffy at cisco.com>, 'SIP IETF' <sip at ietf.org>, "'Uzelac,
Adam'" <Adam.Uzelac at globalcrossing.com>
Subject: Re: [Sip] Thoughts on SIP Identity issues
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
> 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 thnd 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.
Thank you - this is the first description of a codec attack that
anyone has explained.
So a beneficial change (adding a codec and doing transcoding for
the user) is okay, but a non-benficial change (removing a good-
sounding codec for the end equipment [wideband] or for the network
[iSAC]) is an attack?
-d
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
us 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.
Thank you - this is the first description of a codec attack that
anyone has explained.
So a beneficial change (adding a codec and doing transcoding for
the user) is okay, but a non-benficial change (removing a good-
sounding codec for the end equipment [wideband] or for the network
[iSAC]) is an attack?
-d
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip