Hi, I think Ben gave my clarification :) Regards, Christer > -----Original Message----- > From: Ben Campbell [mailto:ben@xxxxxxxxxxxx] > Sent: 9. syyskuuta 2010 1:15 > To: Christer Holmberg; Cullen Jennings > Cc: draft-ietf-simple-msrp-sessmatch@xxxxxxxxxxxxxx; Ted > Hardie; IESG IESG; The IETF; secdir@xxxxxxxx > 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@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf