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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 16 Dec 2020 13:49:39 -0800

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.

---

From: [email-masked]
Date: Thu, 17 Dec 2020 13:26:26 +0100

Hi Benjamin,

Many thanks for your comments. Please see inline below.

Ian

> On 16. Dec 2020, at 22:49, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

[if - copied from my reply to Murray:

It’s both - the IA_PD option is a contain one or more IAPREFIX options (that hold prefix itself).
Suggest changing to:

“… forwarding DHCPv6 messages containing IA_PD and IAPREFIX …”
]

> applies to "some" networks, would resolve the apparent disparity.)

[if - Suggested reword:

OLD:
"In this situation, the operational costs of locating and swapping out such
  devices are prohibitive."

NEW:
"In some networks, the operational costs of locating and swapping out
such devices are prohibitive."

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

[if - R-5 is intended to solve this]

> This mechanism is important as a security/anti-DoS mechanism; I hope we

[if - Suggest that the following paragraph is added to the Security Considerations

“Failure to implement requirement G-6 may have specific security implications, such
as a resource depletion attack on the relay."

> it's capitalized as if it's a term of art.)

[if - reworded to “client’s reply”]

> (What is it trying to prevent?)

[if - The main problem is where a relay breaks a shorter delegated prefix into multiple /64s wasting its own routing table resources (this
Has been observed). Should we add a problem description for this?

Given where the delegating relay is in the network topology, I don’t see any aggregation problems here.]

> to this trend, just wondering if we should note the change more

[if - BCP38 describes a problem and proposes anti-spoofing
as a solution to this problem. The ‘all providers of Internet…’ is a plea to 
the ISPs to implement this solution as a policy. 

The text above says that the device must be capable of dynamically learning
the delegated prefixes and applying filters based on those learnt prefixes so
it is possible and operationally manageable to implement a BCP38 filtering
policy, but does not say ‘you MUST implement BCP38’ (which I don’t think
is in scope for this document).

So, I think this isn’t more stringent - the really must be capable of providing
dynamic prefix filtering and you are still urged to turn the function on as 
Per BCP38]

> thus merit an informative reference)?

[if - draft-ietf-dhc-dhcpv6-yang does have state data for prefix delegation
Information, but you could also potentially access this via CLI, web interface, SNMP, TR-69 etc.,
So I don’t think that the yang module needs a special mention.]

> the needed RFC 8213 reference...

[if - We can use the following wording, as the security considerations for 
RFC8213 are also applicable:

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

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

[If - Now I reread this, I don’t think the second sentence is needed at all:

  "[RFC8213] describes a method for securing traffic between the relay
  agent and server by sending DHCP messages over an IPsec tunnel. 
  It is RECOMMENDED that this is implemented by the
  delegating relay."

> 4443 would be more properly classified as a normative reference.

[if - Done]

> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg