Subject: [Sip] Record-Route, Path, Service Route, and Multi-Homed Proxies

From: "Dean Willis" <[email-masked]>
Date: Mon, 14 Oct 2002 17:24:51 -0500

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:

1) All routes would be fully symmetric -- that is, the route from UA1 to
UA2 would be the exact inverse of the route from UA2 to UA1

2) Service-Route could be derived directly from Path

3) End-to-end protection could be used for Record-Route and Path and
Service-Route 

4) P would, executing normal loose-routing logic, see each request twice
-- that is, it would pop the recieving interface, send the result to the
next hop (in this case the outgoing interface), then process again,
popping the outgoing interface and passing the request on. Of course,
the application logic in P COULD be enhanced to prevent double
processing. After all, we really haven't said a whole lot about how a
multi-homed proxy really works in the SIP specs so far.

5) Routes would be slightly larger, as they would carry information
about both sides of a multihomed proxy.

6) Path could continue to work as currently specfied, save for a
reference that multihomed proxies supporting Path should also do "In-Out
Record-Routing"

7) Service-Route could work as desired, provided it also require
supporting proxies to use In-Out Record-Routing

8) Response processing in a proxy becomes transparent. Everything tricky
is done in the request processing phase. Reponse processing just adds
another outer compare and pop.

I THINK the described behavior would be highly backward compatible,
requiring changes only in multihomed proxies supporting the new
behaviors.

Path Forward:

If nobody convinces me this is just a freaking bad idea, I propose to
document the record-route behavior in a new draft, and edit the
Service-Route draft to reference the behavior and describe how to
generate service-routes from record-routes. I believe all the
implications for Path (currently in rfc-ed queue) can be handled
entirely within the Service Route draft.

--
Dean

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Oct 2002 10:51:56 -0500

Hello Dean:

> Path, Service-route, and a few other things I consider important (like

It also raises (solvable) problems with proxy/registrars being
authoritative entities for multiple domains, each represented by a
different interface.  We've run into some of these while running
on multi-homed machines.

In any case, regarding your specific proposal, it sounds eminently
reasonable.  For much the same reasons as you mention (not so much as
breaking e2e security model as for the intensive task of modifying
R-R responses going upstream; more so if the request has legitimately
spiralled and thus the need to find the appropriately inserted R-R), I
have not been a big fan of R-R response modifications (rfc3261 does
have an example, I believe, in Chapter 17).  Maitaining two Routes
in the Route set leads to simpler processing (optimizing proxies can
prevent double processing, as you point out).

> entirely within the Service Route draft.

Must we come up with a new I-D for this?  It is not new SIP behavior
as much as heuristics/clarification/discussion on how a proxy/registrar
behaves under a multi-homed machine.  I mean, if rfc3261 does not
address multi-homing, can we add a section in Chapter 17?  There are a
list of open issues associated with rfc3261 anyway.  My personal
preference is to add it in rfc3261-bis since the 
heuristics/clarifications/discussions do really belong there.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 15 Oct 2002 11:03:34 -0500

> In any case, regarding your specific proposal, it sounds 
> eminently reasonable. 

Wow! Thanks! It's been  along time since I've done anything eminently
reasonable!

> Must we come up with a new I-D for this?  It is not new SIP 
> behavior as much as heuristics/clarification/discussion on 
> how a proxy/registrar behaves under a multi-homed machine.  I 
> mean, if rfc3261 does not address multi-homing, can we add a 
> section in Chapter 17?  There are a list of open issues 
> associated with rfc3261 anyway.  My personal preference is to 
> add it in rfc3261-bis since the 

Well, the Service-Route specification is a "new" I-D. Actually, it's
completed WGLC and is awaiting final IESG review. Miguel and Gonzalo
raised some valid concerns that it is not as useful as they want. They
want to use it in conjunction with Path (currently in the rfc-ed queue).
Path refers to Record-Route behavior. So the proposed behavior would
probably need to be described in the Service-Route draft in order to
keep Service-Route from being blocked on 3261bis.

I think.

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Oct 2002 11:19:22 -0500

> Wow! Thanks! It's been  along time since I've done anything eminently

Law of averages, Dean; law of averages :-)
I am still waiting for me to do something eminently reasonable.

> keep Service-Route from being blocked on 3261bis.

I was afraid you would say so.  Although, for whatever it is worth, I
really wish we would do it in rfc3261bis, but if we cannot, so be it.
Maybe, when the time comes, we can replicate whatever is in the
Service-Route draft on multi-homed proxies in rfc3261bis -- just to
keep information in one place.

Regards,

- vijay

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 15 Oct 2002 14:24:03 -0500

> > want to use it in conjunction with Path (currently in the rfc-ed 
> > queue). Path refers to Record-Route behavior. So the
> proposed behavior
> > would probably need to be described in the Service-Route draft in 
> > order to keep Service-Route from being blocked on 3261bis.
> 

Absolutely -- I would suggest we document this in 3261bis, but since we
need Service-Route before then, we also document it minimally in
Service-Route. If the writeup in Service-Route doesn't match with what
eventually happens in bis, then we'll need to update Service-Route at
that time.

--
Dean