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

With no hat on...

On Tue, Mar 24, 2015 at 9:20 AM, Andrew Mortensen <amortensen@arbor.net>
wrote:

>
> > On Mar 24, 2015, at 7:39 AM, Eric Burger <eburger@standardstrack.com>
> 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

> Agreed.
>
> andrew
>
>
>
>
> >
> >> On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi <
> takeshi_takahashi@nict.go.jp> 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 ; dots@ietf.org
> >> Cc: tt2@rc5.so-net.ne.jp
> >> Subject: Re: [Dots] FW: Prior discussion about
> draft-fu-ipfix-network-security-00
> >>
> >> Hi,
> >>
> >> On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
> >> 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
> >> Dots@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dots
> >> _______________________________________________
> >> Dots mailing list
> >> Dots@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dots
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>

-- 

Best regards,
Kathleen