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

[Eric Rescorla <[e-mail]>]

Thanks for your note

First, let me apologize: I somehow forgot to include that I think Ben's
point is
correct: there seems to be an amplification attack in which I rebind my
IPv4 address to some victim's IPv6 address with the result that they
get a pile of traffic. Do you agree with that?


On Fri, Oct 12, 2018 at 3:45 AM <[e-mail]> wrote:

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

You probably want to use 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.
>

This is true, but generally we consider cheap traffic redirection attacks as
a problem.



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

Is that really the most unguessable? I would have thought the random
one was best....


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

LGTM.

]
>
>     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?]
>

Yes, but i think it would be best to annotate diagram with it.

-Ekr


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