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

[Benjamin Kaduk <[e-mail]>]

Hi Ian,

On Fri, Oct 12, 2018 at 07:19:27AM +0000, [e-mail] wrote:
> Hi Benjamin,
> 
> Thanks for the comments. Please see inline below.
> 
> Regards,
> Ian
> 
> On 10.10.18, 17:00, "dhcwg on behalf of Benjamin Kaduk" <[e-mail] on behalf of [e-mail]> wrote:
> 
>     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.
> 
> [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.
> ]

That helps, thank you.

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

I think that helps; thank you!

-Benjamin