[dhcwg] Benjamin Kaduk's No Objection on

[Benjamin Kaduk]

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

[i***@telekom.de]

Hi Benjamin,

Thanks for the comments. Please see inline below.

Regards,
Ian

On 10.10.18, 17:00, "dhcwg on behalf of Benjamin Kaduk" <dhcwg-***@ietf.org on behalf of ***@mit.edu> 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.
]

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

_______________________________________________
dhcwg mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

[Benjamin Kaduk]

Hi Ian,

Post by i***@telekom.de
Hi Benjamin,
Thanks for the comments. Please see inline below.
Regards,
Ian
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.
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/
----------------------------------------------------------------------
----------------------------------------------------------------------
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).
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.

Post by i***@telekom.de
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.
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>".
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