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

[Eric Rescorla <[e-mail]>]

Yes, this seems like it should work. If you want to make these changes, I
will clear my discuss.

-Ekr


On Tue, Oct 30, 2018 at 3:02 AM <[e-mail]> wrote:

> Hi Eric,
>
>
>
> Did you have any thoughts on proposed updates below?
>
>
>
> Many thanks,
>
> Ian
>
>
>
> *From: *Ian Farrer <[e-mail]>
> *Date: *Monday, 15. October 2018 at 17:23
> *To: *Eric Rescorla <[e-mail]>
> *Cc: *IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "Bernie Volz (volz)" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Subject: *Re: [dhcwg] Eric Rescorla's Discuss on
> draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)
>
>
>
> Hi Eric,
>
>
>
> Thanks for the response. Please see inline below.
>
>
>
> Regards,
>
> Ian
>
> *From: *Eric Rescorla <[e-mail]>
> *Date: *Friday, 12. October 2018 at 15:55
> *To: *Ian Farrer <[e-mail]>
> *Cc: *IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "Bernie Volz (volz)" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Subject: *Re: [dhcwg] Eric Rescorla's Discuss on
> draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)
>
>
>
> 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?
>
>
>
> [if – I see what you mean. I think this can be cleared up with an
> additional
>
> Check at the server:
>
>
>
> 8.2.  Handling Conflicts Between Client's Bound IPv6 Source Addresses
>
>
>
>    In order for traffic to be forwarded correctly, each CE's softwire
>
>    IPv6 source addresses must be unique.  To ensure this, on receipt of
>
>    every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR,
>
>    the DHCP 4o6 server MUST check the received IPv6 address against all
>
>    existing CE source addresses stored for active client IPv4 leases.
>
>    If there is a match, then the client's source address MUST NOT be
>
>    stored or updated.
>
>
>
>    Depending on where the client and server are in the address leasing
>
>    lifecycle, the DHCP 4o6 server then takes the following action:
>
>
>
>    o  If the DHCP 4o6 does not have a current, active IPv4 address lease
>
>       for the client, then the DHCP address allocation process has not
>
>       been successful.  The server returns a DHCPNAK message to the
>
>       client.
>
>    o  If the DHCP 4o6 does have a current, active IPv4 address lease,
>
>       then the source address update process (see Section 8.1) has not
>
>       been successful.  The DHCP 4o6 server can either silently drop the
>
>       client's message or return a DHCPACK message containing the
>
>       existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR.
>
> ]
>
>
>
>
>
> 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.
>
>
>
> [if – OK]
>
>
>
>       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
>
>
>
> [if – Do you think that the changes I’ve proposed now address this?]
>
>
>
>
>
>       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....
>
>
>
> [if – OK. What about the following:
>
>
>
> 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 random based client identifier (see
>
>     [RFC7844] Section 3.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.....
>
>
>
> 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
>
>
>