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

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=40cisco.com@dmarc.ietf.org> wrote:
> 
>  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 <naveen.sarma@gmail.com> 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 <noreply@ietf.org> 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.
>>> 
>>> 
>>> 
>>> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call