Subject: [Dots] FW: New Version Notification for draft-teague-open-threat-signaling-01.txt

From: "Teague, Nik" <[email-masked]>
Date: Sun, 5 Jul 2015 06:51:17 +0000

Hi,

-01 draft submitted for review and discussion.

As always - comments and feedback are welcome and I look forward to seeing
you all at the meeting in Prague

Thanks,

-Nik

https://www.ietf.org/internet-drafts/draft-teague-open-threat-signaling-01.
txt

On 05/07/2015 07:35, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-teague-open-threat-signaling-01.txt
>has been successfully submitted by Nik Teague and posted to the
>IETF repository.
>
>Name:		draft-teague-open-threat-signaling
>Revision:	01
>Title:		Open Threat Signaling using RPC API over HTTPS and IPFIX
>Document date:	2015-07-05
>Group:		Individual Submission
>Pages:		19
>URL:            
>https://www.ietf.org/internet-drafts/draft-teague-open-threat-signaling-01
>.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-teague-open-threat-signaling/
>Htmlized:       
>https://tools.ietf.org/html/draft-teague-open-threat-signaling-01
>Diff:           
>https://www.ietf.org/rfcdiff?url2=draft-teague-open-threat-signaling-01
>
>Abstract:
>   This document defines a method by which a device or application may
>   signal information relating to current threat handling to other
>   devices/applications that may reside locally or at the service
>   provider.  The initial focus is ddos mitigation; however, the method
>   may be extended to communicate any threat type.  This will allow for
>   a vendor or provider agnostic approach to threat mitigation utilising
>   multiple layers of protection as the operator sees fit.
>
>   The dissemination of threat information will occur utilising JSON RPC
>   API over HTTPS communications between devices/applications and will
>   be augmented by IPFIX and UDP or SCTP for signaling telemetry
>   information relating to attacks and protected object data.
>
>   An open standards based approach to communication between on-premise
>   DDoS mitigation devices and service provider based DDoS protection
>   services allows for enterprises to have a wider range of options to
>   better secure their environments without the limitations of vendor
>   lock-in.
>
>
>                  
>        
>
>
>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.
>
>The IETF Secretariat
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Sun, 05 Jul 2015 23:53:34 +0700

> -01 draft submitted for review and discussion.

One question which springs to mind regards the inclusion of SCTP in the 
latest draft.  I'm a big fan of SCTP, from a functional perspective; 
unfortunately, it hasn't been as widely-adopted as it deserves to be, 
and so its usefulness for this application as a stateful secondary 
transport is questionable, given the problems likely to be encountered 
in terms of traversing network access policies/ACLs/firewall rules, NAT 
policies, proxies, et. al.

Can you expound upon the rationale for specifying SCTP in this latest 
draft?

Thanks!

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

---

From: "Teague, Nik" <[email-masked]>
Date: Sun, 5 Jul 2015 19:00:10 +0000

>Can you expound upon the rationale for specifying SCTP in this latest

Certainly - Draft -00 referenced UDP for the signaling channel alone... as
it pertains to IPFIX and flow export generally this is certainly the most
familiar and commonly deployed transport, that I encounter anyway.

During the IETF92 BOF Brian Trammel queried the use of UDP and requested
that we seriously consider SCTP as an alternative or option.  If I recall
correctly, it was mentioned at the time that UDP was present for backwards
compatibility and didn’t appear to be going away but new world order would
be better served from deploying SCTP.  In that regard I thought it was
worth considering as a transport option.  I think there are other
potential benefits that SCTP can offer over the standard UDP and RFC7011
highlights its strengths in this context at least.  The main question will
be whether these are benefits for our needs or just additional needless
complexity.

I should also mention that I recall Brian mentioning that as there were a
few examples of running code out there, practicality would suggest we pick
the simplest intersection.

