Re: [dhcwg] Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hi Eric,

Many thanks for your comments. Please see inline below.

Regards,
Ian

On 11.10.18, 04:13, "dhcwg on behalf of Eric Rescorla" <[e-mail] on behalf of [e-mail]> wrote:

    Eric Rescorla has entered the following ballot position for
    draft-ietf-dhc-dhcp4o6-saddr-opt-06: Discuss
    
    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/
    
    
    
    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------
    
    Rich version of this review at:
    https://mozphab-ietf.devsvcdev.mozaws.net/D5110
    
    
    I believe there are security issues as detailed in this review.
    
    DETAIL
    S 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).
    
    This doesn't seem like a very strong defense. At minimum you need an
    analysis of the level of entropy.
    
    I note that an on-path attacker (as RFC 3552 requires us to consider)
    will have no real problem with this attack. This seems fairly serious.

[if - I 

      A rogue client could attempt to use the mechanism described
      in Section 4.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 interfer 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).
    
    ]

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    S 1.
    >      A dynamic provisioning model, such as using DHCPv4 over DHCPv6
    >      [RFC7341] (DHCP 4o6) allows much more flexibility in the location of
    >      the IPv4-over-IPv6 softwire source address.  In this model, the IPv6
    >      address is dynamically communicated back to the service provider
    >      allowing the corresponding softwire configuration to be created in
    >      the border router (BR).
    
    I'm sure this is obvious to the informed, but it would have helped me
    to have explained that the setting here is that the client has v6-only
    service and is going to get a v4 address and tunnel that over v6.
    

[if - The abstract tries to cover this, but it could be made more clear. How
about:

OLD:
DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically 
        configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6
NEW:
 DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically 
        configuring IPv4 for use as an over-the-top service in a IPv6-only
        network. Softwires are an example of such a service. For DHCPv4 over
        DHCPv6.....
]
    
    S 5.
    >              OPTION_DHCP4O6_S46_SADDR (TBD2) with the IPv6 address which
    >              the client will use as its softwire source address.
    >   
    >      Step 4  The server sends a DHCPv6 'DHCPV4-RESPONSE (21)' message.
    >              OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message.
    >              OPTION_DHCP4O6_S46_SADDR with the client's softwire source
    
    Which of these messages contains the client's assigned IPv4 address?
    It's the DHCPOFFER, right?

[if - DHCPOFFER contains an address proposal for the client, but the actual
allocation is not made until the client sends the DHCPREQUEST for the
address and the server responds with the DHCPACK saying that that the
allocation request has been successful.

Would it be helpful to add a pointer here to Section 3.1 "Client-server interaction 
- allocating a network address" of RFC2131?]
    
    
    _______________________________________________
    dhcwg mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/dhcwg