At 3:02 PM -0600 11/26/07, James M. Polk wrote: >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?
I don't think it ever did. Why would it do so now? >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? PIDF-LO resources contain statements about things like retransmission. The intent here is to make sure those reading the SIP message containing a PIDF-LO understand to whom those statements are being made. If you are not the intended recipient, you do not act on the basis of the information in the PIDF-LO; you either forward it along (routing-entity) or ignore it (endpoint). Yes, this expects folks to behave according to the rules in a pidf-lo without encryption forcing them to, or a gun to their head, or any other coercion. That's been the case for pidf-lo resources for a long time now, and it should not come as a suprise to at least those that have followed that discussion. If you would like to re-visit it, expect to be working on this document for a long, long time. >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? Try asking the question "Are there circumstances in which the US can decide not to allow its location to be used in determining where to route the call?" We had that discussion over many months, and, I think the rough consensus was yes. The result of that may well be calls that do not go through--but that is the consequence of the UA-determined behavior. It's their location, and they control it in the PIDF-LO world. >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. There's a difference between "not readable" and "does not desire that the proxy act on it". You don't need all the heavyweight mechanisms of encryption to say to the routing system "the included location is not intended for you; don't do location based routing using it--fail instead". All you need for that is knowledge of the intended recipient. Encryption is available for cases where the end-user feels it is needed, but it should not be required for the base case. >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. If you do that, you are violating both the rough consensus of the GeoPRIV working group, and the use of PIDF-LO as already set out in standards track documents. Don't expect smooth sailing on that. Ted >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:[EMAIL PROTECTED] >>> 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: [EMAIL PROTECTED] >>> ---------------------------------- >>> >>> >>> >>> -----Messaggio originale----- >>> Da: Dean Willis [mailto:[EMAIL PROTECTED] >>> 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 >>> [EMAIL PROTECTED] for questions on current sip >>> Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip >Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
