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

[[e-mail]]

Hi Benjamin,

Many thanks for your comments. Please see inline below.

Ian


> On 16. Dec 2020, at 22:49, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> 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.)

[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 …”
]

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

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

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

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

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

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

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

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

> 
> 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?)

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

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

[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]

> 
> 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)?

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

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

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

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

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

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

[if - Done]

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