At 6:21 PM -0600 11/26/07, James M. Polk wrote: >Matt > >in-line > >At 04:06 PM 11/26/2007, Matt Lepinski wrote: >>James, >> >>I do believe that the intent of Ted (as well as others in the GEOPRIV working >>group, including myself) is that if a UAC specifies "recipient=endpoint" then >>a compliant proxy will not 'read' the location body. > >Why isn't the message body not encrypted to make sure the Proxy doesn't? > >What about the situation in which there are multiple proxies between Alice and >Bob, but only one will do anything good with the location. What is >"recipient=" set to, to ensure only the good proxy reads the location body, >and the no-so-good proxies obey the parameter and don't look at the location?
To go back to your first question, how does proxy 1 know that later proxies won't do anything with the location if they are permitted to? Having a UA able to say "permit this for routing-entities/don't permit this for routing-entities" is pretty binary, but discussion in the past covered the problems with trying to enumerate roles beyond that. >>In particular, "recipient=endpoint" indicates that a SIP proxy in the >>signaling path does not have permission to store the location (or any derived >>information) for longer than is necessary to forward the SIP message and does >>not have permission to send the location to any third party (for any reason >>including location-based routing) other than the next-hop SIP proxy. > >The RFC4119 defined PIDF-LO <retransmission-allowed> element (section 2.2.2) >covers this already, for any proxy that reads the message body. Why does this >also need to be in a SIP header parameter? James, we had this discussion over many months in the geopriv working group. You were certainly present for all of that; if you want to summarize the arguments made and detail where you disagree, that would be useful. Acting as if the questions hadn't been asked and answered already is both tedious and tendentious. It's deeply weird to talk to the author of a document that includes all these changes based on those agreements while the author is acting like those changes appeared magically by the action of bad elves. As the previous discussion made clear, relying on "retransmission-allowed" without a clear statement of the intended recipient would bounce a lot of messages, as the default is "no". The suggestion that "no" be considered yes for routing was a non-starter. Recommending that retransmission-allowed be set to "yes" for all the cases of location-based routing would mean both that the intermediate systems could use it *and that the end-user would be able to retransmit it*, which might not be wanted. Your previous draft suggested an update to RFC 4119 to include a "routing-query-allowed" element; geopriv didn't want to make a generic change to 4119 for what seemed like a SIP-specific case when a SIP header mechanism looked like it worked as well or better. (For what it's worth, I agreed with that, but was also personally willing to tolerate the cruft to get the right thing done) Are we back on the same page here? > >fair, but know that I'm a co-author of 3693, and I'm the one who put in the >exception for the emergency case text in that RFC. And we all have agreed, many times, that all bets are off in the emergency case; if an emergency system needs to route based on an included location, it gets to ignore this value. That doesn't change the base design. > >>Alternatively, a location-by-value could be encrypted end-to-end; or location >>could be conveyed by-reference using an LIS with certificate-based access >>controls. The GEOPRIV working group discussed various mechanisms last May >>(See the thread beginning with: >>http://www1.ietf.org/mail-archive/web/geopriv/current/msg03521.html) and I >>believe there was rough consensus that the "recipient=endpoint" mechanism >>described in the current conveyance draft was the best mechanism for >>achieving the above desideratum. > >This is something that the SIP WG needed to be in on, since this is not a >Geopriv header parameter, it is a SIP header parameter. Given that one SIP WG >chair has already said this mechanism is doubtful to work, there needs to be a >more thorough discussion in SIP about this. As I asked before, and Dean reinforced, please start from the GeoPRIV consensus. If you don't do that, we're going to have a long, hard slog through something that is otherwise pretty damn close to done. > >>This seems to leave us with three options going forward: > >Exactly who is "us" in the above? James, come on. How about "those of us who care"? > >>1) Deny the UAC the opertunity to indicate that location is to be read only >>by the SIP endpoint. (That is, declare that SIP is not a GEOPRIV using >>protocol in sense of RFC 3693). > >encryption of the message body does this, all of which is already defined in >SIP (RFC 3261), so this option is not really a choice But without this, you're still left with the same problem. If there is a plain text pidf-lo and "retransmission=no" (remember, kids, that's the default), what does the routing entity do after doing location-based routing? > >>2) Revisit the mechanism discussion and attempt to reach consensus on a >>better mechanism for indicating that location is to be read only by the SIP >>endpoint. > >How doesn't encryption do this? Because e2e encryption isn't available in at least some of the cases we've discussed? >BTW - the discussion needs to be in the Using Protocol's WG, where the >expertise is for that Using protocol. But it has to be based on the principles already set out in the documents that Using Protocol has chosen to reference. You want to re-use GeoPRIV for something, you don't get to ignore those principles. We've been through that several times already, eh? > >>3) Craft text explaining that when the "recipient=endpoint" parameter is used >>that a compliant SIP proxy is not to 'read' the location information. (Note >>that this text should also indicate that when "recipient=endpoint" is used >>that calls requiring location-based routing will fail, and thus should only >>be used when call failure is preferred over disclosure of location >>information to a routing entity.) > >This option is only satisfied when there is an agreeable SIP response with >Geolocation-Error code indication that informs the UAC why this failure >occurred, so it can make an informed decision about what the next step is. regards, Ted > >>- Matt Lepinski >> >> >>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? >>> >>>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:[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 > > >_______________________________________________ >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
