Subject: RE: [Sip] Location header

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Jul 2006 11:34:12 -0400

Well, the logical conclusion of this is pretty obvious. Why stop at PIDF-LO and SAML? Create a Body header, composed of a MIME type and a base64 encoded body, into which we can place location information, SAML assertions, SDP, instant messages, or anything else that would ordinarily be placed into a SIP message body. Deprecate the body of SIP messages, and our problems will be solved! Of course, the various Content-* headers would all need to be built into the Body header eventually, but I'm sure that won't stop us.

Rhetoric and layering concerns aside, I think the confidentiality analysis of header vs. body below is unpersuasive. While it is true that a body can be encrypted to prevent proxies from inspecting it, that is surely also true for the base64 encoded blob that would appear in the Body header, and the rational and circumstances associated with encrypting either are identical. A pointer to an external location, from my perspective, has much more interesting and powerful confidentiality properties than an encrypted blob (be it in a body or a header). There is no practical way I am aware of that a single body could be selectively revealed to multiple elements in a SIP message path other than through such a pointer to an external blob. What I mean is that the external server could challenge and selectively authorize requests to fetch the body which originate from various elements in the message path. Compound this with the "unanticipated recipient" problems associated with retargeting and you honestly begin to wonder if any other approach for confidentiality works in SIP.

I am also unpersuaded that an external reference is any more likely to induce loops than proxies using the Body header. After all, if two proxies keep changing the location information in such a way that it causes a loop, it hardly matters if that location information is provided by-reference or by-value - that is a problem with allowing proxies to modify location information at all.

I suspect it is only the integrity differences between header and body that are material here. Headers can be modified, bodies cannot. For some bodies, people argue this is a feature, for others a bug. From time to time people propose a flag signifying "this body can be modified". The current proposed flag is encoding the body as a header. The general problem with such flags, however they are cast, is that they are not themselves integrity-protected, and the recipient of a request has no way to know who applied the flags. So far, despite numerous challenges on numerous occasions, this WG has not exhibited a consensus to overturn the RFC3261 normative language that prevents intermediaries from changing bodies.

In short, I am not convinced that recasting bodies as headers accomplishes anything further than changing their integrity properties, and I remain quite skeptical that changing the integrity properties of bodies is warranted or wise.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, July 12, 2006 7:36 PM
> To: Henning Schulzrinne
> Cc: [email-masked]
> Subject: Re: [Sip] Location header
> 
> 
> Hi Henning,
> 
> I like your idea of using the data URL.
> It would work nicely for PIDF-LO and SAML assertions.
> 
> Ciao
> Hannes
> 
> 
> Henning Schulzrinne wrote:
> > To follow up on the discussion in the SIP group. I think there are  
> > roughly three options for the content of Location:
> > 
> > (1) Point to content in the body  --> can't be modified and 
> cannot be  
> > inserted by proxies (and may not be inspectable by proxies 
> if encrypted)
> > 
> > (2) Point to external location --> can be modified, can be 
> added, but  
> > can induce loops if changed in mid-stream and incurs 
> another failure  
> > mode (and possible security risks if the reference is generally  
> > accessible)
> > 
> > (3) Point to data URL (RFC 2397) as in
> > 
> > Location: data:application/pidf+xml;base64,<base-64 version 
> of PIDF-LO)
> > 
> > Disadvantage: about 30% larger than as body; can't be encrypted  
> > separately (except as XML-DSIG)
> > 
> > Advantages: can be inserted/modified by proxies (similar to 
> (2)), but  
> > avoids difficulty of external reference
> > 
> > I think these three methods all have different 
> time-space-flexibility  
> > trade-offs and thus I suspect they all serve a need.
> > 
> > Henning
> > 
> > 
> > _______________________________________________
> > 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
> 

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Jul 2006 22:18:48 -0400

I'll avoid the temptation to pursue the general reductio-ad-absurdio  
arguments and focus on the proposal at hand. At least from my SIP  
background, SIP headers are appropriate for material meant for  
request routing and that are thus meant to be inspected and/or  
modified by proxies rather than (just) end systems. SDP presumably  
does not fall into that category, even though SBCs seem to think so.

Length or base-64 encoding doesn't seem to be determining factor of  
the use of a header vs. body since I suspect that the base-64 encoded  
version of the "Identity" header, to pick one example, will often be  
larger than the Location header proposal.

Thus, the only remaining difference between

Location: some pointer to a location object
and
Location: some location object

