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