Re: draft-ietf-idr-flowspec-l2vpn-12

Hi Robert,

First, I want to thank you for your technical feedback which has
contributed significantly to the improvement of this draft.

On Mon, Nov 18, 2019 at 9:10 AM Robert Raszuk <[email protected]> wrote:
>
> Dear WG,
>
> ...
>
> So far flowspec 5575 and 5575bis focused on solving one real problem
> - mitigation of DDoS attacks which we are all experiencing daily with
> different strength.
>
> With that SAFI 133 and 134 have consistently defined types to
> describe L3 packets match criteria.
>
> I do not understand why now we are to take SAFI 134 and load 13 new
> types on it to define completely irrelevant to FlowSpec original goal
> L2 packet match criteria.

The way I view this is from the point inside a box where you have
parsed some headers and want to defend against traffic whose source
might be more distributed or less distributed.  Abusive traffic might
be identifiable by a nested L2 header. And, while it is true that if
you are inside a classic IP router, the outer L2 header of received
traffic should have been discarded, most boxes today are switches and
useful outer L2 header information could be available.

If you are worried about the number of component types, I now think
they should be in a separate registry anyway. (Until Flowspec v2, they
can't be added to the existing/proposed IPv4/IPv6 registries anyway.)

> Yes implementation may use AFI 25 and SAFI 134 to distinguish it
> from AFI 1 or 2 and SAFI 134, but it is introducing pure mess and
> architecturally it is just ugly.

I think beauty and ugliness are in the eye of the beholder.
Personally, I do not see an L2 header bit as more ugly or more
beautiful than an L3 or L4 or L5 header bit.

> Moreover the draft in question while defining the protocol extension
> fails to identify even a single valid use case for it. L2 VPNs are
> usually private and I am not sure about others but I never seen a
> L2VPN DDoS other then BPDUs on LAN's spanning tree. I am sure using
> BGP to mitigate those type of attacks is an innovative one.

As above, one use case is to match nested L2 addresses as in
draft-ietf-idr-nvo3-flowspec. Another is to match an outer L2 in the
case of a box that is not always acting as a classic L3 router.

> So clearly this has nothing to do with DDoS mitigation, and this is
> pure BGP policy push extension.

I disagree.

> The draft also skips over fundamental reason why we have SAFI 134 in
> the first place. When we run L3VPNs customer may detect a DDoS and
> signal with SAFI 133 to a PE about it then PE carries it within SAFI
> 134 across all PEs (modulo RTC) where filters may be installed in
> proper VPNs or pushed again with SAFI 133 to remote CEs.
>
> Here in L2VPN what protocol will be used to signal DDoS between PE &
> CE ? Email ?

I'm not sure why there is much difference in this aspect. Although not
presently in the draft, as I mentioned verbally during my presentation
and as I also had in a line on one slide, AFI=6/SAFI=133 seems right for L2
non-VPN flowspec, for example between customer and PE.

>
> ...
>
> I would like to reiterate Acee's question - Do we really need to put
> into BGP all possible packet formats to transport filters with it
> around ?

This draft does not put all possible packet formats into BGP. Seems to
me that L2 Ethernet headers are very common in current networks and I
think it is reasonable to be able to handle them with flowspec filter
and action types.

> Even if some will say - sure - please separate this via new
> extension and new name leaving original FlowSpec to at least have
> the chance to do what it intended to do in the first place.

As far as I can see, the specification of new AFI/SAFI pairs,
regardless of what "name" they use, does not in any way interfere with
the use of "original FlowSpec" and its AFI/SAFI pairs.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email protected]

> Kind regards,
> Robert

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr