>#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 mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv