Hi Adam, As we discuss the main DDoS attack case, I did want to also reply to the other comments (see inline).
I'm keeping pending changes available here, to be published after the telechat: https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/25 <https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/25> Thanks! Tommy > On Jan 21, 2020, at 9:26 PM, Adam Roach via Datatracker <[email protected]> > wrote: > > Adam Roach has entered the following ballot position for > draft-ietf-intarea-provisioning-domains-10: Discuss > > 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-intarea-provisioning-domains/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks to the authors and working group for their work on this document. I > have one major concern about the ability for this mechanism to be abused to > form DDoS attacks, described below. Unfortunately, while I have identified the > attack, I don't have an easy solution to propose that mitigates it > satisfactorily. > > I also have a handful of mostly editorial comments on the document. > > --------------------------------------------------------------------------- > > §6: > > I was expecting to see a discussion of the DDoS attack that may result from a > large network (or a rogue host on such a network) sending out a PvD ID > containing the hostname of a victim machine, and setting the "H" flag. > > Since the messages used to trigger these HTTP connections are extremely > lightweight, unauthenticated UDP messages, and the resulting HTTP connections > require the exchange of a significant number of packets in addition to a > number of cryptographic operations, this is a very high ratio amplification > attack, both in terms of network and CPU resources. > > Given that the delay setting comes from the network instead of being > independently computed by the host, such an attack could be honed to be > particularly devastating. Although it isn't a complete mitigation, one > approach to consider would be moving computation of the delay upper bound to > the host, or specifying a minimum upper bound of several minutes (where a > smaller value will cause the host to use this minimum upper bound). > > Regardless of how this is ultimately handled, I think this is a pretty severe > risk that needs addressing in the document prior to publication. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > >> This document also introduces a mechanism for hosts to retrieve >> optional additional information related to a specific PvD by means of >> an HTTP over TLS query using an URI derived from the PvD ID. > > Nit: "...a URI..." Fixed! > > --------------------------------------------------------------------------- > > §3.4.1: > >> This is intended to >> resolve backward compatibility issues with rare deployments choosing >> to assign addresses with DHCPv6 while not sending any matching PIO. > > It seems that this set of circumstances could also arise due to a > misconfiguration of DHCPv6. If this is expected to be only rarely > intended, perhaps some oprationational/implementation guidance to log > a warning or otherwise alert the operator would be helpful. Added the following sentence at the end of the paragraph: Implementations are suggested to flag or log such scenarios as errors to help detect misconfigurations. > > --------------------------------------------------------------------------- > > §4.1: > >> HTTP requests and responses for PvD additional information use the >> "application/pvd+json" media type (see Section 8). Clients SHOULD >> include this media type as an Accept header in their GET requests, > > Nit: "...Accept header field..." Fixed > > --------------------------------------------------------------------------- > > §4.1: > >> If the HTTP >> status of the answer is between 200 and 299, inclusive, the host MAY >> get a file containing a single JSON object. > > This is very confusing phrasing. The sentence -- and the use of a normative > "MAY" in particular -- indicates that the host is given permission to take > some additional action that "gets" a JSON object from somewhere. I think it's > intending to say that a 200-class HTTP response will contain such an object. > > Consider rephrasing. This is similar to Alissa's comment. The new text is: If the HTTP status of the answer is between 200 and 299, inclusive, the response is expected to be a single JSON object. > > --------------------------------------------------------------------------- > > §4.3: > >> Private-use or experimental keys MAY be used in the JSON dictionary. >> In order to avoid such keys colliding with IANA registry keys, >> implementers or vendors defining private-use or experimental keys >> MUST create sub-dictionaries, where the sub-dictionary is added into >> the top-level JSON dictionary with a key of the format "vendor-*" >> where the "*" is replaced by the implementer's or vendor's >> identifier. For example, keys specific to the FooBar organization >> could use "vendor-foobar". Upon receiving such a sub-dictionary, >> host MUST ignore this sub-dictionary if it is unknown. When the >> vendor or implementer is part of an IANA URN namespace [URN], the URN >> namespace SHOULD be used rather than the "vendor-*" format. > > This is kind of a minor nit, but this paragraph is a bit confusing. It > starts off with a less-preferred convention ("vendor-*") and discusses > it as if it were the only way to do things; and then it throws in a > SHOULD-strength different encoding at the end as a surprise twist. > I would suggest reworking the paragraph so that the preferred encoding > (URNs) are mentioned first, as a SHOULD-strength statement, followed by > the less-preferred "vendor-*" as a fallback. This is also similar to Alissa's comment. I've updated the URN text, but also reordered the text. The paragraph now reads: Private-use or experimental keys MAY be used in the JSON dictionary. In order to avoid such keys colliding with IANA registry keys, implementers or vendors defining private-use or experimental keys MUST create sub-dictionaries. If a set of PvD Additional Information keys are defined by an organization that has a Formal URN Namespace {{URN}}, the URN namespace SHOULD be used as the top-level JSON key for the sub-dictionary. For other private uses, the sub-dictionary key SHOULD follow the format of "vendor-\*", where the "\*" is replaced by the implementer's or vendor's identifier. For example, keys specific to the FooBar organization could use "vendor-foobar". If a host receives a sub-dictionary with an unknown key, the host MUST ignore the contents of the sub-dictionary. > > --------------------------------------------------------------------------- > > §4.3: > >> +------------+-----------------+-----------+------------------------+ >> | JSON key | Description | Type | Example | >> +------------+-----------------+-----------+------------------------+ >> | identifier | PvD ID FQDN | String | "pvd.example.com." | > > ... > >> { >> "identifier": "cafe.example.com", >> "expires": "2017-07-23T06:00:00Z", >> "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], >> } > > I'm concerned about the variation in the identifier field alternately > containing and not containing the terminal dot of the FQDN. If the > intention that these are to be equivalent, it would probably head off > some implementation incompatibilities if the document were to say so > explicitly. I've updated the examples to all use a trailing dot. > > --------------------------------------------------------------------------- > > §7: > >> without leaking identity information, SHOULD make use of an IPv6 >> Privacy Address and SHOULD NOT include any privacy sensitive data, >> such as User Agent header or HTTP cookie, while performing the HTTP > > Nit: "...User-Agent header field..." > ^ ^^^^^ Fixed! > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
