Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 23 Mar 2015 22:41:46 +0100

Hello all,

Let me post two comments on draft-fu-ipfix-network-security.

1. XML representation

I am wondering if the draft could addrss the XML representation of the data
elements.
I understand that sometimes people (including myself) wish to avoid using
XML, but it would be beneficial if IODEF can use the data elements listed in
the draft.
The data elements listed in Section 3.1 could be also represented in XML.

IODEF  and IODEF-bis define data model for incident information sharing.
It can embed assorted information that is usable for incident analysis,
including event logs.
XML-style logs can also be embedded to IODEF through the means of IODEF-SCI.
IODEF-SCI planned to embed XML-type information, such as CEE.

If the ipfix-network-security draft can provide an XML representation of the
data element, IODEF can also convey the information.
I am not that familiar with the current situation on how organzations
actually share information, but I feel like that there are notable amount of
people who exchange information using XML.
So, addressing the other representations would also help the draft, I think.

Indeed, the same discussion applies to draft-teague-threat-signaling.

2. draft-fu-ipfix-network-security vs draft-teague-threat-signaling

Both of them approach attack/treat information expression and exchange.
Though the defined data elements are not the same (as can be seen in
Section 3.1 of draft-fu-ipfix-network-security and in Section 4 of
draft-teague-threat-signaling), I feel that they are somehow overlapping.
Having two different data representation is not something I like, so I would
like to hear the difference of their scopes.

I might have some misunderstanding, so your explanation would be helpful.
Thank you.

Take

-----Original Message----- 
From: Roman D. Danyliw
Sent: Monday, March 23, 2015 2:55 AM
To: [email-masked]
Subject: [Dots] FW: Prior discussion about
draft-fu-ipfix-network-security-00

Hello!

To those that might be in the same situation, Robert Moskwitz tracked down
that the place to download messages has moved.  Please now go to
http://www.ietf.org/mail-archive/text/dots/.

Roman

________________________________________
From: Robert Moskowitz [[email-masked]]
Sent: Sunday, March 22, 2015 8:47 AM
To: Roman D. Danyliw; [email-masked]'
Subject: Re: [Dots] Prior discussion about
draft-fu-ipfix-network-security-00

Can you check with the list serve people as to why there is not a
downloadable form for the list as other IETF lists?  Granted I only
missed a few, but I like to have them all in my local folder.

On 03/21/2015 04:43 PM, Roman D. Danyliw wrote:
> Hello!
>
> Two formal drafts will be part of the agenda [1] at the DOTS BOF,
> draft-teague-open-threat-signaling-00 [2] and
> draft-fu-ipfix-network-security-00 [3].  Discussion about the former
> (draft-teague-open-threat-signaling-00) already started on the DOTS list
> [4].  I wanted  to provide a pointer to prior discussions about the latter
> draft (draft-fu-ipfix-network-security-00) that were on the IPFIX list [5]
> in December 2014.
>
> Regards.
> Roman
>
> [1] http://www.ietf.org/mail-archive/web/dots/current/msg00003.html
> [2] https://tools.ietf.org/html/draft-teague-open-threat-signaling-00
> [3] https://tools.ietf.org/html/draft-fu-ipfix-network-security-00
> [4] http://www.ietf.org/mail-archive/web/dots/current/msg00002.html
> [5] http://www.ietf.org/mail-archive/web/ipfix/current/msg07277.html
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: "Teague, Nik" <[email-masked]>
Date: Tue, 24 Mar 2015 00:11:46 +0000

Hi,

See inline

>Indeed, the same discussion applies to draft-teague-threat-signaling.

A factor of the draft-teague-threat-signaling proposal was to avoid the
weight of something like XML simply to keep the signaling portion light
and more pliable for UDP export.  I think we could obviously examine how
DOTS and IODEF etc. may interoperate as we proceed but was beyond the
scope of the initial 00 draft.  This list is a great place to have that
discussion.

>like to hear the difference of their scopes.

Taking draft-teague-threat-signaling - The proposal is to enable a DDoS
mitigation device, that is already more than capable of identifying and
dealing with attacks, to signal to a service provider with DDoS mitigation
capabilities telemetry data and when offramp to the service provider
infrastructure is desired.  DDoS mitigation devices are quite
sophisticated and come with their own suite of analytics. There is no
point in both an on-premise device and a provider analytics engine
recreating work when one can tell the other whats going on and we can all
get down to the mitigation part faster.  The telemetry export is there to
kickstart the upstream mitigation so the provider can have a suitable
granular mitigation strategy ready to go... rather than falling back on a
generic response while relearning the attack profile in order to tweak
said response to fit.

Reading over draft-fu-ipfix-network-security - I see this adding
enhancements to IPFIX which would still then require upstream/service
provider analytics to determine the attack and the appropriate response
(flagged in the slides as big data mining). For operators who are not
deploying a local mitigation device though I see the enhancements having
value for the service provider to identify, alert, notify the operator etc.

So I see the 2x as fulfilling different functions within differing
deployments.

>I might have some misunderstanding, so your explanation would be helpful.

Thanks,

-Nik

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Tue, 24 Mar 2015 03:14:05 +0000

Hi all,

  > From: Dots [mailto:[email-masked]] On Behalf Of Teague, Nik
  > Sent: Tuesday, March 24, 2015 8:12 AM
  > To: Takeshi Takahashi; Roman D. Danyliw; [email-masked]
  > Cc: [email-masked]
  > Subject: Re: [Dots] FW: Prior discussion about
  > >I am wondering if the draft could addrss the XML representation of the
  > >data elements.
  > >I understand that sometimes people (including myself) wish to avoid
  > >using XML, but it would be beneficial if IODEF can use the data
  > >elements listed in the draft.
  > >If the ipfix-network-security draft can provide an XML representation
  > >of the data element, IODEF can also convey the information.
  > >actually share information, but I feel like that there are notable
  > >amount of people who exchange information using XML.
  > weight of something like XML simply to keep the signaling portion light and
  > more pliable for UDP export.  I think we could obviously examine how DOTS
  > and IODEF etc. may interoperate as we proceed but was beyond the scope of
  > the initial 00 draft.  This list is a great place to have that discussion.
  > 
Ipfix has its own standardized approach to export messages. It defines how flow information is formatted and transmitted. Template can be customized to export and transmit message from exporter to collector. draft-fu-ipfix-network-security-00 directly reuses such mechanism to convey messages. Besides, efficiency is a big challenge in anti-DDOS attack, as big amount of flow information data should be observed and transmitted, therefore it's necessary to evaluate the efficiency of using xml to deliver those messages, and to see in which aspect the solution can interoperate with IODEF. 
  > >Having two different data representation is not something I like, so I
  > >would like to hear the difference of their scopes.
  > 
  > 
  > infrastructure is desired.  DDoS mitigation devices are quite sophisticated
  > and come with their own suite of analytics. There is no point in both an
  > on-premise device and a provider analytics engine recreating work when one
  > can tell the other whats going on and we can all get down to the mitigation
  > part faster.  The telemetry export is there to kickstart the upstream
  > mitigation so the provider can have a suitable granular mitigation strategy
  > ready to go... rather than falling back on a generic response while relearning
  > the attack profile in order to tweak said response to fit.
  > 
  > Reading over draft-fu-ipfix-network-security - I see this adding enhancements
  > to IPFIX which would still then require upstream/service provider analytics to
  > determine the attack and the appropriate response (flagged in the slides as
  > big data mining). For operators who are not deploying a local mitigation
  > device though I see the enhancements having value for the service provider
  > to identify, alert, notify the operator etc.
  > 
  > So I see the 2x as fulfilling different functions within differing deployments.

Indeed, good summary. 
Beside, draft-fu-ipfix-network-security-00 allows the central server learns the behavior of evolved attacks from big data mining, then adjusting thresholds or adding new metrics that might trigger the event alarm, and finally making acl policy, traffic steering policy and data cleaning policy more effectively and efficiently. 

Even though the data elements are different in both drafts, IMHO, they are actually observing behavior of the same attacks at different levels, and as both drafts are 00 version, we still need to discuss more on the data elements.

Regards,
Ana

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 24 Mar 2015 03:54:12 +0000

Hello,

It seems to me that the "signaling in order to mitigate DDoS" problem has been solved already by BGP FlowSpec. I am not sure if defining more verbose and detailed communications between network elements would add much value, since these devices cannot do more than signalling and mitigate.

Panos

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Hedanping (Ana)
Sent: Monday, March 23, 2015 11:14 PM
To: Teague, Nik; Takeshi Takahashi; Roman D. Danyliw; [email-masked]
Cc: [email-masked]
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00

Hi all,

Indeed, good summary. 

Regards,
Ana

---

From: "Teague, Nik" <[email-masked]>
Date: Tue, 24 Mar 2015 05:20:24 +0000

Hi,

On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" <[email-masked]>
wrote:

>Hello,
>
>It seems to me that the "signaling in order to mitigate DDoS" problem has
>been solved already by BGP FlowSpec. I am not sure if defining more
>verbose and detailed communications between network elements would add
>much value, since these devices cannot do more than signalling and
>mitigate.
>
>Panos

Flowspec is very effective within the bounds of its capabilities - if a
bad actor is hammering my network with an ntp reflection attack or my web
server with a whole swathe of large udp packets then I can easily build
filters to handle that - if the bad actor is hitting my web server with a
syn flood from a massively random source pool then I have to consider rate
limiting as probably my best, but maybe not ideal, option.  If I try and
generate more than 12k flow route filters to push to either my equipment
or my service providers (depending upon whether they support Flowspec)
then things can get a little hairy.  DDoS mitigation CPE and DDoS
mitigation providers exist because the need is there - The DOTS proposal
is that effective signaling is necessary between these elements, not
specifically generic network elements, but actual elements that are
concerned with often complex attacks that a flow route filter is unable to
deal with.  If my ingress links are saturated then signaling via a tcp
oriented session can potentially result in more cycles being spent trying
to initiate and maintain a session than actual information transferŠ and
if the connection drops then the whole thing has to start again.

Thanks,

-Nik

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 24 Mar 2015 05:57:49 -0500

Hi,

Thank you for the replies; I think I got the idea better than before.

> the initial 00 draft.  This list is a great place to have that discussion.

It would be great if we could have such a discussion.

Below are comments on why I would like to see the XML representation in the 
drafts.
IODEF is just one spec of many other specs that defines XML-based 
information model; there are lots more that haven't been brought to IETF 
(e.g., stix).
If you do not provide any XML schema (in the appendix of the drafts) on this 
issue, the same kind of work would be taken again in the future from the 
XML-based community.
I think that is a waste.
I know that XML-representation is off the context of these drafts and thus 
authors are not that happy to cope with that, but I believe it is worth 
saying that here :)
It could be that Nik's draft can gain little benefit by defining xml schema 
since it does not need further analytics, but I feel that it is useful for 
Ana's draft since it expects further analysis such as big data analysis.

Thank you.
Take

-----Original Message----- 
From: Teague, Nik
Sent: Tuesday, March 24, 2015 12:20 AM
To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi ; 
Roman D. Danyliw ; [email-masked]
Cc: [email-masked]
Subject: Re: [Dots] FW: Prior discussion about 
draft-fu-ipfix-network-security-00

Hi,

Thanks,

-Nik

---

From: Eric Burger <[email-masked]>
Date: Tue, 24 Mar 2015 07:39:49 -0400

Let me take it from a different perspective. If we could use XML, would we not just use IODEF and be done with it? My understanding is we cannot pay the XML tax and as such need to go a different route.

A well-defined data model would be very important for this effort. With a well-defined data model, one should be able to easily translate from IPFIX or some hyper-compressed binary encoding to XML.

> On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi <[email-masked]> wrote:
> 
> Hi,
> 
> Below are comments on why I would like to see the XML representation in the drafts.
> IODEF is just one spec of many other specs that defines XML-based information model; there are lots more that haven't been brought to IETF (e.g., stix).
> If you do not provide any XML schema (in the appendix of the drafts) on this issue, the same kind of work would be taken again in the future from the XML-based community.
> I think that is a waste.
> I know that XML-representation is off the context of these drafts and thus authors are not that happy to cope with that, but I believe it is worth saying that here :)
> It could be that Nik's draft can gain little benefit by defining xml schema since it does not need further analytics, but I feel that it is useful for Ana's draft since it expects further analysis such as big data analysis.
> 
> Thank you.
> Take
> 
> 
> -----Original Message----- From: Teague, Nik
> To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi ; Roman D. Danyliw ; [email-masked]
> Cc: [email-masked]

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 24 Mar 2015 06:58:01 -0500

> A well-defined data model would be very important for this effort. With a well-defined data model, one should be able to easily translate from IPFIX or some hyper-compressed binary encoding to XML.

I almost hate to say it, but if we can develop (or there already is) a 
Binary Encoding Rule(s) for XML to a very compressed format, then we can 
do the data modeling in XML, but transmit in this BER format.

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 24 Mar 2015 07:46:03 -0500

Hi Eric,

I agree on your comments, but let me remind you that we need a documented schema to use external XML via IODEF/IODEF-SCI.

> Let me take it from a different perspective. If we could use XML, would we not just use IODEF and be done with it? My understanding is we cannot pay the XML tax and as such need to go a different r…

Yes, I understand the same for the use cases that require prompt and automated actions.
I think this is true, though I haven’t done evaluation by myself. 

> A well-defined data model would be very important for this effort. 

I also agree on this point.

And I believe the outpuf these works will provide specific and practical data model.
I think we could consider how to reuse the output.
One example was IODEF; it can convey XML data if the schema is defined.

> With a well-defined data model, one should be able to easily translate from IPFIX or some hyper-compressed binary encoding to XML.

Yes, but we need a spec that defines a schema in order to list it in the IANA table of IODEF-SCI.
Even more, if these draft defines a schema, that can be used by non-IODEF techniques as well.

I am wondering if there is any negative effects of preparing a schema for the draft except the workload.
I have listened some discussion on XML vs JSON vs... etc. until now, but all of these works should be able to cope with each other regarding information model, I guess.

Kind regards,
Take

From: Robert Moskowitz 
Sent: Tuesday, March 24, 2015 6:58 AM
To: Eric Burger ; [email-masked] 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00

A well-defined data model would be very important for this effort. With a well-defined data model, one should be able to easily translate from IPFIX or some hyper-compressed binary encoding to XML.
I almost hate to say it, but if we can develop (or there already is) a Binary Encoding Rule(s) for XML to a very compressed format, then we can do the data modeling in XML, but transmit in this BER format.

On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi mailto:[email-masked] wrote:

Hi,

Thank you.
Take

Hi,

On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" mailto:[email-masked]
wrote:

Hello,

Panos

Thanks,

-Nik

--------------------------------------------------------------------------------
_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: Andrew Mortensen <[email-masked]>
Date: Tue, 24 Mar 2015 09:20:57 -0400

> On Mar 24, 2015, at 7:39 AM, Eric Burger <[email-masked]> wrote:
> 

This gets to the heart of the matter. In the case of draft-teague-threat-signaling-00, it is vital to keep the signaling packet size to a minimum. When the link is saturated the signaling element needs to be able to communicate protection needs in the most compact and most reliably delivered form possible. Small UDP packets stand the best chance of getting through, and the smaller the better. (Similarly, the HTTPS channel will not be a reliable vehicle for upstream acknowledgment of the signaling element’s heartbeat/export during attack.)

> A well-defined data model would be very important for this effort. With a well-defined data model, one should be able to easily translate from IPFIX or some hyper-compressed binary encoding to XML.

Agreed. 

andrew

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Mar 2015 09:31:46 -0400

With no hat on...

On Tue, Mar 24, 2015 at 9:20 AM, Andrew Mortensen <[email-masked]>
wrote:

> > Let me take it from a different perspective. If we could use XML, would
> we not just use IODEF and be done with it? My understanding is we cannot
> pay the XML tax and as such need to go a different route.
>
> This gets to the heart of the matter. In the case of
> draft-teague-threat-signaling-00, it is vital to keep the signaling packet
> size to a minimum. When the link is saturated the signaling element needs
> to be able to communicate protection needs in the most compact and most
> reliably delivered form possible. Small UDP packets stand the best chance
> of getting through, and the smaller the better. (Similarly, the HTTPS
> channel will not be a reliable vehicle for upstream acknowledgment of the
> signaling element’s heartbeat/export during attack.)
>
> > A well-defined data model would be very important for this effort. With
> a well-defined data model, one should be able to easily translate from
> IPFIX or some hyper-compressed binary encoding to XML.
>

