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

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Oct 2018 19:12:56 -0700

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.

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

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?

---

From: <[email-masked]>
Date: Fri, 12 Oct 2018 10:45:12 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    DETAIL
    S 9.

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

    S 1.

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

[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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Oct 2018 06:54:06 -0700

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 <[email-masked]> wrote:

>
>
> On 11.10.18, 04:13, "dhcwg on behalf of Eric Rescorla" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

You probably want to use NOT RECOMMENDED.

>          intercept or interfer with traffic flows to the client.

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

>          based client identifier (see [I-D.ietf-dhc-rfc3315bis]

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

LGTM.

]
> - allocating a network address" of RFC2131?]

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

-Ekr

---

From: <[email-masked]>
Date: Mon, 15 Oct 2018 15:23:19 +0000

Hi Eric,

Thanks for the response. Please see inline below.

Regards,
Ian
From: Eric Rescorla <[email-masked]>
Date: Friday, 12. October 2018 at 15:55
To: Ian Farrer <[email-masked]>
Cc: IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Bernie Volz (volz)" <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

On 11.10.18, 04:13, "dhcwg on behalf of Eric Rescorla" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    DETAIL
    S 9.

[if – OK]

a problem

[if – Do you think that the changes I’ve proposed now address this?]

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

    ]

    S 1.

OLD:

LGTM.

]

    S 5.

-Ekr

    _______________________________________________
    dhcwg mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/dhcwg

---

From: <[email-masked]>
Date: Tue, 30 Oct 2018 10:02:04 +0000

Hi Eric,

Did you have any thoughts on proposed updates below?

Many thanks,
Ian

From: Ian Farrer <[email-masked]>
Date: Monday, 15. October 2018 at 17:23
To: Eric Rescorla <[email-masked]>
Cc: IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Bernie Volz (volz)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dhcwg] Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)

Hi Eric,

Regards,
Ian

Thanks for your note

    DETAIL
    S 9.

[if – OK]

    ]

    S 1.

OLD:

LGTM.

]

    S 5.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Oct 2018 17:17:00 -0700

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 <[email-masked]> wrote:

> *From: *Ian Farrer <[email-masked]>
> *Date: *Monday, 15. October 2018 at 17:23
> *To: *Eric Rescorla <[email-masked]>
> *Cc: *IESG <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "Bernie Volz (volz)" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [dhcwg] Eric Rescorla's Discuss on
> draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)
>
>
>
> Hi Eric,
>
>
>
> *From: *Eric Rescorla <[email-masked]>
> *Date: *Friday, 12. October 2018 at 15:55
> *To: *Ian Farrer <[email-masked]>
> *Cc: *IESG <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "Bernie Volz (volz)" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [dhcwg] Eric Rescorla's Discuss on
> draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)
>
>
>
> Thanks for your note
>
>
>