is the value vs. pointer distinction, i.e., one additional layer of  
dereferencing. I fail to see the deep architectural implications of  
this distinction, but maybe these can be explored.

The modifiability of the header vs. body is not a major issue since  
either can be signed (or not). Even in the current conveyance draft,  
a proxy can simply replace one http pointer with another if it  
doesn't like the original one, so I again fail to see the major  
difference.

We've discussed pointer vs. value issues in various places such as  
GEOPRIV, so I don't want to repeat the discussion, particularly since  
I'm likely to miss some of the arguments. My basic concern about  
changeability is not the proxies changing the location but the end  
system having no idea when and how long they need to keep the  
location information up-to-date and available. In some cases, it's a  
good idea for a moving object to update its location store, in others  
(such as routing) it is potentially a bad idea since you could  
suddenly find yourself at a proxy that doesn't know how to route the  
request.  (Picture a car crossing the county boundary where the  
internal county PSAP routing is done by a separate proxy.)

As a side issue, the draft currently provides no guidance on what  
kind of properties the referenced location information needs to have  
(how long to keep, whether it can change or not, etc.). This is more  
than just specifying HTTP GET.

Note that I did not advocate that end systems inserting location  
information use the data: mechanism, as they don't need to. The by- 
value case is mostly of interest in the case that we need a proxy to  
insert location information. Without this case, we wouldn't need the  
location header at all since proxies could just inspect the message  
body and find the location information by disposition information.  
For the case of proxy insertion, the proxy needs to maintain a  
location store that is accessible by all downstream proxies, by  
unknown entities and for unknown periods of time, including external  
(outside-in) traversal of firewalls. It would be nice to have a  
simpler option for that case.

Or are you opposed to proxies inserting location information? If so,  
I apologize for mis-understanding your basic argument.

Henning

On Jul 13, 2006, at 11:34 AM, Peterson, Jon wrote:

>
> Well, the logical conclusion of this is pretty obvious. Why stop at  
> PIDF-LO and SAML? Create a Body header, composed of a MIME type and  
> a base64 encoded body, into which we can place location  
> information, SAML assertions, SDP, instant messages, or anything  
> else that would ordinarily be placed into a SIP message body.  
> Deprecate the body of SIP messages, and our problems will be  
> solved! Of course, the various Content-* headers would all need to  
> be built into the Body header eventually, but I'm sure that won't  
> stop us.
>
> Rhetoric and layering concerns aside, I think the confidentiality  
> analysis of header vs. body below is unpersuasive. While it is true  
> that a body can be encrypted to prevent proxies from inspecting it,  
> that is surely also true for the base64 encoded blob that would  
> appear in the Body header, and the rational and circumstances  
> associated with encrypting either are identical. A pointer to an  
> external location, from my perspective, has much more interesting  
> and powerful confidentiality properties than an encrypted blob (be  
> it in a body or a header). There is no practical way I am aware of  
> that a single body could be selectively revealed to multiple  
> elements in a SIP message path other than through such a pointer to  
> an external blob. What I mean is that the external server could  
> challenge and selectively authorize requests to fetch the body  
> which originate from various elements in the message path. Compound  
> this with the "unanticipated recipient" problems associated with  
> retargeting and you honestly begin to wonder if any other approach  
> for confidentiality works in SIP.
>
> I am also unpersuaded that an external reference is any more likely  
> to induce loops than proxies using the Body header. After all, if  
> two proxies keep changing the location information in such a way  
> that it causes a loop, it hardly matters if that location  
> information is provided by-reference or by-value - that is a  
> problem with allowing proxies to modify location information at all.
>
> I suspect it is only the integrity differences between header and  
> body that are material here. Headers can be modified, bodies  
> cannot. For some bodies, people argue this is a feature, for others  
> a bug. From time to time people propose a flag signifying "this  
> body can be modified". The current proposed flag is encoding the  
> body as a header. The general problem with such flags, however they  
> are cast, is that they are not themselves integrity-protected, and  
> the recipient of a request has no way to know who applied the  
> flags. So far, despite numerous challenges on numerous occasions,  
> this WG has not exhibited a consensus to overturn the RFC3261  
> normative language that prevents intermediaries from changing bodies.
>
> In short, I am not convinced that recasting bodies as headers  
> accomplishes anything further than changing their integrity  
> properties, and I remain quite skeptical that changing the  
> integrity properties of bodies is warranted or wise.
>
> Jon Peterson
> NeuStar, Inc.
>