RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Proxies

[John.Hearty@Level3.com]

As I recall, I've already seen at least one vendor doing it the way you
proposed, and it seemed to work OK.

John Hearty
Level3

> -----Original Message-----
> From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> Sent: Monday, October 14, 2002 4:25 PM
> To: sip@ietf.org
> Cc: mankin@isi.edu
> Subject: [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
> 
_______________________________________________
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