Subject: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

From: [email-masked]
Date: Tue, 23 Jan 2018 14:26:55 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.

        Title           : Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
        Authors         : Andrew Mortensen
                          Robert Moskowitz
                          Tirumaleswar Reddy
	Filename        : draft-ietf-dots-requirements-11.txt
	Pages           : 20
	Date            : 2018-01-23

Abstract:
   This document defines the requirements for the Distributed Denial of
   Service (DDoS) Open Threat Signaling (DOTS) protocols enabling
   coordinated response to DDoS attacks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dots-requirements-11
https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Tue, 23 Jan 2018 22:29:32 +0000

This revision incorporates all WGLC feedback, including an expanded security considerations section.

andrew

> On Jan 23, 2018, at 5:26 PM, [email-masked] wrote:
> 
>

---

From: <[email-masked]>
Date: Wed, 24 Jan 2018 08:57:13 +0000

Hi Andrew, 

Thank you for this updated version. 

Looks good to me. 

Some very minor comments below, FWIW: 

* I don't parse this one: 

  The DOTS server and client must also have some standardized method of
  defining the scope of any mitigation, and negotiating related
  mitigation communication and actions and communications.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* s/for a negotiated time interval or lifetime/for a negotiated time interval
* s/SIG-010:  Network Address Translator Traversal:/ SIG-010 Network Address Translator Traversal:
* s/"DM-001:  Structure:"/"DM-001  Structure:"
* Same change as above for DM-002-DM-009
* s/channel requirements in Section 2.1 and Section 2.2/channel requirements in Sections 2.1 and 2.2
* I don't parse this one "Blocking communication between DOTS agents-signal blocking-has the..."
* Add an "IANA Considerations" which basically says: "This document does not require any IANA action.". 
* Remove RFC5405 from the references 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Mortensen, Andrew
> Envoyé : mardi 23 janvier 2018 23:30
> À : dots
> Objet : Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 24 Jan 2018 12:22:52 -0000

Hi Andrew,

There are 2 pending resolution issues raised about the signal / data
channels which may need to be included in the requirements draft.  I was
planning on raising the 2 pending resolutions at the upcoming Virtual
Meeting.

1) Signal/Data path loop detection protection.

There is some proposed text by Med about loop detection by the use of a
hop-limit parameter.  Do we need tis?
https://mailarchive.ietf.org/arch/msg/dots/63MfwLTldONbO9gO_sdT6FG2DxQ 

2) Signal Channel support for Filter usage

Should a signal channel mitigation request be able to specify which Filters
to use as set up by the Data channel?
https://mailarchive.ietf.org/arch/msg/dots/kuINxI8XrcIgL1IuxjI-mvo2U1E 

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 24 January 2018 08:57
To: Mortensen, Andrew; dots
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

Hi Andrew, 

Looks good to me. 

* s/for a negotiated time interval or lifetime/for a negotiated time
interval
* s/SIG-010:  Network Address Translator Traversal:/ SIG-010 Network Address
Translator Traversal:
* s/"DM-001:  Structure:"/"DM-001  Structure:"
* Same change as above for DM-002-DM-009
* s/channel requirements in Section 2.1 and Section 2.2/channel requirements
in Sections 2.1 and 2.2
* I don't parse this one "Blocking communication between DOTS agents-signal
blocking-has the..."
* Add an "IANA Considerations" which basically says: "This document does not
require any IANA action.". 
* Remove RFC5405 from the references 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Mortensen, 
> Andrew Envoyé : mardi 23 janvier 2018 23:30 À : dots Objet : Re: 
> [Dots] I-D Action: draft-ietf-dots-requirements-11.txt
> 
> > This draft is a work item of the DDoS Open Threat Signaling WG of 
> > the
> IETF.
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Jan 2018 13:26:16 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Wednesday, January 24, 2018 5:53 PM
> To: Mortensen, Andrew <[email-masked]>; [email-masked]
> There are 2 pending resolution issues raised about the signal / data channels
> which may need to be included in the requirements draft.  I was planning on
> raising the 2 pending resolutions at the upcoming Virtual Meeting.
> 

I don't see an agreement on this one, please see my last response https://mailarchive.ietf.org/arch/msg/dots/p3TaRiNkZOrZ5PKr3UIXe10g9CU

