Re: [Gen-art] Gen-ART LC review of draft-ietf-geopriv-http-location-delivery-07

[Ben Campbell <[e-mail]>]

Further comments inline:

Thanks!

Ben.

On May 9, 2008, at 2:02 PM, Mary Barnes wrote:

> Hi Ben,
>
> Thank you for your detailed review. After consulting with the
> contributors, we've come up with the responses embedded below [MB].
>
> Thanks,
> Mary.
>
> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Tuesday, May 06, 2008 5:02 PM
> To: Barnes, Mary (RICH2:AR00); [e-mail];
> [e-mail]; [e-mail]; General Area
> Review Team
> Cc: Robert Sparks; Jon Peterson; Cullen Jennings
> Subject: Gen-ART LC review of
> draft-ietf-geopriv-http-location-delivery-07
>
> I have been selected as the General Area Review Team (Gen-ART)  
> reviewer
> for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
>
> Document: draft-ietf-geopriv-http-location-delivery-07
> Reviewer: Ben Campbell
> Review Date:  2008-05-06
> IETF LC End Date: 2008-05-07
> IESG Telechat date: (if known)
>
> Summary:
>
> This document is almost ready for publication as a proposed standard.
> I have a few questions and comments that should be considered prior to
> publication.
>
> Comments:
>
> -- Substantive comments:
>
> -- I am a little bit confused by the scope of applicability of this
> draft. Section 3, paragraph 1 says "This document assumes that the LIS
> is present within the same administrative domain as the Device (e.g.,
> the access network)." However, section A.3. claims compliance to a
> requirement to the effect of "The design of the L7 LCP MUST NOT  
> assume a
> business or trust relationship between the Application Service  
> Provider
> (ASP) and the Access Network Provider." (It is possibly I am
> misunderstanding what ASP means in this context?)
>
> [MB] The ASP is defined in the RFC 5012 (ECRIT requirements that is a
> normative reference for draft-ietf-geopriv-l7-lcp-ps).  The ASP is the
> entity that provides voice services for example and really should be
> independent of the LIS. The ASP might eventually make use of the
> information that a device gets using HELD, however, the ASP is  
> entirely
> outside the scope of the HELD protocol, which I think is what that
> requirement is saying.  I can see how the response to that requirement
> could be misleading, so I would propose to change as follows:
> OLD:
>   HELD describes a location acquisition protocol and has no
>   dependencies on the business or trust relationship between the ASP
>   and the Access Network Provider.  Location acquisition using HELD is
>   subject to the restrictions described in Section 10.
> NEW:
>   HELD describes a location acquisition protocol between a Device and
>   a LIS. In the context of HELD, the LIS is within the Access Network.
>
>   Thus, HELD is independent of
>   the business or trust relationship between the Application Service
>   Provider (ASP)
>   and the Access Network Provider.  Location acquisition using HELD is
>   subject to the restrictions described in Section 10.
> [/MB]

That helps, thanks.

>
>
> Furthermore, certain aspects of HELD seem to require fairly tight
> coupling between the LIS and the access network. For example, the NIS
> needs to know about any range of addresses for which it is likely to
> have erroneous location info due to VPNs and NATs. The security
> considerations indicate that the network needs to be properly  
> configured
> to avoid ip spoofing attacks, which would seem to indicate at least an
> administrative coupling between the access network provider. It goes  
> on
> to make a normative statement that network configuration SHOULD be
> considered.
>
> A paragraph or two describing the expected network architecture might
> clear this up. Maybe this is covered sufficiently in some of the
> referenced documents?
> [MB] Figure 1 was intended to show the general architectural elements
> relevant to HELD. Draft-ietf-geopriv-l7-lcp-ps defines some more
> specific scenarios, such as DSL, wireless, etc. But, again, these are
> all independent of the Access Network to ASP interface and are only
> addressing the interface between a LIS and the entity (Device in the
> context of the HELD document) requesting the location.
> The LIS and access network need to share a special relationship, but
> attempting to enumerate the options is only likely to limit
> applicability unnecessarily.
> [/MB]

In the context of how the LIS and ASP relate, I think your previous  
response solves the problem. I'm more concerned now about making sure  
the draft is precise on what the relationship between the LIS and the  
access network really needs to be, and what the network operator must  
do to make all this work safely. This really fits more into some of my  
later comments.

>
>
>
> -- I would like to see a little more analysis on the safety of using  
> the
> source IP address as the device identifier. My instinct says that
> reverse routeability may keep this from being a problem--but the
> security considerations do indicate source address spoofing could  
> cause
> LI to be compromised, and add a list of approaches, "one or more" of
> which is recommended to limit the exposure. If there are in fact risks
> of compromise, I think the draft needs some more exhaustive and  
> explicit
> statements of what I must do to avoid such attacks.
> [MB] The first bullet is actually documented as a MUST include the
> "expires" parameter in the protocol section when one uses  
> locationURIs.
> So, perhaps it would resolve your concern to make that first  bullet a
> MUST and rearrange this slightly, since one MUST do both the first
> already and per the subsequent paragraph, the third is really only
> optional in the context of a fixed network. So, I would propose
> something like the following:
> OLD:
>   One or more of the
>   following approaches are RECOMMENDED to limit these exposures:
>
>   o  Location URIs SHOULD have a limited lifetime, as reflected by the
>      value for the expires element in Section 6.5.2.
>   o  The network SHOULD have mechanisms that protect against IP  
> address
>      spoofing, such as those defined in [RFC3704].
>   o  The LIS and network SHOULD be configured so that the LIS is made
>      aware of Device movement within the network and addressing
>      changes.  If the LIS detects a change in the network that results
>      in it no longer being able to determine the location of the
>      Device, then all location URIs for that Device SHOULD be
>      invalidated.
>
>   The above measures are dependent on network configuration, which
>   SHOULD be considered.  For instance, in a fixed internet access,
>   providers may be able to restrict the allocation of IP addresses  
> to a
>   single physical line, ensuring that spoofing is not possible; in  
> such
>   an environment, other measures may not be necessary.
>
> NEW:
>   These exposures are limited by the following:
>
>   o  Location URIs MUST have a limited lifetime, as reflected by the
>      value for the expires element in Section 6.5.2.  The lifetime
>      of location URIs necessarily depends on the nature of the access.
>   o  The network SHOULD have mechanisms that protect against IP  
> address
>      spoofing, such as those defined in [RFC3704].
>   o  The LIS and network SHOULD be configured so that the LIS is made
>      aware of Device movement within the network and addressing
>      changes.  If the LIS detects a change in the network that results
>      in it no longer being able to determine the location of the
>      Device, then all location URIs for that Device SHOULD be
>      invalidated.
>
>   The above measures are dependent on network configuration, which
>   SHOULD be considered.  For instance, in a fixed internet access,
>   providers may be able to restrict the allocation of IP addresses  
> to a
>   single physical line, ensuring that spoofing is not possible; in  
> such
>   an environment, additional measures may not be necessary.
>
> [/MB]

That helps, thanks.

>
>
> -- The lbyr requirements draft includes a SHOULD level requirement  
> that
> a client should be able to cancel location references. HELD does not
> seem to allow for that capability. I know it was only a SHOULD, but  
> was
> there a particular reason to leave it out?
> [MB]  The pre-working group version of HELD had an explicit means to
> void a
> location URI, and provided a means for the Target to set the lifetime
> of the URI. Such a mechanism requires explicit management of Target
> state on the LIS. It was decided by the WG that this wasn't necessary
> for
> the base specification. There is
> one individual submission that currently addresses these
> considerations but no formal approach has been adopted by the WG at  
> this
> stage.
> [/MB]

Understood. Maybe a brief mention the fact that HELD intentionally  
does not support that use case, and the reasoning behind the decision  
would help.

>
>
> -- Section 4.2: I understand that the authz mechanisms for  
> dereferencing
> location URLs constitute a bit of an "elephant in the room". But do we
> really think it is useful to punt entirely on that?
> The referenced doc does not seem all that helpful on the matter.  
> Even an
> example of a potentially useful approach might be helpful. (I realize
> this is not a HELD problem per se, but without some mechanism for  
> it, I
> question the usefulness of location by reference in HELD.) (If we can
> point to a location dereference protocol and claim that spec solves
> this, then no problem.)
> [MB] This should be addressed in the deref-protocol document. I can  
> add
> a reference to that doc, as well, if you think it's necessary.  [/MB]

I'm not sure "necessary" is the right word--but it would certainly  
shortcut any argument about whether _this_ draft needs to solve the  
problem.

>
>
> Section 4.3.1: Should there be normative advice in this section?
> [MB] I'm not clear as to whether you're suggesting we should or should
> not have normative text in this section. We do have normative  
> statements
> in the first paragraph, but there aren't in the second. Part of the
> issue is this text was carefully crafted as a result of WG consensus,
> thus it's perhaps not as strong as some would like. The language was
> softened in this section during the -03 to -04 changes. The
> justification was that we can't mandate behaviors on elements unless
> it's specific to the actual protocol. [/MB]

So I reread the section, and cannot actually find the place I thought  
needed more normative behavior--I think it was a misread on my part.  
However, in the process of re-reading it, I wonder if there is not a  
conflict between the normative advice about the client performing  
discovery prior to the establishment of the VPN, and the architectural  
advice about what VPN device behavior, since if the device follows the  
recommended behavior the VPN response to discovery would never get  
excercised.

I am guessing the intent is to say that the special "closed network"  
guidance is for situations where one might have a good reason to  
ignore the RECOMMENDED advice about client behavior. If that is  
correct, some more precise words to that effect might help.

>
>
> Section 6.2 and 6.2.1: I don't see an obvious way to say I only want  
> to
> get location by value. Is that intentional?
> [MB] Correct. You cannot ask for just "any" location by value. You can
> ask for just one type of location or both types using "exact", but you
> can't do an either/or.  If you want either/or, then you may also get a
> locationURI by just using "any". It makes the protocol slightly more
> complicated to allow that, when it didn't seem like that would be a  
> high
> runner - e.g., if neither of the location by values were available,  
> then
> wouldn't you want to use a locationURI, so this in the end could  
> save on
> the number of requests at the cost of sometimes getting more  
> information
> than you want. [/MB]

Just to make sure I understand: You can request lbyr only, by  
asserting "locationURI" and "exact", but there is nothing I can  
combine with "exact" to get me by-value only. Does that mean that you  
assume it possible to have devices that only understand lbyr, but not  
common to have devices that only understand lbyv? Or that sending by  
value when the device doesn't want it is somehow more damaging than  
sending by reference if the device doesn't want it?

On re-reading the section, I think it would be helpful to talk a  
little more about how the values can be combined. I am somewhat  
confused by the fact that the class of location (geodetic, civic,etc)  
is combined with the way it is transmitted (by value or by reference.)  
Are these not orthagonal?

>
>
> Section 6.3, error code unsupportedMessage:
>
> Wasn't there a normative statement ealier that the LIS MUST ignore
> anything in a request that it does not understand? If so, when would
> this get used?
>
> [MB] The rationale for including this error is take care of any
> totally new messages that are introduced. The earlier statement is
> actually
> a slightly different case, and refers to the
> concept of additional namespace elements being included in an existing
> message.
> For example, if a locationRequest with an identity
> extension in it is sent, the LIS is free to accept the  
> locationRequest,
> but
> ignore the identity extension that it doesn't understand, and
> everything should just work. The unsupportedMessage case would be like
> the Target sending a createContext message to the LIS and the LIS
> being able to send something sensible back to the Target to say I  
> don't
> understand this. These cases are quite different, and the second case
> is actually quite catchable by most XML parsers.
>
> This could probably be addressed by the following change :
> OLD:
> unsupportedMessage:  This code indicates that an element in the XML
>      document for the request, was not supported or understood by the
>      LIS.
>
> NEW:
> unsupportedMessage:  This code indicates that an element in the XML
>      document for the request, was not supported or understood by the
>      LIS.  This error code is used when a HELD request contains a
> document
>      element that is not supported by the receiver.
>
> And, then we should quality that earlier statement in section 5.2 as
> follows:
> OLD:
>   The LIS MUST ignore any part of a location request message that it
>   does not understand.
> NEW:
>   The LIS MUST ignore any part of a location request message that it
>   does not understand, except the document element.
> [/MB]

Thanks, that helps.

