Subject: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification

From: Christoph Loibl <[email-masked]>
Date: Tue, 23 Aug 2016 14:08:56 +0200

Hi,

We submitted a new draft and are happy to receive feedback:

Since interoperability is key to an flowspec Internet deployment we tried to clarify the ambiguous parts of the flowspec RFC 5575 in order to allow a consistent implementation by equipment vendors.

Title: draft-loibl-bacher-idr-flowspec-clarification

https://datatracker.ietf.org/doc/draft-loibl-bacher-idr-flowspec-clarification/

The reason for this draft submission is, that we recently performed a rather large flowspec interop test (the main goal was to evaluate possible inter-AS flowspec scenarios in a multi vendor environment) and discovered many bugs and vendor interop problems that we want to solve.

Unfortunately we currently cannot share all our findings in a test report, because we hit some serious bugs that have (under circumstances) potential to remotely melt down entire networks and are working with the vendors to get bugs fixed.

Christoph

--
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Aug 2016 14:54:00 +0200

Dear Christoph and Martin,

Thank you very much for coming up with this document. Indeed it may help
avoid some misinterpretation the intention of RFC5575 by implementors.

I agree with all comments provided perhaps excluding those proposed in
section 5.

The overall intention of validation was to make sure that originator of
given unicast prefix (and here it means at any point of time) is authorized
to inject a filter for it.

There are few cases of course to consider ... and really it also depends
how strong an ISP implements say origin validation or other forms of BGP
Sec.

If I can trust that all paths for a given prefix are valid it should be
sufficient to only validate flow spec NLRI against any path present in the
BGP table for it matching say the left most value of AS_PATH attribute or
originator are the same in unicast and flow spec routes.

While I realize that 5575 says "best-match" while we are at clarifying it
maybe we should discuss this more.

Similarly many operators use flow-spec only within their own ASes and by
default first thing they do is disable validation all together. If we want
to promote use of flow spec inter-as maybe we should also account that
local use case and by spec relax the validation all together for it.

Another debate is if this should be enforced only at the EBGP boundary or
also at IBGP ...

Bottom line we want to prevent ACL churn on the router in the events of
best path changes.

To summarize if you ever will ask for WG acceptance I am in full support of
this work.

Cheers,
Robert.

On Tue, Aug 23, 2016 at 2:08 PM, Christoph Loibl <[email-masked]> wrote:

> Since interoperability is key to an flowspec Internet deployment we tried
> to clarify the ambiguous parts of the flowspec RFC 5575 in order to allow a
> consistent implementation by equipment vendors.
>
> The reason for this draft submission is, that we recently performed a
> rather large flowspec interop test (the main goal was to evaluate possible
> inter-AS flowspec scenarios in a multi vendor environment) and discovered
> many bugs and vendor interop problems that we want to solve.
>
> Unfortunately we currently cannot share all our findings in a test report,
> because we hit some serious bugs that have (under circumstances) potential
> to remotely melt down entire networks and are working with the vendors to
> get bugs fixed.
>
> Christoph
>
> --
> Christoph Loibl
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 23 Aug 2016 14:13:27 +0000

Christoph,

	One could also us flow-spec as a mechanism to disseminate flow-spec "filters" via an SDN controller. I am my co-authors specified changes to the validation procedure such that the unicast route is not required for a router to accept and program the slow-spec path/filter.  When reading through the draft it seems to assume that flow-spec is only used as originally intended this is not the case. IMO this is a good piece of work and it should broaden the scope to include how flow-spec can be used from an SDN Controller.. There are other challenges with the draft as originally written

- Order of Traffic Filtering Rules
- More specific unicast routes
- AS value position in the AS-Path

Here is the draft..

https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-03 

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Christoph Loibl
Sent: Tuesday, August 23, 2016 8:09 AM
To: [email-masked]
Subject: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification

Hi,

Christoph

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Aug 2016 16:28:14 +0200

Hey Jim,

Indeed I alluded to your and others contributions to generalize flowspec
when I mentioned the intra-domain case. Even putting aside SDN use cases
there still can be valid DDoS filters injected centrally - hence my
comment.

For your point however I (*still*) think it would be much easier and
simpler to put all SDN and related work into Flowspec_v2 and run in in
different SAFI. Yourself, Sue and bunch of other people are actively
helping with. That v2 spec may have completely different validation rules
or not have them at all assuming validation happens on controller only.

IMHO mixing both quite separate use cases will not help each other at all
deployment wise - even if both deployment models are very valid. The reason
being that what knobs work for one flowspec NLRIs for the other could turn
to be harmful. So if we do not separate them and someone would like to use
both it will get pretty ugly soon.

Cheers,
R.

On Tue, Aug 23, 2016 at 4:13 PM, UTTARO, JAMES <[email-masked]> wrote:

> Christoph,
>
>         One could also us flow-spec as a mechanism to disseminate
> flow-spec "filters" via an SDN controller. I am my co-authors specified
> changes to the validation procedure such that the unicast route is not
> required for a router to accept and program the slow-spec path/filter.
> When reading through the draft it seems to assume that flow-spec is only
> used as originally intended this is not the case. IMO this is a good piece
> of work and it should broaden the scope to include how flow-spec can be
> used from an SDN Controller.. There are other challenges with the draft as
> originally written
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 23 Aug 2016 14:29:35 +0000

Robert,

                Makes sense..

Thanks,
                Jim Uttaro

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, August 23, 2016 10:28 AM
To: UTTARO, JAMES <[email-masked]>
Cc: Christoph Loibl <[email-masked]>; [email-masked]
Subject: Re: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification

Hey Jim,

Indeed I alluded to your and others contributions to generalize flowspec when I mentioned the intra-domain case. Even putting aside SDN use cases there still can be valid DDoS filters injected centrally - hence my comment.

For your point however I (*still*) think it would be much easier and simpler to put all SDN and related work into Flowspec_v2 and run in in different SAFI. Yourself, Sue and bunch of other people are actively helping with. That v2 spec may have completely different validation rules or not have them at all assuming validation happens on controller only.

IMHO mixing both quite separate use cases will not help each other at all deployment wise - even if both deployment models are very valid. The reason being that what knobs work for one flowspec NLRIs for the other could turn to be harmful. So if we do not separate them and someone would like to use both it will get pretty ugly soon.

Cheers,
R.

On Tue, Aug 23, 2016 at 4:13 PM, UTTARO, JAMES <[email-masked]<mailto:[email-masked]>> wrote:
Christoph,

Here is the draft..

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christoph Loibl
Sent: Tuesday, August 23, 2016 8:09 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification

Hi,

Christoph

--
Christoph Loibl
[email-masked]<mailto:[email-masked]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Christoph Loibl <[email-masked]>
Date: Wed, 24 Aug 2016 12:11:42 +0200

Dear Robert and James,

Thank you for your comments and support on our document.

I completely understand that the verification described in the RFC 5575 is has certain limitations. Most current installations (at least that I know of) are intra-AS _only_ and verification is completely disabled in that case. I think that a relaxed / different validation than defined in RFC 5575 makes perfectly sense in many ways.

However, the primary intention of our draft is to clarify aspects that are somehow ambiguous in RFC 5575. We tried to introduce only minimal changes to the RFC (wherever possible) and fill gaps wherever clear definitions were missing to allow a consistent implementation.

Section 5 (revalidation) actually does not really introduce any different behaviour to RFC 5575 it is basically a more verbose rewrite. The reason why we still put into the draft is the following:

During DDoS mitigations it is perfectly feasible that announcements of prefixes change. Traffic steering/engineering may require to isolate traffic via more-specific routes on certain AS-borders, IPv4 routes may simply change during that process. For example: In our lab we saw routers announcing the flow-spec NLRI before announcing the actual IPv4 prefix during such route changes. So the flow-spec verification failed. However, just 10ms later the IPv4 prefix was announced to that particular neighbour (the flow-spec NLRI was still not taken into account, because no revalidation took place). If there is no revalidation of the flow-spec NLRI we end up with a completely unpredictable verification that is based on the arrival time of the two different NLRI announcements (IPv4 vs Flowspec) (some kind of race condition).

We may still decide to have a different verification mechanism in place (as proposed by both of you) but the key here is, that it should always result in a consistent/predictable view over the entire participating networks. In my opinion the time of arrival of announcements should not have any impact on the verification state of the rules.

Cheers,
Christoph

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Aug 2016 13:30:59 +0200

Hi,

Well indeed the validation procedure or rather the decision may get quite
complex.

Just as an example - assume you are transit AS and you are peering towards
two transit ASes.

One of your peers sent you a flowspec route and the other did not. So my
point was that even if best path changes the other AS will still get the
attack as such will be rather part of the ACL towards the former AS.

If we have unicast best path changes often and flow-spec NLRI are not
withdrawn I would rather think more optimal is to keep the filter in the
ACL if it was ever valid till it get's withdrawn.

And for sure you or someone else may come with different scenario - say
where you are switching best path and origin AS is different as the end
victim is dual homed and has private AS. But even here maybe keeping the
filter in place may help to save the victim.

Lastly ... some folks may have already very heavy ACLs. Adding and removing
the entries frequently especially on distributed switching platforms may
constitute a problem.

But in any case I was just trying to shed a bit of different perspective on
it - that's all.

Your draft is at least to me a very good quality work !

Cheers,
R.

On Wed, Aug 24, 2016 at 12:11 PM, Christoph Loibl <[email-masked]> wrote:

> I completely understand that the verification described in the RFC 5575 is
> has certain limitations. Most current installations (at least that I know
> of) are intra-AS _only_ and verification is completely disabled in that
> case. I think that a relaxed / different validation than defined in RFC
> 5575 makes perfectly sense in many ways.
>
> However, the primary intention of our draft is to clarify aspects that are
> somehow ambiguous in RFC 5575. We tried to introduce only minimal changes
> to the RFC (wherever possible) and fill gaps wherever clear definitions
> were missing to allow a consistent implementation.
>
> Section 5 (revalidation) actually does not really introduce any different
> behaviour to RFC 5575 it is basically a more verbose rewrite. The reason
> why we still put into the draft is the following:
>
> During DDoS mitigations it is perfectly feasible that announcements of
> prefixes change. Traffic steering/engineering may require to isolate
> traffic via more-specific routes on certain AS-borders, IPv4 routes may
> simply change during that process. For example: In our lab we saw routers
> announcing the flow-spec NLRI before announcing the actual IPv4 prefix
> during such route changes. So the flow-spec verification failed. However,
> just 10ms later the IPv4 prefix was announced to that particular neighbour
> (the flow-spec NLRI was still not taken into account, because no
> revalidation took place). If there is no revalidation of the flow-spec NLRI
> we end up with a completely unpredictable verification that is based on the
> arrival time of the two different NLRI announcements (IPv4 vs Flowspec)
> (some kind of race condition).
>
> We may still decide to have a different verification mechanism in place
> (as proposed by both of you) but the key here is, that it should always
> result in a consistent/predictable view over the entire participating
> networks. In my opinion the time of arrival of announcements should not
> have any impact on the verification state of the rules.
>
> Cheers,
> Christoph
>
> --
> Christoph Loibl