-Tiru

> Should a signal channel mitigation request be able to specify which Filters to
> use as set up by the Data channel?

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Jan 2018 14:02:31 +0000

Comments on the security considerations section

1)

   Traffic injection into a naive DOTS deployment could allow an
   attacker to affect DOTS operations selectively.  Rather than
   impersonating a DOTS agent directly, the attacker crafts DOTS signal
   or data channel messages in such a way that the targeted DOTS agent
   treats them as if they originated with a legitimate DOTS agent, for
   example, by spoofing the sender's IP address.  

Comment>  Sender IP address is not used by the DOTS server to authenticate the DOTS client and vice-versa. The only way an attacker can impersonate the DOTS agent is by stealing its credentials or compromising the agent.

2)
   As with agent impersonation, the attacker capable of injecting traffic can affect
   the network path to addresses for which the DOTS client is authorized
   to request mitigation.

Comment> I did not get the above line. 

3)
   As detailed in Section 2.4, DOTS implementations require mutual
   authentication of DOTS agents in order to make agent impersonation
   and traffic injection more difficult.  However, impersonation or
   traffic injection may still be possible as a result of credential
   theft, implementation flaws, or compromise of DOTS agents.  Operators
   should take steps to reduce attack surfaces through current secure
   network communications best practices.

Comment> Current best secure network communications will not defend from credential theft or compromise of DOTS agents. DOTS agents need auditing, analytics tools etc. 
to detect a compromised peer DOTS agent.

-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of Mortensen,
> Andrew
> Sent: Wednesday, January 24, 2018 4:00 AM
> To: dots <[email-masked]>

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Wed, 24 Jan 2018 20:37:12 +0000

Thanks, Tiru. Comments inline.

> On Jan 24, 2018, at 9:02 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> … snip ...

I agree with you. It seemed like a stretch in the previous revision of the security considerations. Are there objections to dropping traffic injection per se as a security consideration? It seems reasonable to subsume it into a discussion of agent impersonation.

> Comment> I did not get the above line.

I had meant an attacker capable of injecting messages could toggle mitigation arbitrarily, potentially swinging traffic to or away from scrubbing centers, or otherwise influencing traffic to the DOTS client’s domain. Would go away if we drop traffic injection as a consideration.

> … snip ...

Agreed, will update.

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 25 Jan 2018 05:48:34 +0000

> Sent: Thursday, January 25, 2018 2:07 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: dots <[email-masked]>
> > On Jan 24, 2018, at 9:02 AM, Konda, Tirumaleswar Reddy
> <[email-masked]> wrote:
> >
> > … snip ...
> > Comment>  Sender IP address is not used by the DOTS server to
> authenticate the DOTS client and vice-versa. The only way an attacker can
> impersonate the DOTS agent is by stealing its credentials or compromising
> the agent.
> 
> I agree with you. It seemed like a stretch in the previous revision of the
> security considerations. Are there objections to dropping traffic injection per
> se as a security consideration? 

No objection from my side. 

Cheers,
-Tiru

> It seems reasonable to subsume it into a
> discussion of agent impersonation.
> 
> 
> >
> > 2)
> I had meant an attacker capable of injecting messages could toggle mitigation
> arbitrarily, potentially swinging traffic to or away from scrubbing centers, or
> otherwise influencing traffic to the DOTS client’s domain. Would go away if
> we drop traffic injection as a consideration.
> 
> 
> > … snip ...
> > Comment> Current best secure network communications will not defend
> from credential theft or compromise of DOTS agents. DOTS agents need
> auditing, analytics tools etc.

---

From: <[email-masked]>
Date: Thu, 25 Jan 2018 09:19:01 +0000

Hi Andrew, Tiru, 

That text is about a "naive DOTS deployment", whatever that means. It has the merit to identify a valid attack vector in a "naïve" deployment. 

I would maintain that text, but update it to indicate that if the requirements in Section 2.4 are honored, then implementing this attack requires stealing security credentials. 

Cheers,
Med

