Subject: [dhcwg] Secdir last call review of draft-ietf-dhc-dhcpv6-pd-relay-requirements-04

From: Christian Huitema via Datatracker <[email-masked]>
Date: Fri, 04 Dec 2020 12:03:16 -0800

Reviewer: Christian Huitema
Review result: Ready

This document presents a set of requirements for how "Prefix Delegating Relays" should
handle the relaying of IPv6 Prefix delegation requests between DHCP clients and DHCP servers.

This document is Ready. But please fix one tiny nit.

Prefix Delegating Relays are more complex than simple DHCP relays. Instead of
merely passing information back and forth between DHCP clients and DHCP servers,
they also need to install IPv6 routes so the allocated IPv6 prefix is routed towards
the client to which the prefix is allocated via DHCP. The document explains
issues found during past deployments, and presents a set of requirements to
ensure smooth operation of the service.

As written in the security section, stating these requrements does not add
any new security considerations beyond those mentioned in RFC 8213, which requires
using IPSEC between DHCP relay and DHCP server. This is fine and I believe that
the draft is ready, except for one nit. The draft mentions "Section 22 of [RFC8213]",
but RFC 8213 only has 6 sections. Since that RFC is entirely about "Security of
Messages Exchanged between Servers and Relay Agents", I don't understand why the
draft needs to mention this bogus "Section 22". Are the authors trying to trick
this reviewer?

There is a security issue concerning communication between clients and relays. This
draft is not the place to address it, which is why I think it is ready, but I can't
resist using this review to pass a message to the working group. On link attackers
could spoof requests for prefix delegation, or responses, just like
they can spoof any DHCP message. Spoofing prefix delegation requests might be a way
to attack networks, or to cause support issues between clients and providers.
RFC 8213 "suggests" using secure DHCPv6 between client and server, but the "secure
DHCPv6" draft cited in RFC 8213 is now expired. I understand that solutions like RA
Guard will in practice provide some protection, but the use of these solutions are
not discussed in RFC 8213. The DHCP WG might want to address that.

---

From: Naveen Kottapalli <[email-masked]>
Date: Mon, 7 Dec 2020 16:35:37 +0530

Thanks Christian.  Reference is corrected and will be available in next
version.

Yours,
Naveen.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 7 Dec 2020 12:31:15 +0000

FYI:

I understand that solutions like RA
Guard will in practice provide some protection, but the use of these solutions are
not discussed in RFC 8213. The DHCP WG might want to address that.

RFC8415’s security considerations is rather extensive and includes reference to many techniques to reduce the issues. 8213 was written while 8415 was under development.

- Bernie

On Dec 7, 2020, at 6:06 AM, Naveen Kottapalli <[email-masked]> wrote:

Thanks Christian.  Reference is corrected and will be available in next version.

Yours,
Naveen.

On Sat, 5 Dec 2020 at 01:34, Christian Huitema via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Christian Huitema
Review result: Ready

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Dec 2020 08:03:22 -0500

Also, Christian, RA guard only works in a managed environment. In an unmanaged environment it will break things. It would be wise to be careful about when and where you recommend it or we will wind up with interoperability problems. This is probably outside of the DHC wg’s bailiwick. 

> On Dec 7, 2020, at 07:32, Bernie Volz (volz) <volz=[email-masked]> wrote:
> 
>  FYI:
> 
>>> On Sat, 5 Dec 2020 at 01:34, Christian Huitema via Datatracker <[email-masked]> wrote:
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Dec 2020 17:06:21 -0800

On 12/7/2020 4:31 AM, Bernie Volz (volz) wrote:
> RFC8415’s security considerations is rather extensive and includes 
> reference to many techniques to reduce the issues. 8213 was written 
> while 8415 was under development.

In the context of the draft, I am concerned in particular with the 
"resource-exhaustion" DoS attack, through exhaustion of delegatable 
prefixes. The attack is mentioned in the security section of 8415, but I 
have not seen the proposed mitigation.

-- Christian Huitema

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Dec 2020 02:01:32 +0000

There really aren’t any. Clients can generate different client-id and request prefix after prefix.

However, as this document points out these relays usually have limits to what it may track (and likely it would drop those packets from reaching client).

In some deployments, the number of prefixes allowed behind a particular relay is limited (at server or relay). Other mitigations may be shorter leases as then it comes down to how many can be requested during that time.

The main question is what does this benefit anyone? It is a DoS but in general it has limited impact as prefixes tend to be topological, so it isn’t like you could assign all of the prefixes an ISP has — just what is allowed on that link.

Why do you think this is a new issue that needs to be fixed in this document?

In my experience we have not seen these kinds of attacks as they aren’t very useful. And it has been a dhcp issue since dhcpv4 (addresses were much more scarce).

We tried securing dhcpv6...but it isn’t an easy problem to solve.

- Bernie

On Dec 7, 2020, at 8:06 PM, Christian Huitema <[email-masked]> wrote:

In the context of the draft, I am concerned in particular with the "resource-exhaustion" DoS attack, through exhaustion of delegatable prefixes. The attack is mentioned in the security section of 8415, but I have not seen the proposed mitigation.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Dec 2020 17:11:33 -0800

On 12/7/2020 5:03 AM, Ted Lemon wrote:
> Also, Christian, RA guard only works in a managed environment. In an 
> unmanaged environment it will break things. It would be wise to be 
> careful about when and where you recommend it or we will wind up with 
> interoperability problems. This is probably outside of the DHC wg’s 
> bailiwick.

But I am being careful -- I am not asking for any change in the draft, 
except for a trivial nit. I am just pointing out that there are attacks 
and that the proposed solution in 8213 did not pan out. It would be nice 
is there was guidance available on how to secure DHCP clients and 
servers "in practice", especially if your attack model includes virus of 
fishing attacks overtaking an authorized client inside the perimeter.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Dec 2020 19:17:14 -0800

I do not think this is a new issue that should be fixed in this document. I have written that a couple times already. I do think that it would be nice to work on another document describing best practices to secure DHCP services.

-- Christian Huitema 

> On Dec 7, 2020, at 6:01 PM, Bernie Volz (volz) <[email-masked]> wrote:
>