Subject: [Dots] Opsdir last call review of draft-ietf-dots-requirements-16

From: Scott Bradner <[email-masked]>
Date: Sat, 24 Nov 2018 12:32:55 -0800

Reviewer: Scott Bradner
Review result: Has Nits

This is an OPS-DIR review of Distributed Denial of Service (DDoS) Open Threat
Signaling Requirements (draft-ietf-dots-requirements)

This document lists requirements for a protocol to used between providers of
DDOS mitigation services and users of such services, as such there can be no
direct operational issues with the document.  I also did not find any indirect
operational issues.

I think the document would benefit from the addition of a section before the
requirements section that specifically describes the setup assumed by the
document. The descriptions before there hint at a presumed setup but a new
section that clearly states the setup would be helpful. (the setup appears to
be one where all network traffic to and from a protected entity flows through a
DDoS mitigation service provider.  The provider includes one or more DOTS
servers.  The protected entity includes one or more DOTS clients that
communicate with the DOTS servers)

Requirement SIG-005 addresses channel redirection – maybe there needs to be a
way that clients can move to a new server on their own if they lose hearbeat
from the server they were using – that might include a way for a server to
provide a list of alternative servers to the clients

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 25 Nov 2018 14:33:34 -0600

Hi Scott,

> communicate with the DOTS servers)

Just to double-check: you think that the reference to
draft-ietf-dots-architecture is insufficient in this regard?

Thanks,

Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 26 Nov 2018 05:15:48 +0000

Hi Scott,

Thanks for the review, Please see inline 