> Envoyé : mercredi 24 janvier 2018 21:37
> À : Konda, Tirumaleswar Reddy
> Cc : dots
> > Comment>  Sender IP address is not used by the DOTS server to authenticate
> the DOTS client and vice-versa. The only way an attacker can impersonate the
> DOTS agent is by stealing its credentials or compromising the agent.
> 
> security considerations. Are there objections to dropping traffic injection
> per se as a security consideration? It seems reasonable to subsume it into a
> arbitrarily, potentially swinging traffic to or away from scrubbing centers,
> or otherwise influencing traffic to the DOTS client’s domain. Would go away
> if we drop traffic injection as a consideration.
> 
> 
> > … snip ...
> > Comment> Current best secure network communications will not defend from
> credential theft or compromise of DOTS agents. DOTS agents need auditing,
> analytics tools etc.

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 29 Jan 2018 21:51:38 +0000

Hi Tiru, Jon and Andrew!

> From: Dots [mailto:[email-masked]] On Behalf Of Konda,
> Tirumaleswar Reddy
> Sent: Wednesday, January 24, 2018 8:26 AM
> To: Jon Shallow <[email-masked]>; Mortensen, Andrew
> <[email-masked]>; [email-masked]
> > channels which may need to be included in the requirements draft.  I
> > was planning on raising the 2 pending resolutions at the upcoming Virtual
> Meeting.
> >
> > There is some proposed text by Med about loop detection by the use of
> > a hop-limit parameter.  Do we need tis?
> >
> I don't see an agreement on this one, please see my last response
> https://mailarchive.ietf.org/arch/msg/dots/p3TaRiNkZOrZ5PKr3UIXe10g9CU

I see the lack of consensus on how to handle loops.  Does this issue need to be resolved with text in the requirements draft?  Could a simple requirement acknowledging the possibility of the problem be made (e.g., such as "the signal/data protocols needs to deal with communication loops ...") and the rest be worked out in the protocol drafts?

Roman

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 30 Jan 2018 12:11:26 -0000

Hi Roman,

"I see the lack of consensus on how to handle loops.  Does this issue need
to be resolved with text in the requirements draft?  Could a simple
requirement acknowledging the possibility of the problem be made (e.g., such
as "the signal/data protocols needs to deal with communication loops ...")
and the rest be worked out in the protocol drafts?"

