Re: [dhcwg] Alissa Cooper's No Objection on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with COMMENT)

[<[e-mail]>]

Hi Alissa,

Thanks for the comment. I've proposed some new text below to address this.

Regards,
Ian 

On 10.10.18, 21:11, "dhcwg on behalf of Alissa Cooper" <[e-mail] on behalf of [e-mail]> wrote:

    Alissa Cooper has entered the following ballot position for
    draft-ietf-dhc-dhcp4o6-saddr-opt-06: No Objection
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    I think this document could benefit from some discussion of the privacy
    considerations associated with the new options specified in the document. E.g.,
    if one were to apply the analysis in RFC 7844, what would the guidance be to
    clients that want to limit the disclosure of information about themselves? (It
    might be "don't use DHCP4o6," but even that is worth saying if that's the best
    advice available.)

[if - proposed new text to be added to the Security Consideration section:

9.1.  Client Privacy Considerations

   [RFC7844] describes anonymity profiles for DHCP clients.  These
   considerations and recommendations are also applicable to clients
   implementing the mechanism described in this document.  As DHCP4o6
   only uses DHCPv6 as a stateless transport for DHCPv4 messages, the
   "Anonymity Profile for DHCPv4" described in Section 3 is most
   relevant here.

   In addition to the considerations given in [RFC7844], the mechanism
   that the client uses for constructing the interface identifier for
   its IPv6 softwire source address (see Section 7.1), could result in
   the device being trackable across different networks and sessions,
   e.g., if the client's softwire IID is immutable.

   This can be mitigated by constructing the softwire source IPv6
   address as per Section 6 of [RFC7597].  Here, the address' IID
   contains only the allocated IPv4 address (and port set identifier if
   [RFC7618] is being used).  This means no additional client
   information is exposed to the DHCP4o6 server, and will also mean that
   the IID will change as the leased IPv4 address changes (e.g., between
   sessions when Section 3.5 of [RFC7844] is implemented).   
]

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