Re: [Int-area] Adam Roach's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

[Tommy Pauly <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area