[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Record-Route, Path, Service Route, and Multi-Homed Proxies
On the weird bits about SIP has always been "how to deal with
multi-homed proxies". This has begun to raise a mess of problems with
Path, Service-route, and a few other things I consider important (like
security).
Background
-----------
By multi-homed, I mean connected, like a router, to two or more
different networks, with an interface into each network, such that
traffic comes "in" one network and goes "out" a different one.
A simple model is shown here:
/------- \ /------------\
| net1 | | net2 |
UA1-----| 10.1.1.0 |---P---| 192.168.1.0 |-----UA2
.2 | /25 | .1 .1 | /24 | .2
\------- / \------------/
UA1 has one interface with IP address 10.1.1.2
P has two interfaces and two addresses
-- 10.1.1.1
-- 192.168.2.1
And UA has one onterface and 1 address, 192.168.2.2
In other words, there IS no IP level route between UA1 and UA2. No ping.
No traceroute. They live in entirely different networks.
But they can still exchange SIP, because P is a SIP Proxy.
This works in SIP because P can record-route.
-- On a request from UA1 (say, INVITE), toward UA2 adds its interface
(the one facing UA2) to the Record-Route header field.
-- UA2 stores the set of Record-Route header field values in case it
wants to send a request trhough P to UA1 later.
-- UA2 replies to the request, including the received Record-Route
header field.
-- P edits the record-route header field value corresponding to its
interface facing UA2 and changes it to have the addressing value
associated with its interface facing UA1. This little blurb is buried
way down in the SIP spec -- we really don't talk about multihomed
proxies very much.
-- UA1 stores the Record-Route header field values in case it ever wants
to talk to UA2 again.
The stored record-Route header field values are later used to construct
Route header fields, which are inserted in furture requests (such as
BYE).
So far, so good. It works.
But there has been an odd thing: the route, as seen by UA1, is entirely
different from the route as seen by UA2.
-- UA1 stored a route of 10.1.1.1
-- UA2 stored a route of 192.168.2.1
This odd thing has two serious implications:
1) UA2 cannot sign the route set, because it gets edited by P in the
response. Consequently, end-to-end protection of the route set can not
be supported by the protocol. We've just broken the openness principle
and the end-to-end principle. Oops.
2) P must implement special "multihomed" logic. On the request phase, it
goes through output interface calculation and writes the output
interface into the route. It must then inspect all responses, grep for
an input interface, and selectively edit them to reference the correct
output interface. This is a CPU drag.
Implications for Path and Service-Route
---------------------------------------
As currently written, the Path header field accumulates in the same
manner as Record-Route. It gets written on the request. The Path draft
doesn't say what happens for a multi-homed host, so we assume it works
like Record-Route (it does say that), so it gets set to the interface
facing the registrar. This works just fine for the documented purpose of
path, finding the route from the registrar back to the UA.
But, people want to use the Path to calculate the route from the UA to a
service proxy associated with the registrar (Service-Route). Since only
the interfaces facing the registar are stored in Path, we have to use
configured information about the network to guess what the "other" side
might be. This is not all that useful -- it requires lots of tricky
configuration. Tricky configuration is BAD when we have an alternative.
One proposal is to let P edit Service-Route on the return stroke, just
like Record-Route. This would probably work, but conflicts with the
security requirements on Service-Route, requries special behavior in P,
and so forth. In other words, its bad for all the same reasons that the
Record-Route processing is bad, and then some.
Suggestion -- Symmetrize the Route with In-Out Record-Routing
-------------------------------------------------------------
What if proxies doing record-routing inserted a Record-Route header
field value for the receiving interface, and iff the sending interface
were different, inserted another Record-Route header field value for the
sending interface?
In the case of our example, P would add both 10.1.1.1 and 192.168.2.1
The result as I see it:
1) All routes would be fully symmetric -- that is, the route from UA1 to
UA2 would be the exact inverse of the route from UA2 to UA1
2) Service-Route could be derived directly from Path
3) End-to-end protection could be used for Record-Route and Path and
Service-Route
4) P would, executing normal loose-routing logic, see each request twice
-- that is, it would pop the recieving interface, send the result to the
next hop (in this case the outgoing interface), then process again,
popping the outgoing interface and passing the request on. Of course,
the application logic in P COULD be enhanced to prevent double
processing. After all, we really haven't said a whole lot about how a
multi-homed proxy really works in the SIP specs so far.
5) Routes would be slightly larger, as they would carry information
about both sides of a multihomed proxy.
6) Path could continue to work as currently specfied, save for a
reference that multihomed proxies supporting Path should also do "In-Out
Record-Routing"
7) Service-Route could work as desired, provided it also require
supporting proxies to use In-Out Record-Routing
8) Response processing in a proxy becomes transparent. Everything tricky
is done in the request processing phase. Reponse processing just adds
another outer compare and pop.
I THINK the described behavior would be highly backward compatible,
requiring changes only in multihomed proxies supporting the new
behaviors.
Path Forward:
If nobody convinces me this is just a freaking bad idea, I propose to
document the record-route behavior in a new draft, and edit the
Service-Route draft to reference the behavior and describe how to
generate service-routes from record-routes. I believe all the
implications for Path (currently in rfc-ed queue) can be handled
entirely within the Service Route draft.
--
Dean
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip