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

[Sean Olson <seancolson@yahoo.com>]

This should certainly work. It seems to be
more of an implementation detail than a 
SIP protocol change. Is it proposed that all
multi-homed implementations would have to insert
two Record-Route: headers?

Sean Olson
Microsoft

--- John.Hearty@level3.com wrote:
> 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:
> > 
> 
=== message truncated ===


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
_______________________________________________
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