My last post described the MSRP Session Match extension (aka “sessmatch”) and its purpose. I mentioned that there were some backwards compatibility issues. This week I will discuss those issues in more detail.
The session matching criteria in sessmatch were intended to be backwards compatible with RFC 4975. Remember, sessmatch relaxes the session matching rules so that only the “session identifier” component of an MSRP URI is considered when matching an MSRP request to a session. An MSRP URI that matches a session according RFC 4975 (that is, an as an exact URI match) always also matches according to sessmatch. And as long as nothing modified an MSRP URI in the SDP offer and answer, then things will still match according to RFC 4975 rules.
But keep in mind that the whole point of sessmatch is to allow a device, for example an SBC, to modify the MSRP URIs in the SDP. So I think we can assume that, whenever sessmatch is used, something probably does modify the URIs.
As sessmatch was specified prior to version 11 of the draft, An MSRP endpoint that supports sessmatch, and is also behind an SBC, cannot talk to an endpoint that does not support sessmatch.
And even if both endpoints support sessmatch, things break down if one endpoint uses an SBC and the other uses an MSRP Relay. The sessmatch extension, as currently written, does not apply to MSRP relays. But relays use the same session matching rules as in RFC 4975. So if an SBC modifies the offer or answer, then the session will fail to match at the relay.
That problem could be mitigated if we extended sessmatch to apply to relays as well. But there’s still a more subtle problem. One very popular feature of SBCs is something called “topology hiding.” Topology hiding means that the SBC hides artifacts (such as IP addresses, host names, and URIs) that identify hosts on one side of the SBC from devices on the other side. This is done for a variety of reasons. Some providers believe their internal topology to be sensitive information. Some want to anonymize the IP addresses of their customers.
Topology hiding can be applied in any number of places. For example, it’s common to hide SIP Route, Record-Route, and Via header field values. But if an SBC performs topology hiding on SDP payloads, then MSRP relays will break.
An endpoint that uses an MSRP relay puts the entire MSRP path to the endpoint in its SDP path attribute. This may look something like the following:
MSRP Relays are session-stateless. They need this entire path in order to figure out where to route MSRP messages. But if a topology hiding SBC removes part of that path, the relay can’t deliver inbound messages. For example, the SBC might change the previous path attribute to look like this:
Now when Bob’s peer tries to send an MSRP SEND request, it will probably get as far as Bob’s relay. But the relay will have no idea how to send it on to Bob.
Version 11 of the sessmatch draft recognizes the backward compatibility issues and proposes a new SIP option tag that indicates an endpoint both supports and is deployed in a way that it can actually use the sessmatch extension. This will at least allow endpoints to fail in a graceful way if their network policies prevent them from exchanging MSRP messages. In the best case, the endpoint behind the SBC could attempt to use an MSRP relay instead, or an SBC could change its behavior for the session to avoid incompatibilities. But in reality, providers that use an SBC in the first place are unlikely to allow such fallbacks as a matter of policy.
The option tag will help prevent the balkanization of the MSRP protocol itself. Unfortunately, the need for sessmatch in the first place shows that service providers, through incompatible policies and network designs, are likely to break the MSRP user communities into islands that can’t talk to each other.