Subject: Re: [Geopriv] Next steps on -retransmission- (was Re: draft-polk-geopriv-sip-lo-retrans-rec-concerns)

From: Richard Barnes <[email-masked]>
Date: Tue, 04 Nov 2008 17:22:59 -0500

Here are my thoughts on James's three issues with -retransmission-.
--Richard

> 1) An objection to the way the draft uses authorized recipient while 
> describing retransmission recommendations.

As James's draft notes, S3.2 of -retransmission- note that there is 
consensus that by sending a SIP message with location in it, a UAC 
authorizes SIP entities along the path that message will take to access 
the location in that message.  So it seems to me entirely appropriate 
for SIP entities on the path to be referred to as "authorized recipients".

James's concern seems to be more related to the distinction between 
"recipients" and "consumers" -- presumably "LR"s and "Viewers" in 
RFC3693 parlance.  Contrary to James's claim that only consumers/Viewers 
are a security risk (not recipients/LRs), this distinction doesn't seem 
to raise any additional security or privacy concerns if we accept the 
definitions in RFC 3693: Viewers are a restricted class of LRs (a Viewer 
"does not pass [location] information further"), so any entity that is 
authorized to be an LR (as above) is automatically authorized to be a 
Viewer.

In particular, all SIP entities along the path are authorized by the UAC 
(acting as a Location Server and Rule Maker) to be both Location 
Recipients and, in particular, Viewers.  The question is then whether 
these particular LRs/Viewers (namely, SIP entities) are authorized to do 
location-based routing even when retransmission=no; this is the point of 
the "Location-Routing-Allowed" indicator.  Like the document says right 
now:
"
[The <retransmission-allowed>] element is intended to prevent a 
compromise of privacy when an authorized recipient of LI shares that LI 
withthird-party entities, principally those who are not authorized by 
the Rule Maker to receive LI.
"

More briefly, it seems to me like the document's usage of "authorized 
recipient" is entirely clear and sensible.

> 2) An objection to the recommendation of a new header preferring a 
> different syntactic representation.

The current draft is contradictory here: It claims to be proposing  only 
an example syntax, but refers to that syntax elsewhere (e.g., Section 
3.6, "failing to copy any "Location-Routing-Allowed" header value").

The critical thing here is the proposal for a "Location-Routing-Allowed" 
*indicator* semantic, with the properties listed in Section 3.5 -- 
mandatory-to-implement, contained in any message with location, default 
"no", etc.

I would suggest that the document (S3.5 in particular) be edited to 
refer to a generic "'Location-Routing-Aware' indicator", with text such 
as Henning's to note that it could be implemented as a header, a URI 
parameter, etc.

> 3) An objection to what James feels will be interpreted as requirements 
> placed on B2BUAs around forwarding location information.

The argument that someone walking in off the street might interpret 
Section 3.6 as normative is bogus.  No matter what you write, there's a 
risk that your text will be interpreted as normative by someone who 
doesn't know how to distinguish normative from non-normative text. 
There's no RFC 2119 language here, and S3.6 explicitly says that B2BUAs 
are "outside the scope of SIP standardization".  If this is the issue, 
then we should just move on.

That said, I think there's a grain of truth in the argument that the 
suggested behavior for B2BUAs here is too restrictive.  The document 
itself says that "any SIP entity which receives a SIP message containing 
LI through the operation of SIP's normal routing procedures" is an 
authorized recipient.  If "normal routing procedures" include transit 
through a B2BUA, it seems like entities on the far side of the B2BUA 
have exactly as the same authorization status as entities on the near 
side.  So while it's still critical that privacy preferences get passed 
along, it doesn't seem like the B2BUA should have to strip location out.

I'm willing to admit that this is mostly applicable to the case where 
both sides of a B2BUA speak SIP, since other protocols might not have 
appropriate semantics for privacy protection.  (In particular, in the 
general case, the "terminate location at the B2BUA" argument is still 
holds.)  So the only text modification I would suggest is to extend the 
last paragraph of S3.6:
"
If both sides of a B2BUA speak SIP, then the B2BUA is simply another SIP 
entity in the routing of the SIP message.  Thus, the B2BUA and any 
subsequent SIP entities in the path are authorized recipient of any LI 
included in a SIP message that the B2BUA receives.  In this case, when a 
B2BUA receives a SIP message that contains LI, it MAY enclose that LI in 
the corresponding outbound SIP message. However, if the inbound message 
includes a "Location-Routing-Allowed" indicator, the outbound message 
must as well, with the same value as the inbound message.  This ensures 
that all authorized recipient (before and after the B2BUA) are informed 
of the policies of the Rule Maker.
"

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Nov 2008 17:52:10 -0600

