Subject: [secdir] Secdir last call review of draft-ietf-v6ops-cpe-slaac-renum-04

From: Christopher Wood via Datatracker <[email-masked]>
Date: Wed, 09 Sep 2020 16:16:11 -0700

Reviewer: Christopher Wood
Review result: Has Nits

Summary: Has Nits

Comments:

- Section 3: is it possible for an attacker to send DHCPv6 Prefix Delegations
with lifetime=0 to CE routers that support LAN-side DHCPv6 and amplify
Reconfigure messages to supporting clients? (I don't know if this is a concern
or part of the threat model, but this did seem to be a case of possible
request/response asymmetry.) - Section 4: rationale for these default values,
if available, might be worth including. (Why not make them shorter? What are
the tradeoffs?) - Section 6: it might be worth noting what happens if stable
storage is unavailable or otherwise compromised when trying to store prefix
information. What happens if the "A" or "L" bits are modified? (I suspect
nothing dangerous, but it's not clear to me whether or not integrity is
important.)

Nits:

- In some places "\"Valid Lifetime\"" is written as "valid-lifetime" -- should
these be made consistent?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Sep 2020 19:31:56 -0400

> nothing dangerous, but it's not clear to me whether or not integrity is

The attacker on the southbound link would have to know the transaction ID of the DHCP request/confirm/renew message, which is only sent on the northbound interface, and would have to know the DUID and IAID used by the client, again never seen on the southbound link, and would have to know the server’s DUID, again only visible northbound. I don’t think this is a feasible attack. It’s hard to see what the benefit of such an attack would be—in order to effect this attack without knowledge of the exchange on the northbound interface, the client would have to be continuously spamming the southbound link with attempts, so that would be a negative amplication factor of perhaps 2^256, perhaps less if the identifiers can be predicted and renewal times can be predicted.

And this assumes that the DHCPv6 PD client on the CPE device will even accept a DHCP Reply on its southbound interface.

:)

---

From: Uri Blumenthal <[email-masked]>
Date: Thu, 10 Sep 2020 02:17:33 +0000

Capability-wise, what's the likelihood that the attacker would be present on the southbound interface, but *not* on the northbound one?

Sent from my test iPhone

> On Sep 9, 2020, at 19:32, Ted Lemon <[email-masked]> wrote:
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Sep 2020 23:42:43 -0400

There is roughly zero chance of an attacker that is willing to reveal its presence listening on the northbound link. This is a CPE router. The northbound link is a point to point link to the ISP. State actors do not do DoS attacks on home networks. They snoop, or censor, the uplink. 

> On Sep 9, 2020, at 22:17, Uri Blumenthal <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 02:09:41 -0300

Hello, Chris,

Thanks a lot for your comments! In-line....

On 9/9/20 20:16, Christopher Wood via Datatracker wrote:
> request/response asymmetry.)

Not sure what you mean. PDs with a lifetime of 0 are orthogonal to 
Reconfigure messages.

If the client asked for reconfigure support, yes it will be accepting 
server reconfigure messages.

However, Reconfigure messages are required to be unicasted (RFC8415, 
Section 16.11), so there's no possibility for amplification (i.e., 
single server packet triggering actions on multiple clients).

> - Section 4: rationale for these default values,
> the tradeoffs?)

I suggested to add this in response to Dale's comments:

  "  However, while the aforementioned values represent an improvement
     over the default values specified in [RFC4861], they represent a 
trade-off among a number of factors, including responsiveness, possible 
impact on the battery life of connected devices [RFC7772], etc. Thus, 
they may or may not provide sufficient mitigation to the problem 
discussed in this document.
"

?

> - Section 6: it might be worth noting what happens if stable

Compromised as in "an attacked intentionally caused different bits to be 
stored"?

If so, I'd say that's probably the least of your concerns. Since DHCPv6 
exchanges are not encrypted or authenticated, your first concern would 
be forged packets. If the attacker has essentially hacked the CE Router, 
then all bets are off.

> these be made consistent?

We use "Valid Lifetime" for SLAAC PIOs, and "valid-lifetime" for DHCPv6 
options, since that's what the respective specs use. Please do let us 
know if you think this should be clarified.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 03:11:25 -0300

On 9/9/20 23:17, Uri Blumenthal wrote:
> Capability-wise, what's the likelihood that the attacker would be 
> present on the southbound interface, but *not* on the northbound one?

I'm not sure I could talk about "likelihood" in any measurable way.

But I'd argue that, generally speaking, anyone that shares the same 
LAN/Connection will be on the southbound interface (e.g., think of a 
cyber-cafe, university network, enterprise network, or whatever) whereas 
in order to be present on the northbound interface you'd probably 
normally be:

* A rogue ISP
* A state actor, or,
* Somebody that managed to get to the right cable.

For the "normal" attacker, I'd say it's much more likely to be present 
on the south-bound interface, whereas for other cases, I guess it could 
be both.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 17 Sep 2020 11:08:59 -0700

On Wed, Sep 9, 2020, at 4:31 PM, Ted Lemon wrote:
> The attacker on the southbound link would have to know the transaction 
> ID of the DHCP request/confirm/renew message, which is only sent on the 
> northbound interface, and would have to know the DUID and IAID used by 
> the client, again never seen on the southbound link, and would have to 
> know the server’s DUID, again only visible northbound. I don’t think 
> this is a feasible attack. It’s hard to see what the benefit of such an 
> attack would be—in order to effect this attack without knowledge of the 
> exchange on the northbound interface, the client would have to be 
> continuously spamming the southbound link with attempts, so that would 
> be a negative amplication factor of perhaps 2^256, perhaps less if the 
> identifiers can be predicted and renewal times can be predicted.
> 
> And this assumes that the DHCPv6 PD client on the CPE device will even 
> accept a DHCP Reply on its southbound interface.
> 
> :)

That makes sense -- thanks for clarifying!

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 17 Sep 2020 11:11:08 -0700

> single server packet triggering actions on multiple clients).

Got it. Thanks.

> discussed in this document.

This seems reasonable to me.

> Compromised as in "an attacked intentionally caused different bits to be 

Well, either maliciously or not, I suppose. I was just trying to learn if integrity is important. 

> know if you think this should be clarified.

Ah! If that's well understood by others, then it's fine with me. (I wasn't aware of the difference.)

Thanks for following up. :-)

Best,
Chris

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Sep 2020 14:24:35 -0400

[ -LC for clutter ]

Just a quick note to say thanks for the secdir review, and for the
followup discussions, it's always nice when directorate review works
nicely....

W