Subject: [dhcwg] Benjamin Kaduk's No Objection on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Oct 2018 07:59:50 -0700

Benjamin Kaduk 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:
----------------------------------------------------------------------

Section 7

   It is also a prerequisite that the client has already learned a
   suitable IPv6 prefix to use for its local softwire endpoint using
   DHCPv6, RA/PIO or another mechanism.

I think I'm confused.  Is the OPTION_S46_BIND_IPV6_PREFIX option a way to
obtain the "suitable IPv6 prefix" above?  If so, then "prerequisite" may
not be the best word to use here.

Section 7.2.1

   Across the lifetime of the leased IPv4 address, it is possible that
   the client's IPv6 will change.  E.g., if there is an IPv6 re-
   numbering event.

nit: The last sentence is a sentence fragment.

Section 9

With address-binding mechanisms such as these we also try to consider the
possibility of binding an unexpected address to an unsuspecting recipient,
e.g., to direct a large flow of traffic to a victim unable to process it
all.  I did not see an immediate way for an attacker to do this, since it
would seem like it would either require DHCPv4 to assign the same address
twice or allow a duplicate v6/v4 softwire binding, but I am not sure I have
the full picture in my head yet.  It would be good to include some text on
this class of attacks, even if it is just "redirecting existing flows to an
unsuspecting victim is not possible because <reason>".

---

From: <[email-masked]>
Date: Fri, 12 Oct 2018 07:19:27 +0000

Hi Benjamin,

Thanks for the comments. Please see inline below.

Regards,
Ian

On 10.10.18, 17:00, "dhcwg on behalf of Benjamin Kaduk" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Section 7

[if - OPTION_S46_BIND_IPV6_PREFIX is supplied to ensure the client can
select the right prefix to use as the softwire endpoint 
from previously configured prefixes via a longest-prefix match
(e.g. to use a routable 2001:: address instead of a ULA).

What about the following re-wording of the paragraph to clear this up?:

Before the dynamic softwire configuration process can commence,
the client MUST be configured with  a suitable IPv6 prefix to be used
as the local softwire endpoint. This could be obtained using
DHCPv6, RA/PIO or another mechanism.
]
    
    Section 7.2.1

[if - re-worded to:

Across the lifetime of the leased IPv4 address, it is possible that
the client's IPv6 will change, e.g., if there is an IPv6 re-
numbering event.
]

    Section 9

[if - What about the following new paragraph in Section 9:

An attacker could attempt to redirect existing flows to a client unable to 
process the traffic. This type of attack can be prevented by implementing
[BCP38] network ingress filtering in conjunction with the BR source address
validation processes described in [RFC7596] Section 5.2 and
[RFC7597] Section 8.1.
]    
    
    _______________________________________________
    dhcwg mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 15 Oct 2018 09:27:52 -0500

Hi Ian,

>     https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/

That helps, thank you.

> validation processes described in [RFC7596] Section 5.2 and

I think that helps; thank you!

-Benjamin