Subject: [Dots] dots-threats-draft?

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 05 Nov 2015 19:41:36 +0900

Do we need a separate dots-threats draft to lay out potential threats to 
DOTS communications channels/nodes in detail, or will the security 
sections of the relevant drafts suffice?

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 5 Nov 2015 10:30:40 -0500

The security considerations should suffice.  The WG will just need to have the appropriate text co weed in the appropriate draft.

Thanks,
Kathleen 

Sent from my iPhone

> On Nov 5, 2015, at 5:41 AM, Roland Dobbins <[email-masked]> wrote:
> 
> 
> Do we need a separate dots-threats draft to lay out potential threats to DOTS communications channels/nodes in detail, or will the security sections of the relevant drafts suffice?
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 10 Nov 2015 14:33:41 -0600

I have finally caught up with all the messages on this list since our 
session.  In a set of messages I will try and share my own thoughts, 
though they cannot be tied too well to specific threads, as there is 
just too much traffic here to respond to...

On 11/05/2015 04:41 AM, Roland Dobbins wrote:
>
> Do we need a separate dots-threats draft to lay out potential threats 
> to DOTS communications channels/nodes in detail, or will the security 

I am VERY concerned about attacks against DOTS agents, particularly the 
servers.

Adversaries will find them and attack them when it is most advantageous.

So we need to be more specific on the attacks that can be waged on DOTS 
(we don't need to address all the attacks against a server or service, 
that is out of scope).

What can an adversary do to UDP?  Is there any specific UDP flooding 
attack that needs to be considered?  Or is this a reason to use 
something other than UDP?

What can an adversary do to DTLS?  There are attacks against the DTLS 
handshake; how can these be mitigated?  What about attacks using DTLS 
datagram flooding?  Is this a reasonable possiblity?  Or is there 
something better than DTLS that better deals with attacks? Should 
message authentication only be used, and not content confidentiality?  
Thus while a Server is under attack, it can still process messages from 
valid clients?  Is there a DTLS auth-only cipher (e.g. CMAC).  What 
about a low-processing cost auth-only 'cipher' based on a hash chain?

There probably are real attacks against the DOTS clients based on 
choices made here.  In the requirements document we can generalize 
dealing with these.  Specific proposals will need to detail how they 
mitigate their own risks.

---

From: Stefan Fouant <[email-masked]>
Date: Tue, 10 Nov 2015 20:40:55 +0000

>(we don't need to address all the attacks against a server or service,

I agree with your concerns and think we agreed in Yokohama to lay those
out in the relevant security sections in each draft. While not a panacea,
I think that including a reference to BCP 38 is paramount, and I would
hope any operator deploying such a service would be employing the use of
edge ACLs to ensure only valid customer IPs are allowed to transmit a DOTS
message.

Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP
Senior Security Engineer
Corero Network Security
Mobile: +1.703.625.6243

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 10 Nov 2015 15:06:17 -0600

> edge ACLs to ensure only valid customer IPs are allowed to transmit a DOTS

I can see all sorts of ways this fails due to interdomain DOTS messaging 
requirements.

But we will see as we get the proposals moving.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 11 Nov 2015 04:12:25 +0700

On 11 Nov 2015, at 4:06, Robert Moskowitz wrote:

> I can see all sorts of ways this fails due to interdomain DOTS 
> messaging requirements.

DOTS peering relationships aren't ad-hoc - they do require minimal 
setup.

Which means that iACLs can and should be updated accordingly.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 11 Nov 2015 04:14:49 +0700

On 11 Nov 2015, at 3:33, Robert Moskowitz wrote:

> I am VERY concerned about attacks against DOTS agents, particularly 
> the servers.

Many of the same BCPs which apply to network infrastructure and to 
servers/services should be used to secure DOTS agents.

We must be sure to capture all the relevant ones and provide 
implementation and deployment guidance.

And then there are the application-layer-specific things we must take 
into account.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 10 Nov 2015 15:15:50 -0600

On 11/10/2015 03:12 PM, Roland Dobbins wrote:
> DOTS peering relationships aren't ad-hoc - they do require minimal setup.
>

This leads to a DOTS operational best practices draft.

How to deploy to limit risks to DOTS itself.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 10 Nov 2015 16:58:51 -0600

> Which means that iACLs can and should be updated accordingly.

As I sit in the IEEE 802.15.12 LLC discussion...

Since a customer can set up a mitigation contract with some DDoS 
mitigation provider well outside their IP service provider, DOTS 
datagrams can be traversing a provider network without any prior 
agreement with said provider.

So perhaps you are talking about ACLs specific to a given DOTS agent.

But I will have to see some of these things in practice to better align 
my thoughts with your view.

---

From: Stefan Fouant <[email-masked]>
Date: Tue, 10 Nov 2015 23:33:18 +0000

>So perhaps you are talking about ACLs specific to a given DOTS agent.

Yes precisely. IMO, similar precautions that we take to protect a BGP
speaker or a DNS server can be taken - that is utilizing edge ACLs to only
allow inbound to your infrastructure that which you want to allow,
effectively protecting your DOTS server infrastructure. Of course, this is
only one aspect of what should be a multi-layered approach. BCP 38 to
prevent to filter the cruft. Authentication schemes to prevent spoofed
clients. Security through obscurity, etc., etc.

Stefan Fouant

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 12 Nov 2015 21:08:39 +0700

> How to deploy to limit risks to DOTS itself.

Concur.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 12 Nov 2015 21:09:37 +0700

> So perhaps you are talking about ACLs specific to a given DOTS agent.

Correct - hence iACLs.