Subject: [Dots] DOTS Description

From: "Roman D. Danyliw" <[email-masked]>
Date: Sat, 21 Mar 2015 20:29:12 +0000

Hello!

>From the BOF summary page [1], the DOTS description is as follows:

"There is a need for a standards based approach for on-premise DDoS mitigation devices to communicate threat and telemetry data to service provider based solutions. On-premise DDoS mitigation devices are sophisticated entities which may already identify, profile and mitigate a wide range of attacks. Although flow export, syslog and SNMP are currently used by service providers to identify anomalies, there is no agreed standard allowing for any device to signal to any other device or service provider what the anomaly is and the subsequent threat telemetry data. 

DDoS open threat signaling (DOTS) would enable any on-premise DDoS mitigation device to effectively communicate the current threat landscape, load and response data to a mitigation service provider. The upstream solution would then have a clear view of the threat should the on-premise solution be required to offramp attack traffic to a more capable handler. A vendor agnostic approach would allow any combination of vendor, service provider or community driven efforts to interoperate. DOTS would be extensible and may, in future, be expanded as a method of real time information exchange between other security devices and, potentially across organizations.

Verisign and Juniper have supported this work on standardized DOTS, and this work has resulted in an input specification for this proposed non-working group forming BOF."

Roman

[1] http://tools.ietf.org/bof/trac/

---

From: Eric Burger <[email-masked]>
Date: Sat, 21 Mar 2015 16:39:51 -0400

Conceptually, why not IODEF? Do we need something lighter weight coming from devices instead of CERTs, or is there more?

> On Mar 21, 2015, at 4:29 PM, Roman D. Danyliw <[email-masked]> wrote:
> 
> Hello!
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 22 Mar 2015 08:45:18 -0400

Do you mean ligher weight in terms of the protocol or the data modeling?

---

From: Eric Burger <[email-masked]>
Date: Sun, 22 Mar 2015 08:51:58 -0400

Either or both.

--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lemonade/>

> On Mar 22, 2015, at 8:45 AM, Robert Moskowitz <[email-masked]> wrote:
>

---

From: "Teague, Nik" <[email-masked]>
Date: Sun, 22 Mar 2015 13:41:39 +0000

Hi,

On 21/03/2015 15:39, "Eric Burger" <[email-masked]> wrote:

>Conceptually, why not IODEF? Do we need something lighter weight coming
>from devices instead of CERTs, or is there more?

A lighter protocol is desirable in order for DDoS mitigation CPE to
effectively communicate to an external upstream provider when resources
may be at a premium during a large volumetric attack.  These devices are
capable of dealing with many attacks but at some point the attack being
aimed at the protected resource may be simply too large to handle.  Links
will be congested and connectionless light weight signaling at this point
is probably the best way to send up a flare to the provider (and fitting
as much as you can into as few packets as possible).

Various aspects of IODEF that are analogous could be adopted but the XML
representation, in my mind, would add too much extraneous weight to the
signaling channel.  Eg. if templates are already exported via IPFIX then
its unnecessary for the data export to then reference redundant field
identifiers, it just needs to identify the matching template.

Thanks,

-Nik

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 22 Mar 2015 10:13:06 -0400

With no hat on...

> identifiers, it just needs to identify the matching template.

I think there are a few other considerations as well.  IPFIX may already be
implemented in devices and is about exchanging flow information.  IPFIX
data might be included in an IODEF message, but wouldn't have called out
explicit indicators or incident data.  IODEF is really designed for
telemetry data int he way that IPFIX is.  I think these can be
complementary and there are ways to create connections between the MILE
work and this proposal with IPFIX.

Thanks,
Kathleen

-- 

Best regards,
Kathleen