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

["Ms. Li HUANG" <[e-mail]>]

09:48.hk S8 Jan 06 2021



Good Day,


DUID as manufacture unique is no longer for sure :

        -    PC machines can be copied in Dhcpv6DUID

        -     Switch, Router can be copied mac on the same model brands ?

        -      Mobile new S10 instance, has function the hidden secure the
mac today.



Sincerely
Li HUANG

On Thu, Dec 17, 2020, 20:26 <[e-mail]> wrote:

> 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
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>