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

Hi,

I think Ben gave my clarification :)

Regards,

Christer


> -----Original Message-----
> From: Ben Campbell [mailto:ben@estacado.net] 
> Sent: 9. syyskuuta 2010 1:15
> To: Christer Holmberg; Cullen Jennings
> Cc: draft-ietf-simple-msrp-sessmatch@tools.ietf.org; Ted 
> Hardie; IESG IESG; The IETF; secdir@ietf.org
> Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch
> 
> (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
> 
>