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

[<[e-mail]>]

Hi Adam,

Many thanks for your review. Please see inline below.

Regards,
Ian

On 11.10.18, 02:02, "dhcwg on behalf of Adam Roach" <[e-mail] on behalf of [e-mail]> wrote:

    Adam Roach 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:
    ----------------------------------------------------------------------
    
    
    Thanks to everyone involved for the work they did on this document.
    
    I agree with Alissa's request for the addition of privacy considerations.
    
    ---------------------------------------------------------------------------
    
    §7.2.1:
    
    >  the client's IPv6 will change.  E.g., if there is an IPv6 re-
    
    Nit: "...the client's IPv6 address will change."

[if - fixed]
    
    ---------------------------------------------------------------------------
    
    §9:
    
    >  For such an attack to be effective, the attacker would need to know
    >  both the client identifier and active IPv4 address lease currently in
    >  use by another client.  The risk of this can be reduced by using a
    >  client identifier format which is not easily guessable, e.g., by
    >  including a time component for when the client identifier was
    >  generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).
    
    I might be missing something here, but my understanding is that DHCP isn't
    confidential, and so attackers on the same segment might be able to observe
    another client's identifier and IPv4 address in the DHCP traffic itself
    (depending on the nature of the networking equipment). Even if
    this cannot be easily mitigated, I think it's worth mentioning.

[if - I've re-worked this text in response to the Discuss raised by Eric Rescorla. I've
Tried to address your point as well. Here's the new text proposal:

"   A rogue client could attempt to use the mechanism described in
   Section 7.2.1 to redirect IPv4 traffic intended for another client to
   itself.  This would be performed by sending a DHCPREQUEST message for
   another client's active IPv4 lease containing the attacker's softwire
   IPv6 address in OPTION_DHCP4O6_S46_SADDR.

   For such an attack to be effective, the attacker would need to know
   both the client identifier and active IPv4 address lease currently in
   use by another client.  This could be attempted in three ways:

   1.  One customer learning the active IPv4 address lease and client
       identifier of another customer via snooping the DHCP4o6 message
       flow between the client and server.  The mechanism described in
       this document is intended for use in a typical ISP network
       topology with a dedicated layer-2 access network per-client,
       meaning that snooping of another client's traffic is not
       possible.  If the access network is a shared medium then it
       provisioning softwire clients using dynamic DHCP4o6 as described
       here is not recommended.
   2.  Learning the active IPv4 address lease and client identifier via
       snooping the DHCP4o6 message flow between the client and server
       in the aggregation or core ISP network.  In this case, the
       attacker requires a level of access to the ISP's infrastructure
       that means they can already intercept or interfere with traffic
       flows to the client.
   3.  An attacker could attempt to brute-force guessing the IPv4 lease
       address and client identifier tuple.  The risk of this can be
       reduced by using a client identifier format which is not easily
       guessable, e.g., by using a UUID based client identifier (see [I-
       D.ietf-dhc-rfc3315bis] Section 11.5).
]
    
    ---------------------------------------------------------------------------
    
    §10:
    
    >  IANA is requested to update the entry for DHCPv6 Option S46_BR (90)
    >  in the Option Codes table at https://www.iana.org/assignments/
    >  dhcpv6-parameters as follows:
    >
    >  Old entry:
    >
    >  |    90 | S46_BR                  | No                  | No        |
    >
    >  New entry:
    >
    >  |    90 | S46_BR                  | Yes                 | No        |
    
    This is a somewhat unconventional way to represent IANA actions. This format
    does not make sense in a vacuum; and, more importantly, and will lose meaning
    in the case that the corresponding registry table is ever expanded. I also
    note that the name is incorrect (S46_BR instead of OPTION_S46_BR), and that
    the Reference column is omitted (which is relevant, as I believe the intenion
    is to instruct IANA to add this document to the list of references).  Please
    consider reformatting as:
    
      Old Entry:
    
        Value:             90
        Description:       OPTION_S46_BR
        Client ORO:        No
        Singleton Option:  No
        Reference:         [RFC7598]
    
      New Entry:
    
        Value:             90
        Description:       OPTION_S46_BR
        Client ORO:        Yes
        Singleton Option:  No
        Reference:         [RFC7598] [RFCxxxx]
    
    
    >  IANA is also requested to make a new entry for
    >  OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at
    >  https://www.iana.org/assignments/dhcpv6-parameters:
    >
    >  |  TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes               | Yes       |
    
    Similarly:
    
        Value:             TBD1
        Description:       OPTION_S64_BIND_IPV6_PREFIX
        Client ORO:        Yes
        Singleton Option:  Yes
        Reference:         [RFCxxxx]

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