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

["Dean Willis" <dwillis@dynamicsoft.com>]

Yep, INSTEAD of doing the rewrite in the reponse phase, you include 2
addresses (Record-Route header field values, to be technical) in the
request phase. 

--
Dean

> -----Original Message-----
> From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] 
> Sent: Tuesday, October 15, 2002 6:53 AM
> To: 'Sean Olson'; John.Hearty@level3.com; 
> dwillis@dynamicsoft.com; sip@ietf.org
> Cc: mankin@isi.edu
> Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed Prox ies
> 
> 
> I read the proposal as everytime that you would have to do a 
> rewrite on a RR in a response you would have to include 2 addresses.
> 
> George Foti
> Ericsson Canada
> 
> > -----Original Message-----
> > From: Sean Olson [mailto:seancolson@yahoo.com]
> > Sent: Monday, October 14, 2002 8:28 PM
> > To: John.Hearty@level3.com; dwillis@dynamicsoft.com; sip@ietf.org
> > Cc: mankin@isi.edu
> > Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed 
> > Prox ies
> > 
> > 
> > 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
> > 
> 
> 

_______________________________________________
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