Subject: [Dots] Does DOTS require sneaker-net support?

From: Dave Dolson <[email-masked]>
Date: Wed, 4 Nov 2015 02:31:25 +0000

With respect to the DOTS information that needs to be exchanged before an attack-the configuration, resource manifest, etc.,

-          Should sneaker-net (https://en.wikipedia.org/wiki/Sneakernet ) transport be supported? I.e., a file on a USB stick taken between sites.

-          Similarly, but not equivalently, should it be human readable such that it could be sent by fax?

-          Should it be QR-encodable so that it can be sent by JPEG (take a picture and send it to me)?

I'm asking because yesterday someone mentioned that occasionally operators need to set things up after an attack has begun.

Admittedly, I'm have a bit of fun with this :-)

But seriously, having the configuration described as a document format vs. as a protocol is worth considering.

-Dave

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 12:00:59 +0900

On 4 Nov 2015, at 11:31, Dave Dolson wrote:

> I'm asking because yesterday someone mentioned that occasionally 
> operators need to set things up after an attack has begun.

I believe this is actually worthy of consideration - it's an interesting 
'failsafe' approach.  We shouldn't spend a lot of time on it just yet, 
but should keep it in mind as we progress, IMHO.

DNS could also be potentially used for this sort of thing.

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

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 4 Nov 2015 14:23:47 +1100

it might be worth (for dave maybe at least) waling through a 'day in
the life' of this job:

scenario 1 - customer setup with mitigation service and dots equipment/etc.
  1) drink coffee
  2) customer detects attack (or you detect attack on customer)
  3) dots client fires off 'help me' message
  4) back to coffee

scenario 2 - customer as no dos-mitigation service/setup with you
  1) drink coffee
  2) customer calls your 'soc' (tech support) with issue
  3) issue is triaged to 'dos attack on customer'
  4) attack mitigation initiated for customer in some manner (perhaps
via dots client under your control, perhaps with other means, not
important)
  5) get sales-eqiuvalent-folks involved with customer to discuss
longer term strategy, ie: "Hey, we did this for free, it's costing us
bucks, how about we get a contract/etc done so you share some fo the
burden here (and consequently get quicker mitigation in the future)"
  6) back to coffee

(note that not all dos-mitigation-workers drink coffee)

I think there may be the need to agree up on the
credentials/endpoints/resources-under-protection/etc out of band.
There is certainly the scenario where this all happens 'on the line'
and via some automated means.

In the end, the conversation during a problem is:
  o short
  o to the point
  o not dependent upon 2 way communications (though certainly with
2-way more rich information could be expressed)
  o 'secure'

-chris

On Wed, Nov 4, 2015 at 2:00 PM, Roland Dobbins <[email-masked]> wrote:
>> I'm asking because yesterday someone mentioned that occasionally operators
>> need to set things up after an attack has begun.
>
>
> 'failsafe' approach.  We shouldn't spend a lot of time on it just yet, but
> should keep it in mind as we progress, IMHO.
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 12:32:16 +0900

> 2-way more rich information could be expressed)

Concur - this is the desired process for ad-hoc, out-of-band 
provisioning and mitigation service initiation.

If folks agree, maybe we can keep this on the back-burner until we're a 
bit further along.

---

From: Jelena Mirkovic <[email-masked]>
Date: Wed, 4 Nov 2015 11:33:38 -0800

I apologize first for not having read the current draft carefully. Feel
free to tell me to go read it if the issue I bring up is addressed there.
It seems to me that the critical issue is how requests are authenticated,
i.e., how does one prove that they have authority over a given IP space.

... leaving that aside for now ..

I see one part missing in this discussion about "network may be too
congested to get the message out". One doesn't have to use the network. We
all have cell phones, cell networks usually work separately from Internet.
One can just use an app on cell phone to contact their ISP.

=========================

Jelena Mirkovic
Research Faculty
USC Information Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
310-448-9170

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 5 Nov 2015 11:23:34 +1100

