Re: [Sip] Signing P-Asserted-Identity

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 09 July 2008 00:49 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7963A6B66; Tue, 8 Jul 2008 17:49:21 -0700 (PDT)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17E23A6B66 for <sip@core3.amsl.com>; Tue, 8 Jul 2008 17:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
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 44ssmy1-J0Kl for <sip@core3.amsl.com>; Tue, 8 Jul 2008 17:49:19 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 370953A6A5C for <sip@ietf.org>; Tue, 8 Jul 2008 17:49:19 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 8 Jul 2008 20:48:36 -0400
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 8 Jul 2008 20:48:36 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Adam Roach <adam@nostrum.com>
Date: Tue, 08 Jul 2008 20:47:32 -0400
Thread-Topic: [Sip] Signing P-Asserted-Identity
Thread-Index: AcjhS5Pk10vok7EBTweCkZvyOvSsjgAD4SsQ
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC30EEDFAA747@mail.acmepacket.com>
References: <E6C2E8958BA59A4FB960963D475F7AC30EEDF3C361@mail.acmepacket.com> <4873B3C5.4020202@cisco.com> <E6C2E8958BA59A4FB960963D475F7AC30EEDF3CD21@mail.acmepacket.com> <4873C037.5050203@cisco.com> <E6C2E8958BA59A4FB960963D475F7AC30EEDFAA52E@mail.acmepacket.com> <4873ECF2.5030908@nostrum.com>
In-Reply-To: <4873ECF2.5030908@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "sip@ietf.org" <sip@ietf.org>, Michael Thomas <mat@cisco.com>
Subject: Re: [Sip] Signing P-Asserted-Identity
X-BeenThere: sip@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@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
>
> In theory, you're talking about To, From, Call-ID, CSeq, Date, Contact,
> and the request body. Proxies aren't allowed to change those (with the
> exception of To and From, which are done only in the context of 4474 and
> RFC 4916), and user agents set them before the 4474 signature goes on
> them.
>
> In practice, the elephant in your elephant (or small hairy predator) is
> the body. You're talking about SBCs, and the thing that SBCs want to
> change that breaks RFC 4474 is the body.

Actually, lots of things change the To and From.  If you built a "proxy" that can't be configured to change 'em, you're probably not in business long.  Of course you're not a 3261 proxy at that point, but more of a b2bua.  Heck, lots of things change Call-id and Cseq and Contact, too.  You're talking like the whole mammal class that changes at least one of those To/From/Call-id/Cseq/Contact things, not just elephants.


> And that was kind of a
> necessary hack back before user agents did much in the way of NAT and
> firewall traversal. But any real, commercial user agent I've played with
> in the past five years or so has at least rudimentary support in this
> area, such that body tweaking is mostly unnecessary.
> In other words: there's a better solution than body mangling, and it's
> supported by most modern SIP clients. Let's not gut 4474 to maintain our
> older, broken network architectures.

It's really not a secret that SBC's change SDP for a whole bunch of reasons that have nothing to do with NATs.  And the list of reasons is actually growing, sadly, not getting smaller.  But that's not the point.  Sign SDP if you feel you need to.  Don't sign something you don't feel you need to.

-hadriel
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip