Re: [secdir] secdir review of draft-forte-lost-extensions-06.txt

["Andrea G. Forte" <[e-mail]>]

Carl,

Thank you for your review. Please read comments inline.

-Andrea


On 8/5/11 4:28 PM, "Carl Wallace" <[e-mail]> wrote:

>I have reviewed this document as part of the security directorate's
>ongoing effort to review all IETF documents being processed by the IESG.
>These comments were written primarily for the benefit of the security area
>directors.  Document editors and WG chairs should treat these comments
>just like any other last call comments.
>
>This draft defines extensions to the LoST protocol defined in RFC 5222.
>Where RFC 5222 focuses on emergency services.  This draft addresses usage
>of the protocol for non-emergency services.  The draft adds three new
>types of <findService> queries: N nearest, within distance X and servedBy.
> The security considerations section is very brief and primarily addresses
>potential problems with a LOST server that provides emergency and
>non-emergency service support being over loaded by non-emergency requests.
> A few additional concerns that may warrant mention in the document are
>below.
>
>Privacy is not mentioned in this draft at all.  RFC 5222 mentions using
>HTTP over TLS.  Queries for some types of non-emergency services may raise
>privacy concerns not associated with seeking emergency services.
>Similarly, the draft does not mention integrity.  The lack of privacy or
>integrity for responses residing in a cache may be worth mentioning as
>well.


[AGF]
As this draft was meant to add functionalities to the LoST protocol (hence
the 'extensions' in the name), I assumed that it was clear that everything
else mentioned in RFC5222 and not mentioned in our draft would still
stand. However, to make this more clear, I have added a paragraph in the
Security section to address your concerns.


> 
>
>The draft does not discuss error handling at all.  Some types of errors
>associated with the extensions do not seem to fit into the errors
>described in RFC 5222.  For example, could a server return an error when a
>requested area was too large for a query?  Is the server allowed to place
>its own limits less than a client requests?  These concerns may not arise
>in 
>the 5222 context, where non-overlapping service regions are a mitigation.


[AGF]
I am not convinced we need additional error messages.
Generally speaking, I do not think the draft should limit what the server
can do with its content. Given a large area, a server could decide to
return the highest rated POIs only, or perhaps a fixed subset, or all of
them. I do not think that we can classify such behaviors as LoST errors.
These seem to be policy issues rather than errors.


>
>Given the commercial focus of the draft, the potential for stale
>information to be returned by a server seems high and probably worth a
>mention.  For example, a pizza service may have closed.


[AGF]
This draft addresses extensions to the protocol used to convey information
about location-based services. The way this information is maintained is
out of scope. 
Similarly, for emergency services, if the boundaries of a PSAP change they
have to be updated in the DB used by the LoST server. The way these are
updated is not in the scope of RFC5222.


>
>Services are identified by URN.  RFC 5222 uses URNs defined in RFC 5031,
>which does not apply here.  Who manages the URNs for this draft?  It's
>worth noting the examples within this draft use different URNs to
>reference the important pizza service.


[AGF]
We have submitted a draft on this very issue in the past and encountered
some resistance. Other people in the IETF thought we should leave this
issue to experts in other non-IETF bodies. We are now trying to resume
such work.
(http://tools.ietf.org/html/draft-forte-ecrit-service-classification-03)


>
>A few nits, on page 11 correct "consinstent".  Also the next to last
>paragraph on page 11 is a little difficult to parse.


[AGF]
Thanks.


>
>