On Thu, Nov 5, 2015 at 6:33 AM, Jelena Mirkovic <[email-masked]> wrote:
> I apologize first for not having read the current draft carefully. Feel free
> to tell me to go read it if the issue I bring up is addressed there. It
> seems to me that the critical issue is how requests are authenticated, i.e.,
> how does one prove that they have authority over a given IP space.

that's a can of worms.. but MOSTLY the ISP customer sorts that out for
other reasons with their ISP. For 'not your ISP' solutions there are
already verification processes being used, we ought to just rely on
them.

unless you wanted to mandate RPKI adoption...

> One can just use an app on cell phone to contact their ISP.

this is in Roland's use-case slides/preso/draft I believe, actually.
depending on human intervention is probably the wrong answer long
term, but 'one option' is fine for people poking buttons. (I think)

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 05 Nov 2015 10:00:58 +0900

> One can just use an app on cell phone to contact their ISP.

Please see the use-cases draft and presentation.

---

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

Digging back for thread start messages and responding there...

On 11/03/2015 08:31 PM, Dave Dolson wrote:
>
> With respect to the DOTS information that needs to be exchanged before 
> an attack—the configuration, resource manifest, etc.,
>
> -Should sneaker-net (https://en.wikipedia.org/wiki/Sneakernet ) 
> transport be supported? I.e., a file on a USB stick taken between sites.
>
> -Similarly, but not equivalently, should it be human readable such 
> that it could be sent by fax?
>
> -Should it be QR-encodable so that it can be sent by JPEG (take a 
> picture and send it to me)?
>
> I’m asking because yesterday someone mentioned that occasionally 
> Admittedly, I’m have a bit of fun with this :-)
>

If a DOTS message can fit into a single MTU, it can fit in a QR code.  I 
can just see a firewall/router with a small screen showing a QR code.  
If it turns red, it means things have really gone down the tubes.  So 
you take your phone with your DOTS client app, read in the QR code 
content and send it off to your DOTS server.  YES! Attack mitigation on 
its way!  :)

There is a lot of room here for product differentiation.

---

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

From: Dots <[email-masked]<mailto:[email-masked]>> on behalf of Robert Moskowitz <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 11, 2015 at 5:56 AM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dots] Does DOTS require sneaker-net support?

Perhaps providing the config in some form of XML or JSON format would fit the bill here. This would provide for all sorts of useful things like putting it into a document, or even piping it into some SDN orchestrator to take action.

If a DOTS message can fit into a single MTU, it can fit in a QR code.  I can just see a firewall/router with a small screen showing a QR code.  If it turns red, it means things have really gone down the tubes.  So you take your phone with your DOTS client app, read in the QR code content and send it off to your DOTS server.  YES!  Attack mitigation on its way!  :)

I actually really like that idea. But I think that’s largely a vendor implementation, right?

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 18:39:55 -0600

On 11/10/2015 05:41 PM, Stefan Fouant wrote:
> From: Dots <[email-masked] <mailto:[email-masked]>> on 
> behalf of Robert Moskowitz <[email-masked] 
> <mailto:[email-masked]>>
> To: Dave Dolson <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>     But seriously, having the configuration described as a document
>     format vs. as a protocol is worth considering.
>
>
> Perhaps providing the config in some form of XML or JSON format would 
> fit the bill here. This would provide for all sorts of useful things 
> like putting it into a document, or even piping it into some SDN 
> orchestrator to take action.

I was talking to Paul Lambert (old-time IETFer security guy) earlier 
today and he has been using both Protobuf and YAML for some of his 
projects.  They both look a lot better than some general XML or JSON.  
Anyone here have experience with them?

>
>
>     If a DOTS message can fit into a single MTU, it can fit in a QR
>     code.  I can just see a firewall/router with a small screen
>     showing a QR code.  If it turns red, it means things have really
>     gone down the tubes.  So you take your phone with your DOTS client
>     app, read in the QR code content and send it off to your DOTS
>     server.  YES!  Attack mitigation on its way!  :)
>

My point exactly.  We do standards.  Vendors work out ways to make their 
implementation more marketable than the other guy's.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 12 Nov 2015 20:58:47 +0700

> vendor implementation, right?

It's a use-case we should cover, IMHO, as well as consider for 
implementation/operational guidance at the appropriate time.