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

[Tommy Pauly <[e-mail]>]

> On Jan 22, 2020, at 6:54 AM, Warren Kumari <[e-mail]> wrote:
> 
> On Wed, Jan 22, 2020 at 12:26 AM 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).
>> 
> 
> Doh!
> 
> Yes, unless we are missing something, this *does* sound like an issue
> -- I like your minimum upper bound idea... but I'm also picturing
> something where the victim sends back some bad PvD info which makes
> the clients fall off the network, thereby stopping the attack :-P

There should certainly be a minimum time between fetches, which we can specify here.

Beyond this, I think there's actually a relatively straightforward solution that's latent in the text but needs to be called out in the security considerations.

The privacy considerations note that the Additional Information server should limit access to valid clients (and if it checks the client public address, this can prevent the NAT66 trick):

Network operators SHOULD restrict access to PvD Additional
Information to only expose it to hosts that are connected to the local
network... [this] can be implemented by
whitelisting access from the addresses and prefixes that the router provides
for the PvD, which will match the prefixes contained in the PvD Additional
Information.

In addition, the client is told to "abandon" requests and consider that a PvD has no additional info if it receives HTTP 400 errors:

If the HTTP status of the answer is greater than or equal to 400
the host MUST abandon and consider that there is no additional PvD
information.

My thought is to specify that the server rejects clients with a 400-level if they are not indeed from its own PvD; and similarly to specify that clients don't retry and effectively blacklist the PvD Additional Info in this case, or if they don't get valid JSON back.

Thoughts?

Thanks!
Tommy

> 
>> Regardless of how this is ultimately handled, I think this is a pretty severe
>> risk that needs addressing in the document prior to publication.
> 
> Yah.
> W
> 
>> 
>> 
>> ----------------------------------------------------------------------
>> 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..."
>> 
>> ---------------------------------------------------------------------------
>> 
>> §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.
>> 
>> ---------------------------------------------------------------------------
>> 
>> §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..."
>> 
>> ---------------------------------------------------------------------------
>> 
>> §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.
>> 
>> ---------------------------------------------------------------------------
>> 
>> §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.
>> 
>> ---------------------------------------------------------------------------
>> 
>> §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.
>> 
>> ---------------------------------------------------------------------------
>> 
>> §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..."
>>             ^             ^^^^^
>> 
>> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf