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

From: James M. Polk ^lt;>
Date: Wed Nov 05 2008 - 18:52:10 EST


comments in-line

At 04:22 PM 11/4/2008, Richard Barnes wrote:
>Here are my thoughts on James's three issues with -retransmission-.
>>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".

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' ).

>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.

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.
>>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

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.
>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.

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.
>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 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.
>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.

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


>path are

>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


> 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).

Geopriv mailing list
Received on Wed, 05 Nov 2008 17:52:10 -0600

This archive was generated by hypermail 2.1.8 : Wed Nov 05 2008 - 18:52:32 EST