Re: [Geopriv] [geopriv] #37: Section 3

From: James M. Polk ^lt;jmpolk@cisco.com>
Date: Tue Aug 24 2010 - 19:29:39 EDT

At 06:11 PM 8/24/2010, Bernard Aboba wrote:
>James said:
>
> > I have no issues with what's above (even if the
> > formatting didn't translate very well here. I
> > think I have 1 issue with what's below though...
> >
> > >Link layer confidentiality and integrity
> > >protection may also be employed to reduce the
> > >risk of location disclosure and tampering.
> >
> > I don't care for the "may" that's here in this
> > sentence. If this is for implementers it should
> > be a MAY, if it's here for education or configuration it should be a "can".
>
>It does seem odd to me that RFC 3118 is a SHOULD while link layer
>security is not even a MAY. Note that while I added "and integrity"
>to the last sentence, I didn't change the capitalization.

I remember having to talk Allison out of mandating RFC 3118 as a MUST
when writing 3825, and "got away with" it only being a SHOULD,
knowing full well this wouldn't be implemented or configured very
often in the real world.

I think the lowercase "may" in the last sentence ought to be a "can"
instead, mostly because IETF doesn't regularly mandate link layer
technologies be a certain way in order for an IETF technology's use.

IMO of course.

James

>Earlier, Martin had questioned some of the SHOULDs:
>
>"A fault that both sets of text share is an overly strong reliance
>on "SHOULD". There is little guidance to an implementer on what sort
>of reasons might be acceptable for ignoring the "SHOULD". The first
>SHOULD applies to <http://tools.ietf.org/html/rfc3118>RFC 3118, so
>we can take it as read that it will be ignored; the second SHOULD
>talks about not providing location unless requested, which I think
>can be addressed by allowing servers to have some prior knowledge
>about clients."
>
>Here is a (better formatted) version of the proposed text.
>
>
>3. Security Considerations
>
> Geopriv requirements (including security requirements) are discussed
> in "Geopriv Requirements" [RFC3693]. A threat analysis is provided
> in "Threat Analysis of the Geopriv Protocol" [RFC3694].
>
> Since there is no privacy protection for DHCP messages, an
> eavesdropper who can monitor the link between the DHCP server and
> requesting client can discover this LCI.
>
> To minimize the unintended exposure of location information, the LCI
> option SHOULD be returned by DHCP servers only when the DHCP client
> has included this option in its 'parameter request list' (section 3.5
> [RFC2131]).
>
> Where critical decisions might be based on the value of this option,
> DHCP authentication as defined in "Authentication for DHCP Messages"
> [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
> [RFC3315] SHOULD be used to protect the integrity of the DHCP
> options.
>
> Link layer confidentiality and integrity protection may also be
> employed to reduce the risk of location disclosure and tampering.
>
>
>
>
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Tue, 24 Aug 2010 18:29:39 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 24 2010 - 19:30:05 EDT