Richard

comments in-line

At 04:22 PM 11/4/2008, Richard Barnes wrote:
>>1) An objection to the way the draft uses authorized recipient 
>>while describing retransmission recommendations.
>
>authorizes SIP entities along the path that message will take to 
>access the location in that message.  So it seems to me entirely 
>appropriate for SIP entities on the path to be referred to as 
>"authorized recipients".

part of what I'm getting to is the difference between "authorized 
recipients" in signaling path and freely sending the Location 
Target's LI to every other node on the Internet.  To me, these are 
very different scenarios.  The idea that LbyV means that all entities 
are "authorized recipients" ON the signaling path seems pretty 
obvious. Yet the idea proposed in section 3.6 of retransmission that 
the <retransmission-allowed> MUST be set to 'yes' in order to have 
location in a message be re-initiated is completely different.  In 
the signaling path, there are no 3rd parties - thus 
<retransmission-allowed> can be set to 'no' and the expectation of 
the original UAC is that the destintation UAS will indeed receive the 
UAC's LbyV.  Again, section 3.6 seems to prevent this - that is, 
unless the originating UAC allows their location to be freely 
broadcast on the Internet (i.e., <retransmission-allowed> set to 'yes' ).

>RFC3693 parlance.  Contrary to James's claim that only 
>consumers/Viewers are a security risk (not recipients/LRs), this 
>distinction doesn't seem to raise any additional security or privacy 
>concerns if we accept the definitions in RFC 3693: Viewers are a 
>restricted class of LRs (a Viewer "does not pass [location] 
>information further"), so any entity that is authorized to be an LR 
>(as above) is automatically authorized to be a Viewer.
>
>In particular, all SIP entities along the path are authorized by the 
>UAC (acting as a Location Server and Rule Maker) to be both Location 
>Recipients and, in particular, Viewers.  The question is then 
>whether these particular LRs/Viewers (namely, SIP entities) are 
>authorized to do location-based routing even when retransmission=no; 
>this is the point of the "Location-Routing-Allowed" indicator.  Like 
>the document says right now:

>compromise of privacy when an authorized recipient of LI shares that 
>LI withthird-party entities, principally those who are not 
>authorized by the Rule Maker to receive LI.
>"

in other words, those not on the signaling path, right?

>More briefly, it seems to me like the document's usage of 
>"authorized recipient" is entirely clear and sensible.
>
>
>
>The current draft is contradictory here: It claims to be 
>proposing  only an example syntax, but refers to that syntax 
>elsewhere (e.g., Section 3.6, "failing to copy any 
>"Location-Routing-Allowed" header value").
>
>The critical thing here is the proposal for a 
>"Location-Routing-Allowed" *indicator* semantic

I'm not resisting an *indicator*, I'm resisting the 
"mandatory-to-implement" new SIP header idea.

>, with the properties listed in Section 3.5 -- 
>mandatory-to-implement, contained in any message with location, 
>default "no", etc.
>
>refer to a generic "'Location-Routing-Aware' indicator", with text 
>such as Henning's to note that it could be implemented as a header, 
>a URI parameter, etc.

I already support this text edit from Henning

>>3) An objection to what James feels will be interpreted as 
>>requirements placed on B2BUAs around forwarding location information.
>
>Section 3.6 as normative is bogus.  No matter what you write, 
>there's a risk that your text will be interpreted as normative by 
>someone who doesn't know how to distinguish normative from non-normative text.

<mumble>

>There's no RFC 2119 language here, and S3.6 explicitly says that 
>B2BUAs are "outside the scope of SIP standardization".

if this quoted part is something that shouldn't have text to the 
right of it, why are there 3 more paragraphs then?

I believe you (and others) woefully underestimate the number of folks 
that doesn't understand the difference between informational and 
standards-track when reading a doc.

>If this is the issue, then we should just move on.
>
>suggested behavior for B2BUAs here is too restrictive.

**eureka**

>The document itself says that "any SIP entity which receives a SIP 
>message containing LI through the operation of SIP's normal routing 
>procedures" is an authorized recipient.  If "normal routing 
>procedures" include transit through a B2BUA, it seems like entities 
>on the far side of the B2BUA have exactly as the same authorization 
>status as entities on the near side.  So while it's still critical 
>that privacy preferences get passed along, it doesn't seem like the 
>B2BUA should have to strip location out.

bingo - this is most of what I've been arguing about (in Dublin, on 
the list, and in my counterproposal ID)

