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

["George Foti (LMC)" <George.Foti@ericsson.ca>]

Last line should read : that rewriting RR is unavoidable at all times.
Rgds/gf

> -----Original Message-----
> From: George Foti (LMC) 
> Sent: Tuesday, October 15, 2002 12:23 PM
> To: 'Dean Willis'; George Foti (LMC); 'Sean Olson';
> John.Hearty@level3.com; sip@ietf.org
> Cc: mankin@isi.edu
> Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed
> Prox ies
> 
> 
> So what if we needed to do a re-write for SIGCOMP reasons, or 
> SIP/SIPS reasons.
> It seems that regarding RR is unavoidable.
> Rgds/gf
> 
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> > Sent: Tuesday, October 15, 2002 12:04 PM
> > To: 'George Foti (LMC)'; 'Sean Olson'; John.Hearty@level3.com;
> > sip@ietf.org
> > Cc: mankin@isi.edu
> > Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed
> > Prox ies
> > 
> > 
> > 
> > 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