Subject: Re: [I2nsf] scope

From: Linda Dunbar <[email-masked]>
Date: Wed, 1 Apr 2015 17:31:30 +0000

Nik,

Can you elaborate a bit more on the  "peacetime provisioning channel"?

What kind of "configuration data" is exchanged on over this channel? What protocol? Is it NETCONF?

In parallel to DOTS, there is the I2NSF initiative intended for specifying the security policies to  security functions (primarily the flow based security functions).
https://datatracker.ietf.org/doc/draft-lopez-i2nsf-packet/ has identified three types interfaces to security functions:
*       Configuration
-      Device configuration
-      Network configuration
*       Signaling
-      Status
-      Counters
-      Queries
-      Alerts
*       Provisioning
-      Capabilities
-      Policy
-      Object Configuration

I2NSF will focus on the 3rd bullet, i.e. the Provisioning part.

Just want to see if the provisioning you mentioned could provide the synergy to I2NSF's provisioning.

Thanks,
Linda

From: Dots [mailto:[email-masked]] On Behalf Of Teague, Nik
Sent: Tuesday, March 31, 2015 9:51 AM
To: [email-masked]
Subject: [Dots] scope

Hi,

I hope everyone had good journeys home or onward to wherever you may be.

I wanted to follow up on the BOF and the outcomes - in particular I wanted to discuss scope, requirements and some thoughts.  Please feedback your thoughts/opinions...

Firstly applicability - as was clear from the BOF we were defining DDoS mitigation devices/applications or devices which may have other functions but contain a DDoS mitigation element.  The devices/applications may have either inline or out of band detection/mitigation capabilities and may be deployed as part of a larger mitigation strategy.  Its signaling between these elements and an upstream or service provider that we're concerned with.  The term CPE was used which we will clarify to the term 'on-premise' to remove any confusion as to what we're discussing.

These devices/applications already provide a degree of sophisticated analytics based on the traffic they observe.  The upstream element may, therefore, only require data relevant to its needs in identifying that an offramp is desired and telemetry in order for situational awareness in providing the correct mitigation strategy.  As was discussed feedback from the upstream/service provider is desirable relating to ongoing attack statistics and also its conclusion.

Characteristics

Signaling:
>From discussions its clear that the signaling element should include a level of encryption/obfuscation to negate the need for additional vpns, infrastructure etc.  Signaling should be lightweight and transport should not be session oriented in the classical sense.  It may be assumed likely that the ingress path to the on-premise device may be congested and loss should be expected and tolerated.  The ability to optimise as much information as possible into discrete packets is a definite advantage based upon the high probability of link/path congestion.

Provisioning:
A peacetime provisioning channel has proven effective in various vendor implementations for authentication, key exchange, configuration exchange etc. and it seems a good way to proceed since the information exchanged is usually weightier and doesn't have restrictions relating to a congested network.  From discussions it was suggested the on-premise device would be in the best position to communicate thresholds as to when a traffic swing should be triggered.  The ability to simply signal (without additional qualification) that an upstream mitigation is requested is also desirable.  This may be a potential in-road to enabling this on less sophisticated (re DDoS) device types - e.g. If link >=80% then call for help.

Thanks,

-Nik

"This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately."

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 8 Apr 2015 15:32:12 +0000

Hi,

On 01/04/2015 13:31, "Linda Dunbar" <[email-masked]> wrote:

>Nik,
>
> 
>Can you elaborate a bit more on the  ³peacetime provisioning channel²?
>
> 
>What kind of ³configuration data² is exchanged on over this channel? What
>protocol? Is it NETCONF?

The term peacetime is somewhat fuzzy and I keep trying out variations that
feel/describe better.  The intent of the channel is the exchange of
information that relates to the service setup/provisioning and not to the
actual signaling - This could be authentication, key/token exchanges,
whitelist, megaproxy lists etc.  In addition this could be the describing
of capabilities (some devices/applications may only monitor while others
may have a mitigation capability).

As far as the protocol - I had thought JSON RPC API over HTTPS - its
reasonably light to implement (anything with access to cURL can take
advantage of it.  It also means little to no re-tooling across many DDoS
mitigation platforms which may be *nix based at their core.

>
> 
>In parallel to DOTS, there is the I2NSF initiative intended for
>specifying the security policies to  security functions (primarily the
>flow based security functions).
>
>https://datatracker.ietf.org/doc/draft-lopez-i2nsf-packet/ has identified
>three types interfaces to security functions:
>
>€      
>Configuration
>     
>Device configuration
>     
>Network configuration
>€      
>Signaling
>     
>Status
>     
>Counters
>     
>Queries
>     
>Alerts
>€      
>Provisioning
>     
>Capabilities
>     
>Policy
>     
>Object Configuration
>
> 
> 
>Just want to see if the provisioning you mentioned could provide the
>synergy to I2NSF¹s provisioning.
> 
>Thanks,
>
>Linda

I would suggest that the device provisioning is already assumed to have
happened and the provisioning we discuss here relates to the service.  I
think there is some potential overlap (filter lists of whatever type) and
its worth investigating and identifying where this occurs and what to
leverage in that event.

Thanks,

-Nik