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

From: "George Foti (LMC)" <[email-masked]>
Date: Tue, 15 Oct 2002 14:20:35 -0400

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 yyou need to rewrite RR coming back in
responses.

 Now quoting the SIGCOMP drafr from Gonzala 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.

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

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, October 15, 2002 1:56 PM
> To: 'George Foti (LMC)'; [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
> > 
> 
> 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
> 
_______________________________________________
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 14:16:03 -0500

Excellent response. Thanks, George!

> From: George Foti (LMC) [mailto:[email-masked]] 
> Sent: Tuesday, October 15, 2002 1:21 PM
> To: 'Dean Willis'; George Foti (LMC); [email-masked]
> Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed Prox ies
> 
> 
> 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
> 

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 16 Oct 2002 16:36:32 +0300

Dean,

> compressed side would list sigcomp, the other one wouldn't. Gonzalo,

When SigComp is used, you need to re-write your RR header when the last
proxy that RRed added comp=SigComp and the next one will not use it.
 
Previous P           P                   Next P
   |                 |                     |
   |   compression   |  no compression     |

Your RR in the INVITE will be used for "Next P" to send you requests, so
it should not contain comp=sigcomp. Your RR in the 200 OK will be used
by "Previous P" to send you requests, so it should have comp=sigcomp.

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.

We could add a section about this in the SigComp-SIP draft so that
everything is clear. If a proxy is routing a message to itself, it would
be safe to ignore comp=sigcomp and "send" the request uncompressed.

Thanks,

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Oct 2002 00:53:22 -0400

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.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com