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

["Takeshi Takahashi" <[e-mail]>]

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 route. 

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 ; [e-mail] 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00




On 03/24/2015 06:39 AM, Eric Burger 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.

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:[e-mail] wrote:

Hi,

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

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.
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 ; [e-mail]
Cc: [e-mail]
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00

Hi,

On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" mailto:[e-mail]
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




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

   

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




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