[dhcwg] Benjamin Kaduk's No Objection on draft-ietf-dhc-dhcpv6-pd-relay-requirements-04: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dhc-dhcpv6-pd-relay-requirements-04: No Objection

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-dhcpv6-pd-relay-requirements/



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

Thanks to Christian Huitema for the secdir review and to all for the
ensuing discussion (even though this draft is agreed to not be the right
place to address the topic of securing the DHCP client/DHCP relay
communications).

Thanks for this document; it's good to see this type of functional
requirements get written out clearly.  That said, I'm not sure I
understand why this document is aiming for Proposed Standard status.  It
seems to make normative requirements for DHCPv6 relay behavior, but does
not have an "Updates:" relationship with RFC 8415 to indicate that
additional requirements are present.  On the other hand, there are no
new protocol mechanisms to indicate that it is a protocol that would be
implemented on its own.  Is it intended to play the role of an
Applicability Statement?

Section 1

   The mechanisms for a relay to inject routes (including aggregated
   ones), on its network-facing interface based on prefixes learned from
   a server via DHCP-PD are out of scope of the document.

Just to check my understanding: the context suggests that the
"network-facing interface" here is the one on the DHCPv6 client side of
the relay, vs the server side.  Is that correct?  (Is the
"network-facing" terminology a term of art?)

   Delegating relay A delegating relay acts as an intermediate device,
                    forwarding DHCPv6 messages containing IA_PD/IAPREFIX

(I agree with Murray that clarification is in order here.)

Section 3.4

   It is an operational reality that client devices with duplicate MAC
   addresses and/or DUIDs exist and have been deployed.  In this
   situation, the operational costs of locating and swapping out such
   devices are prohibitive.
   [...]
   It should be noted that in some access networks, the MAC address and/
   or DUID are used as part of device identification and authentication.
   In such networks, enforcing MAC address/DUID uniqueness is a
   necessary function and not considered a problem.

It's not entirely clear to me that these two statements are entirely
consistent with each other -- are the costs prohibitive, or not a
problem?  (Putting a caveat on the first statement that it also only
applies to "some" networks, would resolve the apparent disparity.)

Section 3.5

[that loop sounds pretty nasty; I look forward to seeing how it's
resolved]

Section 4.1

   G-6:    The relay MUST implement a mechanism to limit the maximum
           number of active prefix delegations on a single port for all
           client identifiers and IA_PDs.  This value MUST be
           configurable.

This mechanism is important as a security/anti-DoS mechanism; I hope we
note that somewhere.

   G-8:    The delegating relay MUST update the lease lifetimes based on
           the Client Reply messages it forwards to the client and only
           expire the delegated prefixes when the valid lifetime has
           elapsed.

(The string "Client Reply" does not appear in RFC 8415; I'm not sure why
it's capitalized as if it's a term of art.)

Section 4.2

   R-2:    The delegating relay's routing entry MUST use the same prefix
           length for the delegated prefix as given in the IA_PD.

Could this requirement ever interfere with an aggregation scenario?
(What is it trying to prevent?)

   R-3:    The relay MUST provide a mechanism to dynamically update
           ingress filters permitting ingress traffic sourced from
           client delegated leases and blocking packets from invalid
           source prefixes.  This is to implement anti-spoofing as
           described in [BCP38].  The delegating relay's ingress filter
           entry MUST use the same prefix length for the delegated
           prefix as given in the IA_PD.

Is this imposing a more stringent requirement than BCP38 itself (which,
as far as I can tell, restricts itself to "all providers of Internet
connectivity are urged to implement filtering described in this
document" with no normative requirement.  (To be clear, I'm not opposed
to this trend, just wondering if we should note the change more
prominently.)

Section 4.4

   O-1:    The relay SHOULD implement an interface allowing the operator
           to view the active delegated prefixes.  This SHOULD provide
           information about the delegated lease and client details such
           as client identifier, next-hop address, connected interface,
           and remaining lifetimes.

Is this something that draft-ietf-dhc-dhcpv6-yang would provide (and
thus merit an informative reference)?

Section 7

   This document does not add any new security considerations beyond
   those mentioned in Section 22 of [RFC8213].

Thanks for queuing up the reference fix per the secdir review.
I guess both Section 22 of RFC 8415 and all of RFC 8213 are relevant?
Though perhaps the las paragraph of the section is intended to provide
the needed RFC 8213 reference...

   [RFC8213] describes a method for securing traffic between the relay
   agent and server by sending DHCP messages over an IPsec tunnel.  In
   this case the IPsec tunnel is functionally the server-facing
   interface and DHCPv6 message snooping can be carried out as
   described.  It is RECOMMENDED that this is implemented by the
   delegating relay.

I do not see any reference to message snooping in RFC 8213; please
clearify.

Section 8.2

The discussion at
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
combined with the way in which RFC 4443 is referenced ("An ICMPv6 Type
1, Code 6 (Destination Unreachable, reject route to destination) error
message MAY be sent as per [RFC4443], section 3.1." suggest that RFC
4443 would be more properly classified as a normative reference.