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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]