As you mention though, the middleware is where things will become complex
and unwieldily if we select the _wrong_ transport and that’s really going
to be the crux of the decision process within the WG.  IE. If we
emphatically stipulate transport X when everything in between will be hard
pressed to deal with it correctly or at all then we aren’t fulfilling any
useful function by pursuing that course (regardless of how funky we think
it may be or what the RFC stipulates MUST be supported).  And that’s one
of the reasons I went with a simple ‘OR’ at this stage since I think all
these factors bear discussion/consideration as we make our choice.

I’d like to hear everyone's further thoughts on the matter.

Thanks,

-Nik

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 02:24:32 +0700

> I’d like to hear everyone's further thoughts on the matter.

It's pretty well-established that we need a stateful transport 
alternative, per previous discussion on-list.  Unfortunately, it's also 
pretty well-established that we can't simply assume that SCTP will make 
it through a given topological path and/or intervening 
devices/services/policies, especially with regards to endpoint networks, 
which is where the majority of DOTS supplicants will likely reside.

Though it pains me to say it, I simply don't think SCTP can seriously be 
considered for this application, at least in the initial stages, due to 
these significant operational concerns.  While DOTS is an extremely 
important initiative which will have a far-reaching positive impact when 
brought to fruition, it isn't likely to be the 'killer app' which brings 
SCTP adoption into the mainstream, either.

Note that this hasn't anything to do with the availability of code, 
example implementations, etc. - it's an unfortunate side-effect of the 
network-policy-based overfiltering and lowest-common-denominator 
protocol support in the installed base and default configurations, all 
of which are constant banes to innovation in the Internet space.

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 05 Jul 2015 23:21:48 -0400

> policies, proxies, et. al.

If UDP traverses the path, then SCTP-in-UDP can as well (e.g. RFC6951).

There might be good arguments against SCTP, but this doesn't seem like
one of them.

-- 
Wes Eddy
MTI Systems

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 6 Jul 2015 03:48:51 +0000

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Wesley Eddy
> Sent: Monday, July 06, 2015 8:52 AM
> To: Roland Dobbins; [email-masked]
> Subject: Re: [Dots] New Version Notification for draft-teague-open-threat-
> signaling-01.txt
> 
> > One question which springs to mind regards the inclusion of SCTP in
> > the latest draft.  I'm a big fan of SCTP, from a functional
> > perspective; unfortunately, it hasn't been as widely-adopted as it
> > deserves to be, and so its usefulness for this application as a
> > stateful secondary transport is questionable, given the problems
> > likely to be encountered in terms of traversing network access
> > policies/ACLs/firewall rules, NAT policies, proxies, et. al.
> 
> 
> There might be good arguments against SCTP, but this doesn't seem like one of
> them.

WebRTC for data channels uses SCTP over DTLS over UDP to solve the NAT traversal problem.

-Tiru

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

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 12:36:18 +0700

