Hello Adam,
Replying with my co-author's hat.
First thank you for the review and the catch (I feel a little ashamed of not
spotting it before!).
As noted by you and Tommy, sections 4.4 and 7 actually protect the real PvD
additional information server based on the source IP address of the PvD-aware
hosts but not 'normal web servers'.
In section 4.1, there is this text:
" 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."
This text could be augmented to at least state 'not to be retried' for the
same PvD sequence number. But, of course, the rogue RA[1] could rotate the
sequence numbers... hence Tommy's proposal of rate limiting the outbound HTTPS
connections is probably the best mitigation technique.
As Tommy wrote, adding a DNS TXT for an easy & quick check whether the PvD ID
has actually a 'valid' additional information server is valid but add more work
to do on the PvD hosts (that could be very lightweight). Even with this added
complexity drawback, it sounds doable.
Good suggestion as well on the delay computation
Regards
-éric
[1] OTOH, I sincerely hope that networks are deployed nowadays with a feature
such as RA-guard so that RA messages can reasonably be trusted esp in large
networks.
On 22/01/2020, 06:26, "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..."
---------------------------------------------------------------------------
§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..."
^ ^^^^^
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
