Subject: [Dots] requirements clarifications needed

From: Andrew Mortensen <[email-masked]>
Date: Sun, 20 Mar 2016 10:44:51 -0400

Hi all. As we wrap up the next draft revision, the requirements editors are seeking clarification on a some previously received feedback and a handful of suggested requirements.

1. The role of the relay was brought up following the use cases draft presentation at the last meeting [1], to which the response was:

	A relay is used for aggregating requests/responses, implementing a filtering policy, or as a proxy between stateful and stateless transport.

 Signal aggregation and proxying are certainly requirements of the relay, but we’re looking for clarification of what “implementing a filtering policy” means in this context.

2. The extent to which provisioning is in scope for DOTS. At the last meeting, there was a suggestion that “some policy provisioning or registration belongs to I2NSF” [2].

3. Whether reduced fate sharing warrants a requirement, as raised in [3].

4. Whether a DOTS server SHOULD be able to redirect a DOTS client to another DOTS server [4].

Thank you!

andrew (on behalf of requirements editors)

--

[1] 2a in <https://datatracker.ietf.org/doc/minutes-94-dots/>

[2] 2b in <https://datatracker.ietf.org/doc/minutes-94-dots/>

[3] <https://tools.ietf.org/html/draft-moskowitz-dots-gre-00#section-3.3.2> and <https://tools.ietf.org/html/draft-moskowitz-dots-gre-00#section-4>

[4] Med18 in  <http://mailarchive.ietf.org/arch/msg/dots/I7zqwcat6KdVES28Z7Pka5y8YDc <https://mailarchive.ietf.org/arch/msg/dots/I7zqwcat6KdVES28Z7Pka5y8YDc>>.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 21 Mar 2016 23:40:34 +0700

On 20 Mar 2016, at 21:44, Andrew Mortensen wrote:

>  Signal aggregation and proxying are certainly requirements of the 
> relay, but we’re looking for clarification of what “implementing a 
> filtering policy” means in this context.

Both DOTS servers and relays ought to be able to filter DOTS requests 
based upon various operator-defined criteria, IMHO.  This could be as 
simple as refusing or ignoring registration requests from known abusive 
clients and as granular as disallowing certain message types.

> 2. The extent to which provisioning is in scope for DOTS. At the last 
> meeting, there was a suggestion that “some policy provisioning or 
> registration belongs to I2NSF” [2].

Provisioning itself is outside the scope of DOTS, IMHO (that's a huge 
area that I2NSF, I2RS, et. al. are working).

Registration of DOTS clients should be supported, IMHO.

The following is from draft-ietf-dots-use-cases-01:

-----

3.2.  Ancillary Use Cases

3.2.1.  Auto-registration of DOTS clients with DOTS servers

    An additional benefit of DOTS is that by utilizing agreed-upon
    authentication mechanisms, DOTS clients can automatically register
    for DDoS mitigation service with one or more upstream DOTS servers.
    The details of such registration are beyond the scope of this
    document.

3.2.2.  Auto-provisioning of DDoS countermeasures

    The largely manual tasks associated with provisioning effective,
    situationally-appropriate DDoS countermeasures is a significant
    barrier to providing/obtaining DDoS mitigation services for both
    mitigation providers and mitigation recipients.  Due to the 'self-
    descriptive' nature of DOTS registration messages and mitigation
    requests, the implementation and deployment of DOTS has the 
potential
    to automate countermeasure selection and configuration for DDoS
    mitigators.  The details of such provisioning are beyond the scope 
of
    this document.

-----

> 3. Whether reduced fate sharing warrants a requirement, as raised in 

Avoidance of fate-sharing should be an operational recommendation, and 
the protocol itself and messaging should lend themselves to such to the 
degree that it is practicable, IMHO.

> 4. Whether a DOTS server SHOULD be able to redirect a DOTS client to 

Yes, given proper bidirectional authentication, IMHO.

-----------------------------------
Roland Dobbins <[email-masked]>