Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch

Ben Campbell <ben@estacado.net> Wed, 08 September 2010 22:15 UTC

Return-Path: <ben@estacado.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32A63A696A; Wed, 8 Sep 2010 15:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 eUSCqm-srkcD; Wed, 8 Sep 2010 15:15:02 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id EAC703A6866; Wed, 8 Sep 2010 15:15:01 -0700 (PDT)
Received: from dn3-174.estacado.net (dn3-174.estacado.net [172.16.3.174]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o88MFAYB071069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Sep 2010 17:15:11 -0500 (CDT) (envelope-from ben@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Ben Campbell <ben@estacado.net>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585015BCA41@ESESSCMS0356.eemea.ericsson.se>
Date: Wed, 08 Sep 2010 17:15:05 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DA8DA86-792B-44A4-A1AD-8DD6DF3FA985@estacado.net>
References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <AANLkTikqkX4iY2nUF1eRYEcpR80pw8A2wXnV1kpfwAZk@mail.gmail.com>, <C3918F74-44C6-4332-9A16-6FDEF6F9A130@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA41@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.1081)
X-Mailman-Approved-At: Thu, 09 Sep 2010 08:57:29 -0700
Cc: draft-ietf-simple-msrp-sessmatch@tools.ietf.org, Ted Hardie <ted.ietf@gmail.com>, secdir@ietf.org, IESG IESG <iesg@ietf.org>, The IETF <ietf@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2010 22:15:03 -0000

(as individual)

On Sep 2, 2010, at 8:37 AM, Christer Holmberg wrote:

> Hi Cullen,
> 
>> Do these changes allow an SBC on the signaling path to change the contents of the MSRP messages 
>> without the end points being able to detect that? I'm sure it will be easier to answer this once we have 
>> a new draft.
> 
> Sessmatch does not make it any easier for an SBC in the signalling path to change the content of the MSRP messages. 
> 
> For an SBC to do MSRP message modification it will have to implement MSRP B2BUA functionality - no matter if sessmatch is supported by the endpionts or not.

I'm going to have to push on this one a little bit:

I think it _does_ make it easier for an SBC to change MSRP messages because it makes it easier for the SBC to put itself into the media path in the first place. This is no different than for any other sort of media.

The need to implement MSRP b2bUA functionality exists if the SBC changes the To-Path and From-Path headers. It may or may not be required if it wants to change _bodies_, depending on whether that change requires chunk-reassembly or changes the length of the body. And assuming, of course, there is no end-to-end protection on the MSRP messages in the first place--and we all know that in practice there probably won't be.

I think what Christer is talking about is, if sessmatch did not exist, then if an SBC were to insert itself into the MSRP media path, it would be _forced_ then to rewrite the To-Path and From-Path in each MSRP request to match the change it made in the SDP. If it did not do so, the endpoints would detect the change and treat it as an error. That is, sessmatch does not enable the insertion in the first place--it just makes things cheaper from a processing perspective.

Note that any end-to-end integrity protection on the SDP, such as RFC4474 or s/mime, will prevent SBC insertion, with or without sessmatch. Just like for any other media.


> 
> Regards,
> 
> Christer
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf