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

From: "George Foti (LMC)" <[email-masked]>
Date: Tue, 15 Oct 2002 12:23:32 -0400

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';
> [email-masked]; [email-masked]
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: Tuesday, October 15, 2002 12:04 PM
> > To: 'George Foti (LMC)'; 'Sean Olson'; [email-masked];
> > [email-masked]
> > Cc: [email-masked]
> > 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:[email-masked]] 
> > > Sent: Tuesday, October 15, 2002 6:53 AM
> > > To: 'Sean Olson'; [email-masked]; 
> > > [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > 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:[email-masked]]
> > > > Sent: Monday, October 14, 2002 8:28 PM
> > > > To: [email-masked]; [email-masked]; 
> [email-masked]
> > > > Cc: [email-masked]
> > > > 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
> > > > 
> > > > --- [email-masked] 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:[email-masked]]
> > > > > > Sent: Monday, October 14, 2002 4:25 PM
> > > > > > To: [email-masked]
> > > > > > Cc: [email-masked]
> > > > > > 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 [email-masked] for questions on 
> current sip
> > > > Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 16 Oct 2002 11:43:21 -0400

I think Dean's suggestion was that an optimizing proxy can detect itself in
the second Route and just do all the processing internally without sending
the request to the network ("processing" here would effectively mean just
popping that second Route header if I understand his proposal correctly).

As an aside, let me also say that I really like this proposal:) The only
potential problem I can see with it is that there might be situations when a
proxy would really send a request to itself doing somewhat different types
of processing the second time around and R-R both times. The optimizing
proxy may have problems determining if it can just pop the second Route
header or if it actually needs to do some additional processing. I guess if
the proxy is really optimizing, it could detect it's about to send the
request to itself and do all the processing internally the first time
around...

Thank you,
Igor Slepchin

> From: Gonzalo Camarillo [mailto:[email-masked]]
> <...>
> If you use your double-RR trick, you could add comp=sigcomp to RR1
> already in the INVITE and leave RR2 without comp=sigcomp. Everything
> will work fine. However, you would be sending messages to 
> yourself using
> compression.