>
>
> 6.5.2: Can you give any guidance about useful value ranges for
> "expires"? I assume very short expirations would not be useful.
> [MB] Correct. These should not have short expirations. We could add
> something like the following at the end of that first paragraph:
> NEW:
>  The "expires" parameter is RECOMMENDED not to exceed 24 hours.
> [/MB]

Should there be a recommended minimum? I can see how very short values  
could cause a lot of poling, or even situations where the location  
object expires before it can be delivered to the consumer.

>
>
> 6.6, last paragraph:
>
> "Note that the presence parameter is not explicitly shown in the XML
>    schema Section 7 for a location response message due to XML schema
>    constraints."
>
> Is that not a problem, since section 7 is the formal definition of the
> protocol syntax?
> [MB] Maybe we should change this to read:
>    "Note that the presence parameter is not explicitly shown in the  
> XML
>    schema Section 7 for a location response message due to XML schema
>    constraints related to the PIDF namespace.  Thus, the "##other"
> namespace serves
>    as a placeholder for the presence parameter in the schema."
> [/MB]

Okay, I guess. I am probably showing my ignorance of XML schema here.  
It just seemed strange that what I thought was an important data  
structure for this protocol is left out of it's formal schema. I don't  
really understand schema enough to grok the "schema constraints"  
causing the issue.

>
>
>
>
> Section 8:
>
> I'm a little confused by the fact that a HELD URI can show up both  
> in a
> HELD response, and in LIS discovery. Does this use of a HELD URI imply
> the use of the HELD protocol? If so, how would a HELD URI in a
> locationReponse message be used? Since HELD uses the source IP address
> for the identifier, it is not useful to transmit the URI to another
> device, right?
>
> [MB] The HELD URI is defined as a fairly general URI that can be used
> both to provide the URI for a LIS and to provide the URI associated  
> with
> a specific location.  And, there may be other uses - the obvious one
> being the dereference. The correlation of the source IP address to a
> specific location URI isn't something specific to HELD - it's the LIS
> that determines the location (using source IP address) and then  
> provides
> the LIS associated location URI in the response.  This document  
> doesn't
> provide a complete description of the usages of the URI (e.g.,
> dereference) and it's not the intention to do so, so maybe that's the
> confusion. The use of the HELD URI within this document is limited by
> the functionality defined in this document, but shouldn't necessarily
> limit the use of the HELD URI overall (if that makes sense). Perhaps
> adding something like the following at the end of that first paragraph
> would help:
> NEW:
>  There are other uses of the HELD: URI, such as
> [I-D.winterbottom-geopriv-deref-protocol].
>  Thus, the usages of the HELD: URI described in this document are not
>  intended to limit the applicability of the HELD: URI to other  
> relevant
> interfaces.
>
> [/MB]

To test my understanding: The deref protocol is a completely different  
protocol than HELD, but the HELD URI semantics work there as well?  
That is to say, that the dereferencer is _not_ using HELD per se, but  
the URI is still useful? I was assuming that the URI type implied the  
use of HELD, which didn't seem to make sense for dereference due to  
the binding to source IP.

I have some mild confusion over making the URI scheme "held" when the  
URI is generally useful across other protocols, but it's probably not  
worth pushing this late in the process (and in my experience the only  
way to win "naming" games is not to play, sort of like for  global  
thermonuclear war.)

[...]

>
>
> Section 6.2. "any" value: The normative statement that the LIS SHOULD
> return all available forms seems to mildly conflict with some of the
> further normative statements in the paragraph.
> [MB] I'm not sure where the conflict is here.  They are all SHOULDs  
> with
> a couple MAYs and the last paragraph explains the reason for the
> SHOULDs. [/MB]

[ Warning: this is highly pedantic--which is why I offered it as a nit  
rather than as a substantive comment.]

I was reading it to say you SHOULD send everything you have, and going  
on to say you SHOULD send certain forms and MAY send others. Since  
anything I could possibly send must be a subset of "everything I  
have", then the second SHOULD and the MAY are either non-constraining,  
or a relaxation of the initial SHOULD.

I would propose either removing the first SHOULD (and maybe indicating  
how sending everything you have by definition fulfills the rest of the  
normative requirements), or making everything except the SHOULD send  
everything you have non-normative.

Of course, it's possible that I am interpreting "SHOULD attempt to  
provide LI in all forms available to it" incorrectly.
>

[...]
_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art