Subject: [Dots] feedback on draft-teague-open-threat-signaling-00

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 10 Mar 2015 19:30:25 +0000

Hi Nik!

I wanted to get the conversation started around your draft.  Please find below a few things that jumped out at me upon first review.  I fully realize that as an -00 informational draft some of the details poked at by these questions would get resolved later or be implementation details.

** Why use two different channels? Why two different formats for each of the channels?  

IPFIX being widely implemented on some mitigation devices is cited in Section 6.  Does it follow that JSON over HTTP is also widely implemented on the same devices?

Is the assumption that IPFIX is commonly implemented on IDS, IPS and WAFs also hold?

** Page 2, Section 2.  Coming into this section it wasn't clear for which channel, IPFIX or JSON, this dictionary was referencing.

** Page 4, last paragraph.  "This specific set of identifiers may be further expanded .. across JSON API".  I didn't find a description of this update mechanism in the draft.

** Page 7, Section 4.  It wasn't readily apparent to me on how to use these IDs in the IPFIX templates because the category/type names didn't line up

**Page 9, Section 5. "The JSON API channel is expected to be opened at regular intervals ..."  How often is that?

** Page 10, device_threshold_config and mitigation_info. Both of these attributes/objects are noted to be extensible but the explicit mechanism isn't in the draft.  

** Page 11, mitigation_info status attribute.  It would appear that the status attribute is mutually exclusive.  However, I was wondering if the monitoring and mitigation state might arise simultaneously.  Wouldn't IPFIX message be getting sent while mitigation is happing upstream?

** Page 11, Section 5.0.  What happens if an unrecognized attribute or object is sent?

** Page 11, Section 5.1 diagram.  The term used for node "I" is "IPFIX receiver".  Is that the same thing as an "IPFIX Collector" used in the IPFIX architecture?

** Page 11-12, Example, The write-up for the example states that the "SOS flag will be set to true should the component cpu=85% or mem=85% or bandwidth=75%".  I'm trying to understand how the "D" in the reference architecture would have known that.  Specifically, did the "D" know that load_factor1 = cpu, load_factor2 = mem and load_factor3 = bandwidth?  Shouldn't the original POST sent by D in the example have these variables defined with "load_factor1: <alias>, load_factor2: <alias>, etc." declarations?  Also, I didn't find it specified anywhere that the load_factors are all ORed together (any has to be true).  Are other expressions possible?

** Page 12, Section 6.  I found the write-up of when each template gets sent very helpful.  I would suggest expanding this narrative to describe the JSON API too so that the reader gets a sense of who sends what (relative to the reference architecture) and under what circumstances.

** Page 12, Section 6, second paragraph.  "An attack will trigger the creation of an incident record".  I couldn't find a definition of an incident record? Of the three IPFIX templates (event, protected object, attack/threat) is it the event template?

** Page 12, Section 6, second paragraph. "Due to the unreliable nature of UDP ... will repeat at regular intervals .."  How often is that?

** Page 12, Section 6, fourth paragraph.  "An IPFIX event data export may be used as a heartbeat between elements".  How often does this heartbeat get sent before "C" or "I" start worrying?  Likewise, if "I" is receiving the IPFIX messages from "D", but "C" is doing all of the signaling back to "D".  What is the signaling between "I" and "C"?

** Page 13, Section 6, templates.  I recognize many of the field names from previous sections but missing are the detailed field write-ups (e.g., data types).  Furthermore, in considering the IPFIX header, I was also wondering how the observationdomain Id was getting set.

** Page 15, Section 8, IANA considerations.  I would have figured that some of these newly defined IPFIX might be put into a registry for future maintenance if a construct like this draft moves forward.

Roman

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 19 Mar 2015 00:45:06 +0000

On 10/03/2015 19:30, "Roman D. Danyliw" <[email-masked]> wrote:

>Hi Nik!
>
>I wanted to get the conversation started around your draft.  Please find
>below a few things that jumped out at me upon first review.  I fully
>realize that as an -00 informational draft some of the details poked at
>by these questions would get resolved later or be implementation details.

- Hi RomanŠ Thanks for taking the time to review this and provide such
detailed feedback.

>** Why use two different channels? Why two different formats for each of

- Great question - DDoS mitigation platforms tend to operate in a
peacetime posture where traditional channels are feasible or they are
operating in a mitigation posture where their ingress links could be
heavily congested.  In the latter instance connection oriented protocols
become problematic or impossible to maintain.  If an operator wants to
have their device communicate with an upstream DDoS mitigation service
provider who will undertake scrubbing they will have to exchange a degree
of information for the provider to be able to effectively protect them in
times of need.  This information can be exchanged across traditional
channels and the information exchange at this stage may not be exclusively
one way.  E.g the service provider may want to push information
(whitelists, blacklists, collector destinations etc.) back to the operator
device.  Splitting things into 2x channels provides, in my mind, the
correct protocol for each postureŠ The differing formats, again, lend
themselves well to their given tasks IPFIX is already a great foundation
for data export beyond flow information and its template based approach
also lends itself well to extensibility.

>IPFIX being widely implemented on some mitigation devices is cited in
>Section 6.  Does it follow that JSON over HTTP is also widely implemented
>on the same devices?

- Many of the CPE devices in this sphere already have some implementation
of issuing API calls to some upstream peer.  With a JSON RPC API over
HTTPS this may be accomplished by anything running cURL.

>Is the assumption that IPFIX is commonly implemented on IDS, IPS and WAFs

