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:22:34 -0400

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: "Dean Willis" <[email-masked]>
Date: Tue, 15 Oct 2002 12:56:15 -0500

> 
> 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
> 

Perhaps. Could you make the examples more obvious. I'm apparently
suffering from a clue deficiency this morning.

You need to change the record-route header field in response processing
to allow sigcomp? I would think one might compress the R-R like all
(other header fields) but I'm currently not cognizant of a situation
where it would need to be semantically analyzed and changed . . . Of
course I may just not be particularly cognizant at the moment, if ever.

--
Dean