>I'm willing to admit that this is mostly applicable to the case 
>where both sides of a B2BUA speak SIP, since other protocols might 
>not have appropriate semantics for privacy protection.  (In 
>particular, in the general case, the "terminate location at the 
>B2BUA" argument is still holds.)  So the only text modification I 
>would suggest is to extend the last paragraph of S3.6:

I've inserted mods to this new text offering

>"
>If both sides of a B2BUA speak SIP, then the B2BUA is simply another 
>SIP entity in the routing of the SIP message.  Thus, the B2BUA and 
>any subsequent SIP entities in the

...signaling...

>path are

..an..

>authorized recipient of any LI included in a SIP message that the 
>B2BUA receives

...and processes...

>.  In this case, when a B2BUA receives a SIP message that contains LI

...s/LI/PIDF-LO  ?...

(do you want to say "LI" here, or "PIDF-LO"? - given that LbyV is 
what we're talking about - and that raw LI is not something that's 
recognized by our specs when discussing SIP)

>, it MAY enclose that LI

...s/LI/PIDF-LO  ?...

>in the corresponding outbound SIP message. However, if the inbound 
>message includes a "Location-Routing-Allowed" indicator, the 
>outbound message must

...MUST...

>  as well, with the same value as the inbound message.  This ensures 
> that all authorized recipient (before and after the B2BUA) are 
> informed of the policies of the Rule Maker.
>"

with my mods, I like this paragraph.  I believe we're not talking 
about LI though here, so that can be further agreed to (or not).

---

From: Richard Barnes <[email-masked]>
Date: Wed, 05 Nov 2008 19:25:59 -0500

Hey James,

> recipients" in signaling path and freely sending the Location Target's 
> LI to every other node on the Internet. 

~snip~

I think we're in violent agreement (with the document, even) on the use 
of "authorized recipient".

The disagreement seems to be where the "signaling path" ends -- at the 
"ultimate" UAS, or at the "UAS side" of a B2BUA.  The retransmission 
document takes the former approach, your document (and my argument 
below) the latter.

So I'd like to claim that this issue is subsumed by Issue 3.

>> The current draft is contradictory here: It claims to be proposing  
>> only an example syntax, but refers to that syntax elsewhere (e.g., 
>> Section 3.6, "failing to copy any "Location-Routing-Allowed" header 
>> value").
>>

For clarity, which are you objecting to?
(A) Suggesting the use of a SIP header, or
(B) Making it mandatory to implement.

If it's (A), then I think there's not an issue here, since there are a 
few proposals to remove or further minimize the text that suggests a 
specific syntax.

If it's (B), then there's a question of scope.  You might be able to 
argue (but would still need to argue it) that it's not mandatory for 
every SIP entity to understand the privacy indicator.  However, it has 
to be mandatory for some class of SIP entities.  It would clearly make 
sense for this indicator to be understood by any SIP entity that 
implements -location-conveyance-.

>> Section 3.6 as normative is bogus.  No matter what you write, there's 
>> a risk that your text will be interpreted as normative by someone who 

Ok, still, I think the text does as much as possible to minimize the 
probability that it will be mis-interpreted.

That said, given that we (you and I) have agreed on the more lenient 
text below, do you think that that's an acceptable risk?  I.e., if 
someone interprets the guidance as normative, it's not going to be too bad?

Revised text below, including your mods, and some editorial fixes of my 
own.  W.r.t. LI/LO, changed to "location information (by value or by 
reference)"
"
If both sides of a B2BUA speak SIP, then the B2BUA is simply another SIP 
entity in the routing of the SIP message.  Thus, the B2BUA and any 
subsequent SIP entities in the signaling path are authorized recipients 
of any LI included in a SIP message that the B2BUA receives.  In this 
case, when a B2BUA receives and processes a SIP message that contains 
location information (by value or by reference), it MAY enclose that LI 
in the corresponding outbound SIP message. However, if the inbound 
message includes a "Location-Routing-Allowed" indicator, the outbound 
message MUST include the indicator as well, with the same value as the 
inbound message.  This ensures that all authorized recipient (before and 
after the B2BUA) are informed of the policies of the Rule Maker.
"

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Nov 2008 22:10:25 -0600

At 06:25 PM 11/5/2008, Richard Barnes wrote:
>>>As James's draft notes, S3.2 of -retransmission- note that there 
>>>is consensus that by sending a SIP message with location in it, a 
>>>UAC authorizes SIP entities along the path that message will take 
>>>to access the location in that message.  So it seems to me 
>>>entirely appropriate for SIP entities on the path to be referred 
>>>to as "authorized recipients".
>>Target's LI to every other node on the Internet.
>
>~snip~
>
>I think we're in violent agreement (with the document, even) on the 
>use of "authorized recipient".

cool (until I read what you say next though... :-(

>The disagreement seems to be where the "signaling path" ends -- at 
>the "ultimate" UAS, or at the "UAS side" of a B2BUA.  The 
>retransmission document takes the former approach,

no it doesn't. If it did, it wouldn't talk about ending or removing 
or stopping anything *at* the B2BUA.  SIP is *always*always* about 
the "signaling path", which includes everything from the originating 
UAC to the destination UAS, regardless if there is any form of a SIP 
proxy in between - or if there are 500 proxies in between.  Anytime a 
doc talks about something stopping prior to the ultimate destination, 
it is talking about the latter example (below), not the former.

>your document (and my argument below) the latter.

How can this be, when my doc talks at great length about forbidding 
B2BUAs from preventing location retransmission (i.e., the former example).

>>>>2) An objection to the recommendation of a new header preferring 
>>>>a different syntactic representation.
>>>
>>>Section 3.6, "failing to copy any "Location-Routing-Allowed" header value").
>>>

I'm resisting Geopriv from declaring to SIP that SIP MUST create a 
mandatory-to-implement header.  It is not Geopriv's place to do this, 
although Geopriv certainly _can_ offer a requirements RFC to SIP for 
SIP to choose whether or not it wants to comply with those 
requirements. That happens all the time.

Case in point, I believe a _new_ SIP header is expressly *not* 
necessary to accomplish this result. I've said so on the list, and 
again on the list, and now in an ID, yet the "retransmission" ID was 
updated a week after my ID was announced in the Geopriv WG.

>If it's (A), then I think there's not an issue here, since there are 
>a few proposals to remove or further minimize the text that suggests 
>a specific syntax.
>
>every SIP entity to understand the privacy indicator.  However, it 
>has to be mandatory for some class of SIP entities.

>It would clearly make sense for this indicator to be understood by 
>any SIP entity that implements -location-conveyance-.

yes it would... and I happen to know the author of that doc, and 
might have an *in* with him   ;-)

