Re: [Dots] AD review of draft-ietf-dots-requirements-15

[Benjamin Kaduk <[e-mail]>]

Excellent; thank you!

-Ben

On Wed, Oct 17, 2018 at 02:16:00PM +0000, Mortensen, Andrew wrote:
> Hi Ben. Thanks for this helpful feedback. I’ve been working on incorporating the changes, and should have an updated revision ready shortly.
> 
> andrew
> 
> 
> 
> > On Oct 8, 2018, at 10:56 AM, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > [EXTERNAL EMAIL]
> > 
> > Hi all,
> > 
> > Thanks for the fine document, and sorry for the processing delay -- the
> > timing interacted poorly with my travel schedule.
> > 
> > I just have some editorial notes that it would be nice to fix before we send
> > this out for broader review; I'll list them section-by-section.
> > 
> > Section 1.1
> > 
> >   A standardized method to coordinate a real-time response among
> >   involved operators will increase the speed and effectiveness of DDoS
> >   attack mitigation, and reduce the impact of these attacks.  This
> >   document describes the required characteristics of protocols that
> >   enable attack coordination and mitigation of DDoS attacks.
> > 
> > "protocols that enable attack coordination" can be read as if we are
> > generating DDoS attacks, which is probably not the intention.
> > 
> > Section 1.2
> > 
> > RFC 8174 has updated BCP 14 boilerplate; proactively changing to use it
> > will save lots of reviewers from pointing this out.
> > 
> >   Mitigator:  An entity, typically a network element, capable of
> >      performing mitigation of a detected or reported DDoS attack.  The
> >      means by which this entity performs these mitigations and how they
> >      are requested of it are out of scope.  The mitigator and DOTS
> >      server receiving a mitigation request are assumed to belong to the
> >      same administrative entity.
> > 
> > It may be best to avoid an unqualified "out of scope" and be clear about if
> > it's out of scope for this document, for the WG, etc.
> > 
> >   DOTS signal:  A concise authenticated status/control message
> >      transmitted over the signal channel between DOTS agents, used to
> >      indicate the client's need for mitigation, as well as to convey
> >      the status of any requested mitigation.
> > 
> > Is the message itself authenticated in addition to the authentication
> > provided by the signal channel?  It might be confusing to mention
> > authentication in both places if it's just the channel providing
> > authentication.
> > 
> > Also, I would suggest to s/as well as/or/, since (presumably) a single
> > message can do just one or the other.
> > 
> >   Data channel:  A bidirectional, mutually authentication communication
> >      channel between two DOTS agents used for infrequent but reliable
> >      bulk exchange of data not easily or appropriately communicated
> >      through the signal channel under attack conditions.
> > 
> > This definition left me wondering whether the data channel is supposed to
> > function during attack conditions (i.e., if the attack condition rendered
> > the signal channel unusable for this purpose, so the data channel was
> > created to still work under attack conditions).  The rest of the document
> > seems to clarify that the data channel is not expected to be useful during
> > attack conditions, so perhaps this could be clarified here.
> > 
> >   Blacklist:  A list of filters indicating sources from which traffic
> >      should be blocked, regardless of traffic content.
> > 
> >   Whitelist:  A list of filters indicating sources from which traffic
> >      should always be allowed, regardless of contradictory data gleaned
> >      in a detected attack.
> > 
> > I note without further comment that there was recently a long thread on
> > [e-mail] about potentially offensive terminology, which included both
> > of these words as examples.
> > 
> > Section 2
> > 
> >   The DOTS protocol must at a minimum make it possible for a DOTS
> >   client to request aid mounting a defense, coordinated by a DOTS
> >   server, against a suspected attack, signaling within or between
> >   domains as requested by local operators. [...]
> > 
> > This sentence has a lot of commas that breaks up the flow trying to read
> > it.  It could perhaps be split into two, as
> > 
> > % The DOTS protocol must at a minimum make it possible for a DOTS
> > % client to request aid mounting a defense against a suspected attack.
> > % This defense could be coordinated by a DOTS server and include signaling
> > % within or between domains as requested by local operators.
> > 
> >   [...]
> >   clients need to justify withdrawing help requests: the decision is
> >   local to the DOTS clients' domain.  Multi-homed DOTS clients must be
> >   able to select the appropriate DOTS server(s) to which a mitigation
> >   request is to be sent.  The method for selecting the appropriate DOTS
> >   server in a multi-homed environment is out of scope.
> > 
> > (same comment about "out of scope").
> > 
> >   DOTS protocol implementations face competing operational goals when
> >   maintaining this bidirectional communication stream.  On the one
> >   hand, DOTS must include protections ensuring message confidentiality,
> >   integrity and authenticity to keep the protocols from becoming
> >   additional vectors for the very attacks it is meant to help fight
> >   off.  [...]
> > 
> > It's probably worth including freshness/replay protection in this list.
> > 
> > Section 2.1
> > 
> >   GEN-001  Extensibility: Protocols and data models developed as part
> >      of DOTS MUST be extensible in order to keep DOTS adaptable to
> >      operational and proprietary DDoS defenses.  Future extensions MUST
> >      be backward compatible.  DOTS protocols MUST use a version number
> >      system to distinguish protocol revisions.  Implementations of
> >      older protocol versions SHOULD ignore information added to DOTS
> >      messages as part of newer protocol versions.
> > 
> > No change specifically needed, but I'll note that using a version number
> > mostly precludes using individual per-feature tags to indicate feature
> > support.  It's okay for a WG to be making such a design choice at this
> > point in the process; I'm just pointing out that it is something of a
> > design choice.
> > 
> >   GEN-002  Resilience and Robustness: The signaling protocol MUST be
> >      designed to maximize the probability of signal delivery even under
> >      the severely constrained network conditions caused by particular
> >      attack traffic.  [...]
> > 
> > The word choice "particular" makes it sound as if there is a specific
> > attack that the author has in mind, leaving the reader wondering what
> > attack that is.  It may be better to just remove the word entirely or give
> > some description of what attack type(s) are relevant.
> > 
> >   GEN-003  Bulk Data Exchange: Infrequent bulk data exchange between
> >      DOTS agents can also significantly augment attack response
> >      coordination, permitting such tasks as population of black- or
> >      white-listed source addresses; address or prefix group aliasing;
> >      exchange of incident reports; and other hinting or configuration
> >      supplementing attack response.
> > 
> >      As the resilience requirements for the DOTS signal channel mandate
> >      small signal message size, a separate, secure data channel
> >      utilizing a reliable transport protocol MUST be used for bulk data
> >      exchange.
> > 
> > (This could potentially also clarify if it's expected to be useful during
> > attack conditions.)
> > 
> >   GEN-004  Mitigation Hinting: DOTS clients may have access to attack
> >      details which can be used to inform mitigation techniques.
> >      Example attack details might include locally collected
> >      fingerprints for an on-going attack, or anticipated or active
> >      attack focal points based on other threat intelligence.  DOTS
> >      clients MAY send mitigation hints derived from attack details to
> >      DOTS servers, in the full understanding that the DOTS server MAY
> >      ignore mitigation hints.  Mitigation hints MAY be transmitted
> >      across either signal or data channel.  [...]
> > 
> > My colleagues on the IESG tend to ask questions when there are multiple
> > options permitted but no discussion of why one might prefer one option or
> > the other.  (That is, they prefer a single mandatory option for reasons of
> > protocol simplicity.)
> > 
> > Section 2.2
> > 
> >   SIG-002  Sub-MTU Message Size: To avoid message fragmentation and the
> >      consequently decreased probability of message delivery over a
> >      congested link, signaling protocol message size MUST be kept under
> >      signaling Path Maximum Transmission Unit (PMTU), including the
> >      byte overhead of any encapsulation, transport headers, and
> >      transport- or message-level security.
> >      DOTS agents SHOULD attempt to learn the PMTU through mechanisms
> >      such as Path MTU Discovery [RFC1191] or Packetization Layer Path
> >      MTU Discovery [RFC4821].  If the PMTU cannot be discovered, DOTS
> >      agents SHOULD assume a PMTU of 1280 bytes.  If IPv4 support on
> >      legacy or otherwise unusual networks is a consideration and PMTU
> > nit: "the PMTU"
> >      is unknown, DOTS implementations MAY rely on a PMTU of 576 bytes,
> >      as discussed in [RFC0791] and [RFC1122].
> > 
> >   SIG-003  Bidirectionality: To support peer health detection, to
> >      maintain an active signal channel, and increase the probability of
> > nit: "to increase"
> >      signal delivery during an attack, the signal channel MUST be
> >      bidirectional, with client and server transmitting signals to each
> >      other at regular intervals, regardless of any client request for
> >      mitigation.  Unidirectional messages MUST be supported within the
> >      bidirectional signal channel to allow for unsolicited message
> >      delivery, enabling asynchronous notifications between DOTS agents.
> > 
> > This sentence about unidirectional messages left me a bit confused on first
> > read, I think just because of the way it was phrased.  It's basically just
> > saying that the signal channel is not necessarily request/reply pairs, but
> > can include oneshot notification messages that don't get an
> > application-level reply (but could still get a transport-level ack), right?
> > I don't have any specific text suggestions here, and it's probably okay to
> > leave it as-is.  (I have no particular reason to think that other people
> > get confused in the same ways that I do, after all.)
> > 
> >   SIG-005  Channel Redirection: In order to increase DOTS operational
> >      flexibility and scalability, DOTS servers SHOULD be able to
> >      redirect DOTS clients to another DOTS server at any time.  DOTS
> >      clients MUST NOT assume the redirection target DOTS server shares
> >      security state with the redirecting DOTS server.  DOTS clients are
> >      free to attempt abbreviated security negotiation methods supported
> >      by the protocol, such as DTLS session resumption, but MUST be
> >      prepared to negotiate new security state with the redirection
> >      target DOTS server.
> > 
> > When redirection occurs, is it always within the same "authentication
> > domain"?  There are perhaps additional complications about authenticating
> > the two servers and the redirection action if they are managed by different
> > entities or the client will be using different credentials with them.
> > 
> >   SIG-006  Mitigation Requests and Status: Authorized DOTS clients MUST
> >   [...]
> >      The initial active-but-terminating period is implementation- and
> >      deployment- specific, but SHOULD be sufficiently long to absorb
> >      latency incurred by route propagation.  If the client requests
> >      mitigation again before the initial active-but-terminating period
> > 
> > Just to check my understanding: this new mitigation request serves only to
> > extend the current termination period, and so the client would have to make
> > yet another mitigation request after mitigation terminates?
> > 
> >      elapses, the DOTS server MAY exponentially increase the active-
> >      but-terminating period up to a maximum of 300 seconds (5 minutes).
> > 
> > "exponentially" requires specifying an exponent base -- is the period
> > doubling each request, increasing by a factor of 1.5, ...?
> > 
> >      After the active-but-terminating period elapses, the DOTS server
> >      MUST treat the mitigation as terminated, as the DOTS client is no
> >      longer responsible for the mitigation.
> > 
> > 
> >   SIG-008  Mitigation Scope: DOTS clients MUST indicate desired
> >      mitigation scope.  The scope type will vary depending on the
> >      resources requiring mitigation.  All DOTS agent implementations
> >      MUST support the following required scope types:
> > 
> >      *  IPv4 prefixes in CIDR notation [RFC4632]
> > 
> > I don't see why CIDR notation comes into play for the protocol itself; why
> > not just say "IPv4 prefixes" to match the "IPv6 prefixes" below?
> > 
> >      If there is additional information available narrowing the scope
> >      of any requested attack response, such as targeted port range,
> >      protocol, or service, DOTS clients SHOULD include that information
> >      in client mitigation requests.  DOTS clients MAY also include
> >      additional attack details.  DOTS servers MAY ignore such
> >      supplemental information when enabling countermeasures on the
> >      mitigator.
> > 
> > Is it implicit from this that the signal channel needs to provide some way
> > in which to convey this sort of structured data that makes the semantics
> > clear (as opposed to, say, implementation-defined)?
> > 
> > Section 2.3
> > 
> >   DATA-002  Data privacy and integrity: Transmissions over the data
> >      channel are likely to contain operationally or privacy-sensitive
> >      information or instructions from the remote DOTS agent.  Theft or
> >      modification of data channel transmissions could lead to
> >      information leaks or malicious transactions on behalf of the
> >      sending agent (see Section 4 below).  Consequently data sent over
> > 
> > It may be worth mentioning the risk of replay explicitly.
> > 
> >      the data channel MUST be encrypted and authenticated using current
> >      IETF best practices.  DOTS servers MUST enable means to prevent
> > 
> > Do we need to provide an extensible model or negotiation scheme for the
> > encryption/authentication algorithms, so that implementations can adapt as
> > best practices change?
> > 
> >      leaking operationally or privacy-sensitive data.  Although
> >      administrative entities participating in DOTS may detail what data
> >      may be revealed to third-party DOTS agents, such considerations
> >      are not in scope for this document.
> > 
> >   DATA-003  Resource Configuration: To help meet the general and signal
> >      channel requirements in Section 2.1 and Section 2.2, DOTS server
> >      implementations MUST provide an interface to configure resource
> >      identifiers, as described in SIG-007.  [...]
> > 
> > I think this is SIG-008, not SIG-007.
> > 
> > Section 2.4
> > 
> >   SEC-001  Peer Mutual Authentication: DOTS agents MUST authenticate
> >      each other before a DOTS signal or data channel is considered
> >      valid.  The method of authentication is not specified, but should
> >      follow current industry best practices with respect to any
> >      cryptographic mechanisms to authenticate the remote peer.
> > 
> > Authentication is great.  What model is used for making authorization
> > decisions?
> > 
> >   SEC-002  Message Confidentiality, Integrity and Authenticity: DOTS
> >   [...]
> >      In order for DOTS protocols to remain secure despite advancements
> >      in cryptanalysis and traffic analysis, DOTS agents MUST be able to
> >      negotiate the terms and mechanisms of protocol security, subject
> >      to the interoperability and signal message size requirements in
> >      Section 2.2.
> > 
> > I'd probably say "securely negotiate" just to avoid any questions.
> > 
> >   SEC-004  Authorization: DOTS servers MUST authorize all messages from
> >      DOTS clients which pertain to mitigation, configuration,
> >      filtering, or status.
> > 
> > Are there any message types left (that would not need authorization)?
> > 
> > Section 2.5
> > 
> >   DM-004  Mitigation Scope Representation: The data model MUST support
> >      representation of a requested mitigation's scope.  As mitigation
> >      scope may be represented in several different ways, per SIG-007
> >      above, the data model MUST be capable of flexible representation
> >      of mitigation scope.
> > 
> > Is "flexible" intended to encompass a generic extensibility to represent
> > new types of data and new semantics?
> > 
> >   DM-007  Acceptable Signal Loss Representation: The data model MUST be
> >      able to represent the DOTS agent's preference for acceptable
> >      signal loss when establishing a signal channel, as described in
> >      GEN-002.
> > 
> > Is this prefernce expressed as a threshold percentage of packet loss, a
> > timeout for keepalive messages, some other way, or we don't care?
> > 
> > Section 4
> > 
> >   Impersonation of either DOTS server or DOTS client could have
> > 
> > nit: "a DOTS server", "a DOTS client"
> > 
> >   Blocking communication between DOTS agents has the potential to
> >   disrupt the core function of DOTS, which is to request mitigation of
> >   active or expected DDoS attacks.  The DOTS signal channel is expected
> >   to operate over congested inbound links, and, as described in
> >   Section 2.2, the signal channel protocol must be designed for minimal
> >   data transfer to reduce the incidence of signal blocking.
> > 
> > "signal blocking" makes me think of an explicit firewall-like
> > functionality, whereas I think the threat here is more of an accidental
> > dropping of packets due to congestion and network elmeent overload.
> > 
> > 
> > 
> > Hopefully we can get a new rev out quickly and then I can request the IETF
> > Last Call!
> > 
> > Thanks to everyone for the good work that went into this document.
> > 
> > -Ben
> > 
>