> -----Original Message-----
> From: Scott Bradner <[email-masked]>
> Sent: Sunday, November 25, 2018 2:03 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Opsdir last call review of draft-ietf-dots-requirements-16
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> Reviewer: Scott Bradner
> Review result: Has Nits
> 
> section that clearly states the setup would be helpful. (the setup appears to be
> one where all network traffic to and from a protected entity flows through a

The requirements drafts refers to the DOTS architecture draft that discusses the architectural relationships, components and concepts used in a DOTS deployment.

> 
> Requirement SIG-005 addresses channel redirection – maybe there needs to be
> a way that clients can move to a new server on their own if they lose hearbeat

We can update SIG-004 requirement to say the following:

The DOTS client may be provided with a list of DOTS servers.  If the DOTS client considers the signal channel is defunct due to the extended absence of 
DOTS server heartbeat, the DOTS client can establish  a new DOTS signal channel with the other DOTS servers in the list.

-Tiru

---

From: <[email-masked]>
Date: Mon, 26 Nov 2018 07:31:50 +0000

Hi Tiru, all,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
> Reddy
> Envoyé : lundi 26 novembre 2018 06:16
> À : Scott Bradner; [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked]
> Objet : Re: [Dots] Opsdir last call review of draft-ietf-dots-requirements-16
> 
> Hi Scott,
> 
> The requirements drafts refers to the DOTS architecture draft that discusses
> the architectural relationships, components and concepts used in a DOTS
> deployment.
> 
> >
> The DOTS client may be provided with a list of DOTS servers.

[Med] IMHO given that the requirements I-D points to the architecture I-D, we don't need to be redundant:

   The DOTS client may be provided with a list of DOTS servers, each
   associated with one or more IP addresses.  These addresses may or may
   not be of the same address family.  The DOTS client establishes one
   or more sessions by connecting to the provided DOTS server addresses.

But, of course it is not harmful to restate it if it helps the reader.

  If the DOTS
> client considers the signal channel is defunct due to the extended absence of
> DOTS server heartbeat, the DOTS client can establish  a new DOTS signal
> channel with the other DOTS servers in the list.
> 

[Med] Some comments here:
* I would not mix server selection/server migration with server redirection. That is, the proposed text is to be placed somewhere else in the I-D, not under SIG-004.
* I would not describe the behavior (e.g., if xxx, establish a new session) in the Requirements I-D, but focus on the expected functionality if we really need to say something. 
* A DOTS client provisioned with multiple dots server may already have other sessions established. How those sessions are established is policy-based. 
* Establishing a new session should be carefully considered to avoid, e.g., leaking information among servers not belonging to the same domain or oscillate between servers.
 
We can include a generic text such as the following:

  "Additional means to enhance the resilience of DOTS protocols, including when multiple DOTS servers are provisioned to the DOTS clients, SHOULD be considered." 

> -Tiru
> 
> >
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 26 Nov 2018 10:11:42 +0000

> From: [email-masked] <[email-masked]>
> Sent: Monday, November 26, 2018 1:02 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Scott Bradner <[email-masked]>; [email-masked]
> Subject: RE: Opsdir last call review of draft-ietf-dots-requirements-16
> 
> > De : Dots [mailto:[email-masked]] De la part de Konda,
> > Tirumaleswar Reddy Envoyé : lundi 26 novembre 2018 06:16 À : Scott
> > Bradner; [email-masked] Cc :
> > [email-masked]; [email-masked];
> > [email-masked] Objet : Re: [Dots] Opsdir last call review of
> > draft-ietf-dots-requirements-16
> >
> > Hi Scott,
> >
> > > This email originated from outside of the organization. Do not click
> > > links
> > or
> > > open attachments unless you recognize the sender and know the
> > > content is
> > safe.
> > >
> > > Reviewer: Scott Bradner
> > > Review result: Has Nits
> > >
> > > This is an OPS-DIR review of Distributed Denial of Service (DDoS)
> > > Open
> > Threat
> > > This document lists requirements for a protocol to used between
> > > providers
> > of
> > > DDOS mitigation services and users of such services, as such there
> > > can be
> > no
> > > direct operational issues with the document.  I also did not find
> > > any
> > indirect
> > > operational issues.
> > >
> > > I think the document would benefit from the addition of a section
> > > before
> > the
> > > requirements section that specifically describes the setup assumed
> > > by the document. The descriptions before there hint at a presumed
> > > setup but a new section that clearly states the setup would be
> > > helpful. (the setup appears
> > to be
> > > one where all network traffic to and from a protected entity flows
> > > through
> > a
> > > DDoS mitigation service provider.  The provider includes one or more
> > > DOTS servers.  The protected entity includes one or more DOTS
> > > clients that communicate with the DOTS servers)
> >
> > The requirements drafts refers to the DOTS architecture draft that
> > discusses the architectural relationships, components and concepts
> > used in a DOTS deployment.
> >
> > >
> > > Requirement SIG-005 addresses channel redirection – maybe there
> > > needs to be a way that clients can move to a new server on their own
> > > if they lose
> > hearbeat
> > > from the server they were using – that might include a way for a
> > > server to provide a list of alternative servers to the clients
> >
> > client considers the signal channel is defunct due to the extended
> > absence of DOTS server heartbeat, the DOTS client can establish  a new
> > DOTS signal channel with the other DOTS servers in the list.
> >
> 
> * I would not mix server selection/server migration with server redirection.
> That is, the proposed text is to be placed somewhere else in the I-D, not under
> SIG-004.
> * I would not describe the behavior (e.g., if xxx, establish a new session) in the
> Requirements I-D, but focus on the expected functionality if we really need to
> say something.
> * A DOTS client provisioned with multiple dots server may already have other
> sessions established. How those sessions are established is policy-based.
> * Establishing a new session should be carefully considered to avoid, e.g.,
> leaking information among servers not belonging to the same domain or
> oscillate between servers.
> 
>   "Additional means to enhance the resilience of DOTS protocols, including
> when multiple DOTS servers are provisioned to the DOTS clients, SHOULD be
> considered."

Works for me.

-Tiru

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 26 Nov 2018 07:07:02 -0500

and for me

Scott

> On Nov 26, 2018, at 5:11 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
>