[dhcwg] Eric Rescorla's Discuss on

Discussion:

Eric Rescorla

2018-10-11 02:12:56 UTC

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

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?

i***@telekom.de

2018-10-12 10:45:12 UTC

Permalink

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" <dhcwg-***@ietf.org on behalf of ***@rtfm.com> 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.

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.

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

]

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 1.

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

S 5.

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

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

Eric Rescorla

2018-10-12 13:54:06 UTC

Permalink

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 11.10.18, 04:13, "dhcwg on behalf of Eric Rescorla" <
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.
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/
----------------------------------------------------------------------
----------------------------------------------------------------------
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).

You probably want to use 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.

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

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

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

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
DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically
configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6
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
https://www.ietf.org/mailman/listinfo/dhcwg

i***@telekom.de

2018-10-15 15:23:19 UTC

Permalink

Hi Eric,

Thanks for the response. Please see inline below.

Regards,
Ian
From: Eric Rescorla <***@rtfm.com>
Date: Friday, 12. October 2018 at 15:55
To: Ian Farrer <***@telekom.de>
Cc: IESG <***@ietf.org>, "draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org" <draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org>, "dhc-***@ietf.org" <dhc-***@ietf.org>, "Bernie Volz (volz)" <***@cisco.com>, "***@ietf.org" <***@ietf.org>
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 <***@telekom.de<mailto:***@telekom.de>> wrote:

On 11.10.18, 04:13, "dhcwg on behalf of Eric Rescorla" <dhcwg-***@ietf.org<mailto:dhcwg-***@ietf.org> on behalf of ***@rtfm.com<mailto:***@rtfm.com>> 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.

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.

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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg

i***@telekom.de

2018-10-30 10:02:04 UTC

Permalink

Hi Eric,

Did you have any thoughts on proposed updates below?

Many thanks,
Ian

From: Ian Farrer <***@telekom.de>
Date: Monday, 15. October 2018 at 17:23
To: Eric Rescorla <***@rtfm.com>
Cc: IESG <***@ietf.org>, "draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org" <draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org>, "dhc-***@ietf.org" <dhc-***@ietf.org>, "Bernie Volz (volz)" <***@cisco.com>, "***@ietf.org" <***@ietf.org>
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 <***@rtfm.com>
Date: Friday, 12. October 2018 at 15:55
To: Ian Farrer <***@telekom.de>
Cc: IESG <***@ietf.org>, "draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org" <draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org>, "dhc-***@ietf.org" <dhc-***@ietf.org>, "Bernie Volz (volz)" <***@cisco.com>, "***@ietf.org" <***@ietf.org>
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 <***@telekom.de<mailto:***@telekom.de>> wrote:

On 11.10.18, 04:13, "dhcwg on behalf of Eric Rescorla" <dhcwg-***@ietf.org<mailto:dhcwg-***@ietf.org> on behalf of ***@rtfm.com<mailto:***@rtfm.com>> 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.

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.

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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg

Eric Rescorla

2018-10-31 00:17:00 UTC

Permalink

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

-Ekr

Post by i***@telekom.de
Hi Eric,
Did you have any thoughts on proposed updates below?
Many thanks,
Ian
*Date: *Monday, 15. October 2018 at 17:23
*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
*Date: *Friday, 12. October 2018 at 15:55
*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
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
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 11.10.18, 04:13, "dhcwg on behalf of Eric Rescorla" <
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.
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/
----------------------------------------------------------------------
----------------------------------------------------------------------
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
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....
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.

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

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
DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically
configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6
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

i***@telekom.de

2018-10-31 16:14:19 UTC

Permalink

Great. Iâll submit a new version with all of the changes when the datatracker re-opens.

Thanks,
Ian

From: Eric Rescorla <***@rtfm.com>
Date: Wednesday, 31. October 2018 at 01:17
To: Ian Farrer <***@telekom.de>
Cc: "***@ietf.org" <***@ietf.org>, "draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org" <draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org>
Subject: Re: FW: [dhcwg] Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)

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 <***@telekom.de<mailto:***@telekom.de>> wrote:
Hi Eric,

Did you have any thoughts on proposed updates below?

Many thanks,
Ian

From: Ian Farrer <***@telekom.de<mailto:***@telekom.de>>
Date: Monday, 15. October 2018 at 17:23
To: Eric Rescorla <***@rtfm.com<mailto:***@rtfm.com>>
Cc: IESG <***@ietf.org<mailto:***@ietf.org>>, "draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org<mailto:draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org>" <draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org<mailto:draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org>>, "dhc-***@ietf.org<mailto:dhc-***@ietf.org>" <dhc-***@ietf.org<mailto:dhc-***@ietf.org>>, "Bernie Volz (volz)" <***@cisco.com<mailto:***@cisco.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
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 <***@rtfm.com<mailto:***@rtfm.com>>
Date: Friday, 12. October 2018 at 15:55
To: Ian Farrer <***@telekom.de<mailto:***@telekom.de>>
Cc: IESG <***@ietf.org<mailto:***@ietf.org>>, "draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org<mailto:draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org>" <draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org<mailto:draft-ietf-dhc-dhcp4o6-saddr-***@ietf.org>>, "dhc-***@ietf.org<mailto:dhc-***@ietf.org>" <dhc-***@ietf.org<mailto:dhc-***@ietf.org>>, "Bernie Volz (volz)" <***@cisco.com<mailto:***@cisco.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
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 <***@telekom.de<mailto:***@telekom.de>> wrote:

On 11.10.18, 04:13, "dhcwg on behalf of Eric Rescorla" <dhcwg-***@ietf.org<mailto:dhcwg-***@ietf.org> on behalf of ***@rtfm.com<mailto:***@rtfm.com>> 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.

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.

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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg