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

[Robert Raszuk <[e-mail]>]

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

> 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
>
> --
> Christoph Loibl
> [e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at
>
>