> If UDP traverses the path, then SCTP-in-UDP can as well (e.g. 

The point of having an alternative stateful transport is precisely 
because, in many cases, UDP can't traverse the path due to excessive 
endpoint-network filtering.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 12:36:53 +0700

> WebRTC for data channels uses SCTP over DTLS over UDP to solve the NAT 

See previous reply.

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 6 Jul 2015 09:30:58 +0100

> As always - comments and feedback are welcome

Re using SCTP as an alternative protocol debate.

I believe that we have lost focus on the boundary / extreme conditions
caused by a DDoS attack - which need to be handled as this is why DOTS is in
existence!

Any connection orientated protocol - whether it is TCP, SCTP or anything
else - that is totally dependent on the returning "ACK" which travels in the
opposite direction to the main data flow, will fail / rate-limit / block etc
if for any reason the "ACK" cannot get through.  Thus any returning "pipe
full" type scenario (as caused by a DDoS attack) to the "exporting process"
will stop the ability of the "exporting process" to transmit anything to the
"collecting process".  Game over.

UDP has its limitations, but only needs to transmit the IPFIX information in
one direction, usually in the opposite direction to the DDoS attack.  The
"collecting process" can determine (through missing heartbeat packets etc.)
that there is an issue at the "exporting process" end (or somewhere in
between in the data path) and can take appropriate action if needed.

Regards

Jon

PS The irony here is UDP is the reliable protocol, but we have all been
taught that UDP is unreliable compared to TCP!

---

From: Gilbert Clark <[email-masked]>
Date: Mon, 06 Jul 2015 07:24:51 -0400

From section 6.3 of RFC 5153 ("IP Flow Information Export (IPFIX) 
Implementation Guidelines"):

"TCP can be used as a transport protocol for IPFIX if one of the 
endpoints has no support for SCTP, but a reliable transport is needed 
and/or the network between the Exporter and the Collector has not 
explicitly been provisioned for the IPFIX traffic.  TCP is one of the 
core protocols of the Internet and is widely supported."

Would it make sense to adopt a similar position here?

-Gilbert Clark

On 7/5/2015 3:24 PM, Roland Dobbins wrote:
> alternative, per previous discussion on-list.  Unfortunately, it's 
> also pretty well-established that we can't simply assume that SCTP 
> will make it through a given topological path and/or intervening 
> devices/services/policies, especially with regards to endpoint 
> networks, which is where the majority of DOTS supplicants will likely 
> reside.
>
> Though it pains me to say it, I simply don't think SCTP can seriously 
> be considered for this application, at least in the initial stages, 
> due to these significant operational concerns. While DOTS is an 
> extremely important initiative which will have a far-reaching positive 
> impact when brought to fruition, it isn't likely to be the 'killer 
> app' which brings SCTP adoption into the mainstream, either.
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 20:27:47 +0700

> caused by a DDoS attack - which need to be handled as this is why DOTS 

Not at all.

The reason we need an alternative stateful transport was discussed 
on-list a few weeks ago.  Suggest you read through the list archives.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 20:31:54 +0700

> Would it make sense to adopt a similar position here?

Yes, IMHO, keeping in mind that we should keep to general principles for 
now, as we're at the beginning of the requirements-definition has.

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 6 Jul 2015 14:57:58 +0100

> The reason we need an alternative stateful transport was discussed on-list
a few weeks ago.  Suggest you read through the list archives.

Sure - I had already read the information you refer to circa 11th June, but
did not have time to respond then.

The issues with Stateful firewall / NAT / ACLs etc for UDP almost completely
disappear if you look at a uni-directional UDP flow containing the IPFIX
signalling information - but agreed issues are problematic for
bi-directional UDP flow.

All that really needs to be considered is the security of the information
held within the UDP flow - wrapping it in a IPSEC tunnel or similar we go
back to the "ACK" response failing to get back issue when keys have to be
re-negotiated.

Regards

Jon

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 21:09:04 +0700

> signalling information - but agreed issues are problematic for

Actually, it's also a problem for unidirectional communications due to 
overfiltering and overly-restrictive traffic-transformation 
configurations/policies which is all-too-commonly encountered on 
endpoint networks, whether said communications are southbound - 
northbound, northbound - southbound, or eastbound-westbound (all of 
which are relevant to DOTS).

In order for DOTS to succeed, we must take into account 
lowest-common-denominator, overly-restrictive communications channels, 
often the result of network access policy arteriosclerosis, 
operational/architectural entropy, and overenthusiasm.

---

From: Scott Barvick <[email-masked]>
Date: Mon, 6 Jul 2015 14:09:47 +0000

And one general principle that we cannot forget is that the supplicant or the link to it may be under a significant attack when we need all of the mechanisms to work.

IMO, the one way, outbound telemetry traffic (e.g IPFIX) is the easy part.    The telemetry information can be/will be resent periodically and there will be a good chance one can get out.

The signaling channel that sends the value-added information, up to and including of course, the 'signal' is the harder problem.  It has more semantics associated with it so the requirements across the board will be more stringent, but the obvious choices for transports may not perform reliably under a heavy inbound attack.

Scott

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Monday, July 06, 2015 9:58 AM
To: [email-masked]
Subject: Re: [Dots] New Version Notification for draft-teague-open-threat-signaling-01.txt

> on-list

Sure - I had already read the information you refer to circa 11th June, but did not have time to respond then.

The issues with Stateful firewall / NAT / ACLs etc for UDP almost completely disappear if you look at a uni-directional UDP flow containing the IPFIX signalling information - but agreed issues are problematic for bi-directional UDP flow.

All that really needs to be considered is the security of the information held within the UDP flow - wrapping it in a IPSEC tunnel or similar we go back to the "ACK" response failing to get back issue when keys have to be re-negotiated.

Regards

Jon

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 21:12:17 +0700

On 6 Jul 2015, at 21:09, Scott Barvick wrote:

> And one general principle that we cannot forget is that the supplicant 
> or the link to it may be under a significant attack when we need all 
> of the mechanisms to work.
>
> IMO, the one way, outbound telemetry traffic (e.g IPFIX) is the easy 
> part.    The telemetry information can be/will be resent periodically 
> and there will be a good chance one can get out.
>
> The signaling channel that sends the value-added information, up to 
> and including of course, the 'signal' is the harder problem.  It has 
> more semantics associated with it so the requirements across the board 
> will be more stringent, but the obvious choices for transports may not 
> perform reliably under a heavy inbound attack.

Concur 100%.  Also, the notions of mutual authentication and privacy 
protections are applicable, here.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Jul 2015 14:21:12 +0000

Another thing to consider is the just-starting SPUD work, which takes as one of its primary justifications that SCTP has failed to get widespread adoption.

If TCP/TLS isn't sufficient, then perhaps given the likely timetables, waiting for SPUD is a reasonable fallback.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 21:34:21 +0700

On 6 Jul 2015, at 21:21, Salz, Rich wrote:

> If TCP/TLS isn't sufficient, then perhaps given the likely timetables, 
> waiting for SPUD is a reasonable fallback.

There are certainly potential benefits to this approach; however, there 
is a longstanding significant unfulfilled need in the operational 
community for a standardized signaling mechanism for initiating and 
reporting on the status and outcome of DDoS mitigation efforts.

It is also important to note that it is expected that DOTS will evolve 
over time in order to add new capabilities and to improve with regards 
to its various aspects and functionalities.

And while there are always pros and cons of any given approach to be 
weighed, we mustn't make the perfect the enemy of the merely good, or we 
won't get something usable in the hands of operators within a reasonable 
timeframe.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Jul 2015 14:42:18 +0000

> won't get something usable in the hands of operators within a reasonable

The question is whether the existing widely deployed protocols are good enough, or whether adding one that isn't widely deployed is a net positive or not, right?

---

From: John Schiel <[email-masked]>
Date: Mon, 06 Jul 2015 08:57:27 -0600

> The question is whether the existing widely deployed protocols are good enough, or whether adding one that isn't widely deployed is a net positive or not, right?
In order to get this WG moving forward, we need to use existing, 
established communication protocols. I'm not saying SPUD is an inferior 
protocol but to get DOTS WG implemented sooner, we should not wait for 
an as yet undefined,un-chartered protocol.

As Roland stated, "It is also important to note that it is expected that 
DOTS will evolve over time in order to add new capabilities and to 
improve with regards to its various aspects and functionalities."

Once DOTS is implemented and once SPUD is defined, it may later be 
determined SPUD may be a useful protocol.

--John Schiel

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 21:59:29 +0700

On 6 Jul 2015, at 21:42, Salz, Rich wrote:

> The question is whether the existing widely deployed protocols are 
> good enough, or whether adding one that isn't widely deployed is a net 
> positive or not, right?

Yes.  One data point to consider is that vendor-proprietary solutions 
have met with some success utilizing widely-deployed transports.

That being said, it's imperative that we develop a standards-based 
mechanism which broadens the participatory scope of DDoS mitigation to 
potentially encompass all relevant network elements and devices.  And 
that we utilize the tools at hand wherever it makes sense to do so, and 
that we do this in a timely manner.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 22:01:35 +0700

> determined SPUD may be a useful protocol.

Concur 100% - let's get something usable into the hands of operators 
within a reasonable timeframe, and then we can turn our attention to 
emerging efforts like SPUD for follow-on phases of DOTS.

---

From: Scott Barvick <[email-masked]>
Date: Tue, 7 Jul 2015 01:01:32 +0000

And I think I need to point out that draft-teague-open-threat-signaling-01.txt already has a reasonable proposal for communicating the necessary threat information using the UDP-based IPFIX signaling channel when under attack.   This is straightforward and has the sophistication to move from higher protocol value add during normal operations to the required threat signaling information when the link or device becomes overwhelmed.

Scott

On Jul 6, 2015, at 10:12 AM, Roland Dobbins <[email-masked]> wrote:

> Concur 100%.  Also, the notions of mutual authentication and privacy protections are applicable, here.
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 07 Jul 2015 14:38:14 +0700

On 7 Jul 2015, at 8:01, Scott Barvick wrote:

> And I think I need to point out that 
> draft-teague-open-threat-signaling-01.txt already has a reasonable 
> proposal for communicating the necessary threat information using the 
> UDP-based IPFIX signaling channel when under attack.

Concur that IPFIX is certainly a viable candidate for this 
functionality; however, we need to ensure we've a complete set of 
requirements defined in order to guide our ultimate decisions in this 
regard.

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 7 Jul 2015 11:08:52 +0000

So, our current consensus is that we go on working on the transport of ipfix over udp for the timely output. Meanwhile, we can observe and discuss the other options and maybe consider them when time is appropriate.
Is it right?

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2015年7月7日 15:38
收件人: [email-masked]
主题: Re: [Dots] New Version Notification for draft-teague-open-threat-signaling-01.txt

> UDP-based IPFIX signaling channel when under attack.

Concur that IPFIX is certainly a viable candidate for this functionality; however, we need to ensure we've a complete set of requirements defined in order to guide our ultimate decisions in this regard.

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 07 Jul 2015 18:36:11 +0700

On 7 Jul 2015, at 18:08, Xialiang (Frank) wrote:

> So, our current consensus is that we go on working on the transport of 
> ipfix over udp for the timely output.

I individually believe that this potential avenue should be thoroughly 
investigated; however, it's far too early to say we've attained 
consensus in this regard.

> Meanwhile, we can observe and discuss the other options and maybe 
> consider them when time is appropriate.

Yes, this is the current position.

---

From: Scott Barvick <[email-masked]>
Date: Tue, 7 Jul 2015 12:47:13 +0000

I agree with Roland.  We are making a standard that needs to support a
breadth of use cases, but having a sense of a solution that can satisfy
the arguably most difficult networking situation utilizing a base of
existing capabilities is comforting.

Scott

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 7 Jul 2015 13:05:57 +0000

Any alternative views on where the starting point should be for transport and encoding?

Roman

> From: Dots [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
> Sent: Tuesday, July 07, 2015 7:09 AM
> To: Roland Dobbins
> Cc: [email-masked]
> Subject: [Dots] 答复: New Version Notification for draft-teague-open-
> threat-signaling-01.txt
> 
> So, our current consensus is that we go on working on the transport of ipfix
> over udp for the timely output. Meanwhile, we can observe and discuss the
> other options and maybe consider them when time is appropriate.
> Is it right?
> 
> -----邮件原件-----
> Concur that IPFIX is certainly a viable candidate for this functionality;
> however, we need to ensure we've a complete set of requirements defined
> in order to guide our ultimate decisions in this regard.
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 07 Jul 2015 20:09:28 +0700

> Any alternative views on where the starting point should be for 

Defining the actual functional and operational requirements for DOTS 
should be the starting-point, IMHO.

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 7 Jul 2015 13:17:51 +0000

Agreed. We should focus on use cases and requirements first!

Roman

> On Jul 7, 2015, at 9:09 AM, Roland Dobbins <[email-masked]> wrote:
> 
> 
> Defining the actual functional and operational requirements for DOTS should be the starting-point, IMHO.
>