RE: R: R: [Sip] a question about IETF draft location conveyance 09

["James M. Polk" <[e-mail]>]

This also gets back to one of my original points, does SIP expect a 
UAC to understand the topology of a message's path to the ultimate destination?

Is Ted's intent of the "recipient=endpoint" parameter to prevent 
proxies from reading location in a message *and* a "recipient=server" 
parameter to prevent endpoints from reading location in a message?

Does the UAC always know that there are only proxies between it and 
the destination UAS?

Does the UAC always understand a particular message does or does not 
need to be routed based on the location within the request?

Emergency services is an example of, always allow proxy routing when 
the UAC knows this is an emergency request.  But will this be true 
for all applications of location conveyance in the (relatively 
near-term) future?  I'm not so sure.

The UAC has a mechanism for making location not readable by proxies 
if it doesn't want them to, use encryption e2e.  But this has 
interesting properties in at least one case, the a user calls the 
nearest Pizza Hut.

A UAC can encrypt its location in the first INVITE, but if Pizza Hut 
has a national or regional number, that routes on the location of the 
caller, the message will probably return a 493 (undecipherable).

Does the UAC then send location to PizzaHut.com unencrypted, knowing 
this is required to get the INVITE to the right store?

There are other usages of this, other than Pizza Hut.

Does anyone have a suggestion for informative text that can address 
each of these two (or more) situations?

At the moment, all text around "recipient=" is suggestive, and not 
definitive, because of what Dean says below.

That said, I could put something in like "unless a future standards 
track RFC says otherwise, the use of "recipient=" parameter within 
any locationValue is informative in nature", thus leaving the door 
open for ECRIT's phoneBCP doc to refine usage in the emergency 
context, as well as any other service defining document to do the 
same type of refinement.

James

At 08:28 AM 11/26/2007, DRAGE, Keith \(Keith\) wrote:
>This just seems to me to be an inappropriate change of RFC 2119 language.
>
>If we really mean either of these, then we should be specifying that 
>the message is encrypted in the first place.
>
>What we probably mean is something informative (because we cannot 
>make a normative statement on what applications do with the data), 
>stating that usage of the message so tagged is inappropriate because 
>the sender did not intend it to be used for this purpose.
>
>Regards
>
>Keith
>
> > -----Original Message-----
> > From: daniel grotti [mailto:[e-mail]]
> > Sent: Saturday, November 24, 2007 11:38 AM
> > To: Dean Willis
> > Cc: IETF SIP List; James M. Polk
> > Subject: R: R: R: [Sip] a question about IETF draft location
> > conveyance 09
> >
> > I know.
> > May be SHOULD NOT instead MUST NOT could be better.
> >
> > daniel
> >
> >
> > ----------------------------------
> >        Daniel  Grotti
> > D.E.I.S. - University of Bologna
> > ----------------------------------
> >        Via Venezia, 52
> >   47023 Cesena (FC) - ITALY
> > ----------------------------------
> > e-mail: [e-mail]
> > ----------------------------------
> >
> >
> >
> > -----Messaggio originale-----
> > Da: Dean Willis [mailto:[e-mail]]
> > Inviato: sab 24/11/2007 2.32
> > A: daniel grotti
> > Cc: Hannes Tschofenig; IETF SIP List; James M. Polk
> > Oggetto: Re: R: R: [Sip] a question about IETF draft location
> > conveyance 09
> >
> >
> > On Nov 22, 2007, at 12:08 PM, daniel grotti wrote:
> >
> > > Hi all,
> > > so why don't emphasize this point in the next draft, saying :
> > > "Proxy server MUST not read messages with "recipient=endpoint"
> > > paramenter setted".
> > > This is my point of you.
> > >
> > >
> >
> >
> > because from a security standpoint, this prohibition is meaningless.
> > Intermediate nodes can and will read anything that's in
> > plaintext, and SOMEBODY will come up with a rationale, in
> > some context or another, for doing so.
> >
> > And has been pointed out, doing so does not appear to create
> > a compatibility problem. It doesn't break the protocol. It
> > might defeat security-through-obscurity. It might be rude, or
> > otherwise socially unacceptable. But those don't qualify for
> > a MUST level protocol prohibition.
> >
> > --
> > Dean
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > [e-mail] for questions on current sip
> > Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip