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

[Benjamin Kaduk <[e-mail]>]

I had intended to cc the WG list on this; sorry I missed it at the time.
Andrew, do you expect to be able to prepare an update?

Thanks,

Ben

On Mon, Oct 08, 2018 at 09:56:01AM -0500, Benjamin Kaduk wrote:
> 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
>