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

["Eric Vyncke (evyncke)" <[e-mail]>]

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" <[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..."
    
    ---------------------------------------------------------------------------
    
    §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..."
                 ^             ^^^^^