- To my knowledge this doesn¹t hold - and this highlights that the 00
draft references to these applications being too generic and really scope
should focus on DDoS mitigation platforms.  I do think that expanding this
to other applications which are in the path of attacks could provide some
interesting opportunities - but at this stage that is very ambitious.

>** Page 2, Section 2.  Coming into this section it wasn't clear for which
>channel, IPFIX or JSON, this dictionary was referencing.

- Noted - the dictionary is used by the IPFIX channel for communication of
telemetry.  Clarity is required in the description and assignment to a
channel.

>** Page 4, last paragraph.  "This specific set of identifiers may be
>further expanded .. across JSON API".  I didn't find a description of
>this update mechanism in the draft.

- Nope - this is at this stage a concept that I would like to explore in
greater detail as I believe this could offer a powerful method of updating
the dictionary in the field.

>** Page 7, Section 4.  It wasn't readily apparent to me on how to use
>these IDs in the IPFIX templates because the category/type names didn't
>line up

- Yes - I can see this isn¹t clear and needs to be better explained/tied
in.

>**Page 9, Section 5. "The JSON API channel is expected to be opened at
>regular intervals ..."  How often is that?

- This could be negotiable and probably should be - on first registration
a device and service provider could agree a check in interval.  I don¹t
perceive this being required though at intervals of less than 12 hours or
probably even 24.  Although elaborating on all this in the draft would
obviously be helpful.

>** Page 10, device_threshold_config and mitigation_info. Both of these
>attributes/objects are noted to be extensible but the explicit mechanism
>isn't in the draft.

- Yes I see how that needs to be represented with more clarity both in the
text and the JSON examples.

>** Page 11, mitigation_info status attribute.  It would appear that the
>status attribute is mutually exclusive.  However, I was wondering if the
>monitoring and mitigation state might arise simultaneously.  Wouldn't
>IPFIX message be getting sent while mitigation is happing upstream?

- Yes there are instances where both would occur and it is worth adjusting
the status definitions to include a mitigating-monitoring for those
overlapping occurrences.

>** Page 11, Section 5.0.  What happens if an unrecognized attribute or

- An unrecognised attribute/object where it occurs outside of the bare
bones protocol definition should probably result in a warning but should
not interfere with the systems ongoing operation.

>** Page 11, Section 5.1 diagram.  The term used for node "I" is "IPFIX
>receiver".  Is that the same thing as an "IPFIX Collector" used in the
>IPFIX architecture?

- ³Receiver" should be replaced by ³collector² in this instance.

>** Page 11-12, Example, The write-up for the example states that the "SOS
>flag will be set to true should the component cpu=85% or mem=85% or
>bandwidth=75%".  I'm trying to understand how the "D" in the reference
>architecture would have known that.  Specifically, did the "D" know that
>load_factor1 = cpu, load_factor2 = mem and load_factor3 = bandwidth?
>Shouldn't the original POST sent by D in the example have these variables
>defined with "load_factor1: <alias>, load_factor2: <alias>, etc."
>declarations?  Also, I didn't find it specified anywhere that the
>load_factors are all ORed together (any has to be true).  Are other
>expressions possible?

- Other expressions may, indeed, be possible and this does require further
exploration and explanation.  Different systems may have differing
capabilities and in certain instances any one of those thresholds being
reached may not be enough to initiate offramping.  The assumption was,
however, that any of the load_factors reaching a threshold would shortly
result in a degradation of some kind.  My preference would be to specify
the expressions or combinations that a particular device would consider
critical and as such an offramp action would be desirable.

>** Page 12, Section 6.  I found the write-up of when each template gets
>sent very helpful.  I would suggest expanding this narrative to describe
>the JSON API too so that the reader gets a sense of who sends what
>(relative to the reference architecture) and under what circumstances.

- Noted...

>** Page 12, Section 6, second paragraph.  "An attack will trigger the
>creation of an incident record".  I couldn't find a definition of an
>incident record? Of the three IPFIX templates (event, protected object,
>attack/threat) is it the event template?

- Its the event record and this was an error of mixing terminology -
incident is a term of reference for certain DDoS mitigation
implementations but in this context we¹re describing it under the umbrella
of an event.  

>
>** Page 12, Section 6, second paragraph. "Due to the unreliable nature of
>UDP ... will repeat at regular intervals .."  How often is that?

- This should be a tuneable function in my mind.  A default of somewhere
between 3 and 5 minutes should probably suffice.

>** Page 12, Section 6, fourth paragraph.  "An IPFIX event data export may
>be used as a heartbeat between elements".  How often does this heartbeat
>get sent before "C" or "I" start worrying?  Likewise, if "I" is receiving
>the IPFIX messages from "D", but "C" is doing all of the signaling back
>to "D".  What is the signaling between "I" and "C"?

- I think for the heartbeat to be effective then every 60 seconds is a
good default.  The loss of 3x heartbeats (3minutes of no contact) could
result in the upstream considering communication to have been lost and a
warning/alert flagged up.

>** Page 13, Section 6, templates.  I recognize many of the field names
>from previous sections but missing are the detailed field write-ups
>(e.g., data types).  Furthermore, in considering the IPFIX header, I was
>also wondering how the observationdomain Id was getting set.

- Deriving the observationDomain ID may be implementation specific.  If we
set the ID from the perspective of the upstream then we are assuming that
this is the only export destinationŠ Which may not be the case.

>** Page 15, Section 8, IANA considerations.  I would have figured that
>some of these newly defined IPFIX might be put into a registry for future
>maintenance if a construct like this draft moves forward.

- I agree and this will be fixed.

Looking forward to seeing you in Dallas.

Thanks,

-Nik