[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Dean,

Generally, I too like this proposal. As has been pointed out, folks have done it already as an implementation choice, as its backwards compatible.

My only real concern is the strength of this solution (MUST/MAY). I'd rather it be a MAY, and that would be consistent with 3261. However, the interesting bit is that Path specifies that you SHOULD NOT modify the Path in the response, and discusses protecting it with SMIME. Bis, on the other hand, explicitly says that since record-route can be changed by proxies, you shouldn't worry about modifications to it. So, from the path perspective, a MUST or SHOULD on your mechanism would make sense, in order to meet the security requirements that are already there.

So, its kind of odd that we have these divergent behaviors for path and record-route, even though they are supposed to be more or less the same. If the goal is to unify them, then we need to have MAY for both. If the goal is to be consistent with whats there, your new I-D would have to specify SHOULD usage for path/service route, and MAY for 3261. Kind of ugly.

Oh - one other point. The only case in which your proposal WONT work is when the proxy needs to insert an RR into the response based on information in the response. I can't offhand think of a scenario for this, but certainly its possible. By still allowing the modification of the Path/RR, you could handle these cases.

We'll need to add some text about this in 3261bis when the time comes, and fix some of the MUSTS that have been poitned out by George. We'll log them into bugzilla.


-Jonathan R.

Dean Willis wrote:
Excellent response. Thanks, George!
-----Original Message-----
From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] Sent: Tuesday, October 15, 2002 1:21 PM
To: 'Dean Willis'; George Foti (LMC); sip@ietf.org
Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox ies


Quoting RFC 3261, step 4 section 16.6
In a similar fashion, a proxy that receives a request
over TLS, but generates a request without a SIPS URI in the
Request-URI or topmost Route header field value (after the post
processing of bullet 6), MUST insert a Record-Route header
field that is not a SIPS URI.

A proxy at a security perimeter must remain on the perimeter
throughout the dialog.

If the URI placed in the Record-Route header field needs to be
rewritten when it passes back through in a response, the URI
MUST be distinct enough to locate at that time. (The request
may spiral through this proxy, resulting in more than one
Record-Route header field value being added). Item 8 of
Section 16.7 recommends a mechanism to make the URI
sufficiently distinct.


Doesnt the above imply that if you come in a proxy over TLS and leave without TLS and you RR that you need to rewrite RR coming back in responses.


Or that you have two RR entries -- one sips on the secure side, one sip
on the not-secure side. It's effectively like being dual-homed, even on
a single interface. Good catch, this will need to be made clear.

Now quoting the SIGCOMP drafr from Gonzalo revision 01

5) Sending a Response to a Client

A response is sent to the host in the sent-by parameter of the Via
header field. If the topmost Via header field contains the parameter
comp=sigcomp, the response SHOULD be compressed. Otherwise, the
response MUST NOT be compressed.

A proxy performing Record-Route inspects the Record-Route header
field in the response and the Contact header field in the request
that triggered this response (see example in Section 8). It looks for
the URI of the next upstream (closer to the user agent client) hop in
the route set. If this URI contains the parameter comp=sigcomp, the
proxy SHOULD add comp=sigcomp to its entry in the Record-Route header
field. If this URI does not contain the parameter comp=sigcomp, the
proxy SHOULD remove comp=sigcomp (if it is present) from its entry in
the Record-Route header field.

The above implies that we may to need to do rewrite of RR in the response.

Hmm. Could this be accounted for by having "in" and "out" RR heaader
field values as proposed for sips and network adaptation? The one on the
compressed side would list sigcomp, the other one wouldn't. Gonzalo,
what do you think?

So how do we deal with all the cases, will a proxy have to include both addresses in the RR as well. It was not clear to me from your initial e-mail on the topic. Rgds/gf

Good catch. On first thought, I THINK all of these cases can be dealt
with the same way -- by listing separate "in" and "out" Record-Route
header field values whenever they're not the same.

Proposed Rule: When a proxy Record-Routes and the route entering the
proxy differs (name, type, or parameters) from the route exiting the
proxy, the proxy should insert a record-route header field value for
each.

Other people probably know more. People?

--
Dean

_______________________________________________
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


--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.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