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

[Naveen Kottapalli <[e-mail]>]

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 <
[e-mail]> wrote:

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