>>>The argument that someone walking in off the street might 
>>>interpret Section 3.6 as normative is bogus.  No matter what you 
>>>write, there's a risk that your text will be interpreted as 
>>>normative by someone who doesn't know how to distinguish normative 
>>>from non-normative text.
>>I believe you (and others) woefully underestimate the number of 
>>folks that doesn't understand the difference between informational 
>>and standards-track when reading a doc.
>

Does it, really?

Case in point, does any of the "recommendations" made in the 
retransmission ID closely preceded or followed with words similar to 
"For example, here is one (or a) proposal (blah blah blah)..."

the answer is no, in each case.  Simple word searches will reveal 
this to anyone who wants to look for similar phrases.

>someone interprets the guidance as normative, it's not going to be too bad?

with what you have below, I think this would be good to have in the 
doc (knowing that this is replacement text, and not just added on 
text to section 3.6).

>Revised text below, including your mods, and some editorial fixes of 
>my own.  W.r.t. LI/LO, changed to "location information (by value or 
>by reference)"
>"
>any subsequent SIP entities in the signaling path are authorized 
>recipients of any LI included in a SIP message that the B2BUA 
>receives.  In this case, when a B2BUA receives and processes a SIP 
>message that contains location information (by value or by 
>reference), it MAY enclose that LI in the corresponding outbound SIP 
>message. However, if the inbound message includes a 
>"Location-Routing-Allowed" indicator, the outbound message MUST 
>include the indicator as well, with the same value as the inbound 
>message.  This ensures that all authorized recipient (before and