I do not believe that how to do this needs to be spelt out in the
requirements draft.  Your suggested text works for me and is a good starting
point for possibly adding at the end of "GEN-002 Resilience and Robustness",
even though that section is primarily for signalling.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Roman Danyliw
Sent: 29 January 2018 21:52
To: Konda, Tirumaleswar Reddy; Jon Shallow; Mortensen, Andrew; [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

Hi Tiru, Jon and Andrew!

> > There is some proposed text by Med about loop detection by the use 
> > of a hop-limit parameter.  Do we need tis?
> >

I see the lack of consensus on how to handle loops.  Does this issue need to
be resolved with text in the requirements draft?  Could a simple requirement
acknowledging the possibility of the problem be made (e.g., such as "the
signal/data protocols needs to deal with communication loops ...") and the
rest be worked out in the protocol drafts?

Roman

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Tue, 30 Jan 2018 17:31:37 +0000

On Jan 30, 2018, at 7:11 AM, Jon Shallow <[email-masked]<mailto:[email-masked]>> wrote:

… snip ...

the signal/data protocols needs to deal with communication loops ...")
and the rest be worked out in the protocol drafts?"

I do not believe that how to do this needs to be spelt out in the
requirements draft.  Your suggested text works for me and is a good starting
point for possibly adding at the end of "GEN-002 Resilience and Robustness”,

I can do this.

Now would be a great time to hear concerns about document structure. Are you suggesting the general requirements section should be…generally…subsumed into the signal and data channel reqs section?

andrew

-----Original Message-----
From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Roman Danyliw
Sent: 29 January 2018 21:52
To: Konda, Tirumaleswar Reddy; Jon Shallow; Mortensen, Andrew; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

Hi Tiru, Jon and Andrew!

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Konda,
Tirumaleswar Reddy
Sent: Wednesday, January 24, 2018 8:26 AM
To: Jon Shallow <[email-masked]<mailto:[email-masked]>>; Mortensen, Andrew
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Wednesday, January 24, 2018 5:53 PM
To: Mortensen, Andrew <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

Hi Andrew,

There are 2 pending resolution issues raised about the signal / data
channels which may need to be included in the requirements draft.  I
was planning on raising the 2 pending resolutions at the upcoming
Virtual
Meeting.

https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dots_63MfwLTldONbO9gO-5FsdT6FG2D&d=DwICAg&c=Hlvprqonr5LuCN9TN65xNw&r=M-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=DPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=ZC5VY65R5uAJSAi6IbJ78-GqasHh4WvWeFAof_Tps2Q&e=
xQ

I don't see an agreement on this one, please see my last response
https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dots_p3TaRiNkZOrZ5PKr3UIXe10g9CU&d=DwICAg&c=Hlvprqonr5LuCN9TN65xNw&r=M-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=DPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=Usz0VuMvU_CVPqiGhuN_JWqIKZ9JR0MGa_axVLog2dg&e=

Roman

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dots&d=DwICAg&c=Hlvprqonr5LuCN9TN65xNw&r=M-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=DPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=h_F-yXEyPVcszMFW7_YGdd4orC58f-M_x29F_oHl9hM&e=

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 30 Jan 2018 19:28:17 -0000

Hi Andrew,

Apologies – I did not make myself clear – I was referring to the GEN-002 section in my comment, not the whole of the General Requirements Section.

I do think that there should be a ‘General Requirements’ that cover both signal and data that does not fit under Data Model Requirements or Security Requirements.

That said, GEN-003 could be moved to under SIG- as Bidirectionality  is signal specific.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Mortensen, Andrew
Sent: 30 January 2018 17:32
To: Jon Shallow
Cc: Roman Danyliw; Konda, Tirumaleswar Reddy; [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

On Jan 30, 2018, at 7:11 AM, Jon Shallow <[email-masked]> wrote:

… snip ...

I can do this.

andrew

-----Original Message-----
From: Dots [mailto:  <mailto:[email-masked]> [email-masked]] On Behalf Of Roman Danyliw
Sent: 29 January 2018 21:52
To: Konda, Tirumaleswar Reddy; Jon Shallow; Mortensen, Andrew;  <mailto:[email-masked]> [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

Hi Tiru, Jon and Andrew!

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Wednesday, January 24, 2018 5:53 PM
To: Mortensen, Andrew <[email-masked]>; [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

Hi Andrew,

Meeting.

https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dots_63MfwLTldONbO9gO-5FsdT6FG2D <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dots_63MfwLTldONbO9gO-5FsdT6FG2D&d=DwICAg&c=Hlvprqonr5LuCN9TN65xNw&r=M-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=DPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=ZC5VY65R5uAJSAi6IbJ78-GqasHh4WvWeFAof_Tps2Q&e=> &d=DwICAg&c=Hlvprqonr5LuCN9TN65xNw&r=M-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=DPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=ZC5VY65R5uAJSAi6IbJ78-GqasHh4WvWeFAof_Tps2Q&e=

xQ

I don't see an agreement on this one, please see my last response 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dots_p3TaRiNkZOrZ5PKr3UIXe10g9CU <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dots_p3TaRiNkZOrZ5PKr3UIXe10g9CU&d=DwICAg&c=Hlvprqonr5LuCN9TN65xNw&r=M-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=DPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=Usz0VuMvU_CVPqiGhuN_JWqIKZ9JR0MGa_axVLog2dg&e=> &d=DwICAg&c=Hlvprqonr5LuCN9TN65xNw&r=M-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=DPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=Usz0VuMvU_CVPqiGhuN_JWqIKZ9JR0MGa_axVLog2dg&e=

Roman

_______________________________________________
Dots mailing list
 <mailto:[email-masked]> [email-masked]
 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dots&d=DwICAg&c=Hlvprqonr5LuCN9TN65xNw&r=M-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=DPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=h_F-yXEyPVcszMFW7_YGdd4orC58f-M_x29F_oHl9hM&e=> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dots&d=DwICAg&c=Hlvprqonr5LuCN9TN65xNw&r=M-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=DPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=h_F-yXEyPVcszMFW7_YGdd4orC58f-M_x29F_oHl9hM&e=