I agree that this doesn't need an XML format for the signaling proposed.  I
also think it would be important for the barrier for implementation in
devices be low, meaning use of something that may already be implemented
and kept at signaling level.

For the device types being discussed, how many of them already have IPFIX
implemented?

However, creating relationships with IODEF to embed such content either
through the mechanism to attach a file or packet in RecordData or through a
schema extending IODEF via SCI could work.  I see these efforts as
complimentary in that the proposals in DOTS don't rise to the level of
incidents and the associated analysis, but rather provide data for analysis
that could result in incident/indicator identification.

Thanks,
Kathleen

> >> If you do not provide any XML schema (in the appendix of the drafts) on
> this issue, the same kind of work would be taken again in the future from
> the XML-based community.
> >> I think that is a waste.
> >> I know that XML-representation is off the context of these drafts and
> thus authors are not that happy to cope with that, but I believe it is
> worth saying that here :)
> >> It could be that Nik's draft can gain little benefit by defining xml
> schema since it does not need further analytics, but I feel that it is
> useful for Ana's draft since it expects further analysis such as big data
> analysis.
> >>
> >> Thank you.
> >> Take
> >>
> >>

-- 

Best regards,
Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Mar 2015 14:14:28 +0000

Well, there's ASN.1 XER which can go to DER, which I'm not seriously suggesting.  But was CBOR (IETF RFC 7049) already considered?

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: will <[email-masked]>
Date: Tue, 24 Mar 2015 20:43:21 -0400

If we are worried about trying to signal over saturated links, maybe we 
should consider using out of band signaling.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 25 Mar 2015 04:10:44 +0000

I think that is a strong assumption that would simplify the problem, but probably is not very practical.

After attending the BOF today it seems the problem trying to solve here is signaling over saturated links and the a data representation of DDoS activity to be exchanged. For the latter, existing representations could do the job IMO, unless there is DDoS info that cannot be described. But then we would need specific examples.

As someone put it in the BOF call today, scope should be well-defined if this ends up being a WG I believe.

Panos

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of will
Sent: Tuesday, March 24, 2015 8:43 PM
To: [email-masked]
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00

If we are worried about trying to signal over saturated links, maybe we should consider using out of band signaling.

On 03/24/2015 01:20 AM, Teague, Nik wrote:
>> It seems to me that the "signaling in order to mitigate DDoS" problem 
>> has been solved already by BGP FlowSpec. I am not sure if defining 
>> more verbose and detailed communications between network elements 
>> would add much value, since these devices cannot do more than 
>> signalling and mitigate.
>>
>> Panos
> Flowspec is very effective within the bounds of its capabilities - if 
> a bad actor is hammering my network with an ntp reflection attack or 
> my web server with a whole swathe of large udp packets then I can 
> easily build filters to handle that - if the bad actor is hitting my 
> web server with a syn flood from a massively random source pool then I 
> have to consider rate limiting as probably my best, but maybe not 
> ideal, option.  If I try and generate more than 12k flow route filters 
> to push to either my equipment or my service providers (depending upon 
> whether they support Flowspec) then things can get a little hairy.  
> DDoS mitigation CPE and DDoS mitigation providers exist because the 
> need is there - The DOTS proposal is that effective signaling is 
> necessary between these elements, not specifically generic network 
> elements, but actual elements that are concerned with often complex 
> attacks that a flow route filter is unable to deal with.  If my 
> ingress links are saturated then signaling via a tcp oriented session 
> can potentially result in more cycles being spent trying to initiate 
> and maintain a session than actual information transferŠ and if the connection drops then the whole thing has to start again.
>
> Thanks,
>
> -Nik
>
>
>
>

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 25 Mar 2015 12:12:28 +0000

Agree with Panos's comments. I also think our most important job right now is to discuss a clear scope of DOTS and work out a new charter.

Another point I want to note is, current two drafts are for two different scenarios, and they are all valuable for operators and security service providers. So, we should consider them together in the beginning to avoid the unnecessary waste.

B.R.
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Panos Kampanakis (pkampana)
发送时间: 2015年3月24日 23:11
收件人: will; [email-masked]
主题: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00

Panos