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

"James M. Polk" <jmpolk@cisco.com> Tue, 24 August 2010 22:55 UTC

Message-Id: <201008242255.o7OMtpj9005609@sj-core-2.cisco.com>
Date: Tue, 24 Aug 2010 17:55:50 -0500
To: geopriv issue tracker <trac@tools.ietf.org>, bernard_aboba@hotmail.com, martin.thomson@andrew.com
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <076.67733666628b3be15b2c9016bc2fe240@tools.ietf.org>
References: <067.9168665e27c42ab3edfebb880650885b@tools.ietf.org> <076.67733666628b3be15b2c9016bc2fe240@tools.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] [geopriv] #37: Section 3
Precedence: list

At 04:16 PM 8/24/2010, geopriv issue tracker wrote:
>#37: Section 3 
>------------------------------------------+--------------------------------- 
>Reporter:  bernard_aboba@               | 
>  Owner:  bernard_aboba@ 
>¦                Type:  defect 
>       |       Status:  closed 
>  Priority:  major                         | 
>Milestone:  draft-ietf-geopriv-3825bis 
>Component:  rfc3825bis                    | 
>Version:  1.0                       Severity: 
>Waiting for Shepherd 
>Writeup  |   Resolution:  fixed 
>    Keywords:                                | 
>------------------------------------------+--------------------------------- 
>Changes (by bernard_aboba@):    * status:  new 
>=> closed   * resolution:  => fixed Comment: 
>Here is a potential change to Section 3 to 
>include references to RFC 3693 and 3694, as well 
>as to address the tampering as well as 
>confidentiality issues: 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.

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

IMO of course

James

>-- Ticket URL: 
><http://trac.tools.ietf.org/wg/geopriv/trac/ticket/37#comment:2> 
>geopriv <http://tools.ietf.org/geopriv/> 
>_______________________________________________ 
>Geopriv mailing list Geopriv@ietf.org 
>https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] [geopriv] #37: Section 3 geopriv issue tracker
Re: [Geopriv] [geopriv] #37: Section 3 geopriv issue tracker
Re: [Geopriv] [geopriv] #37: Section 3 geopriv issue tracker
Re: [Geopriv] [geopriv] #37: Section 3 James M. Polk
Re: [Geopriv] [geopriv] #37: Section 3 Bernard Aboba
Re: [Geopriv] [geopriv] #37: Section 3 James M. Polk