Re: [Idr] draft-ietf-idr-flowspec-l2vpn-12

Donald Eastlake <d3e3e3@gmail.com> Wed, 18 December 2019 05:21 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833CE120892 for <idr@ietfa.amsl.com>; Tue, 17 Dec 2019 21:21:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNYnmA1-pmOR for <idr@ietfa.amsl.com>; Tue, 17 Dec 2019 21:21:08 -0800 (PST)
Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33D01200A1 for <idr@ietf.org>; Tue, 17 Dec 2019 21:21:07 -0800 (PST)
Received: by mail-io1-xd44.google.com with SMTP id x1so646241iop.7 for <idr@ietf.org>; Tue, 17 Dec 2019 21:21:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8H8XCU332Uvw2rpkzuD9DBrqb6b5i378i7x/1bUCDlQ=; b=pMA4TB2Prl1AstD6+9vHGLuz+5nI7HAR9DBGVV7+6emZawPPSOmHARQnK8XuIEWvRR 4khgwyqPYYbaGbPdzI/y4nIlqiONhFZDUYQmi9gS2xGxefX+nU6GXoOIlVGEA6YxkHKy LT55vR4B4L+4TpDwYiSR+5eW394dDVwpVTnM023l2ZFO0yhKAaF++bY6Sn6fV+MCOvfl I8wzs23hGTqAFJFL51eTL5uMFydlAbDTZ8djeyhwC+bUKwDlcozJ2cqnKbKOG2Ao2npV FpeWxdXbYTrC9K3AUkns7doXHgi17A53q/YG9RerUAIRqtVg25rAqJtMLDwSINN6KcCO prKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8H8XCU332Uvw2rpkzuD9DBrqb6b5i378i7x/1bUCDlQ=; b=Lxpzn8y97w1SndWp0cFUzbSNHWoZ/pUQCrGfRiRL+JHW3VcbWkA/YNY/sVkpsb3JAl Wqb1VDXYZn0UaeQapyY+wA7MAeWskyCrTkOCEL2RNPkIcQ3i0jVj5VOmal69XwFXE36h C+TZRYrFLzNutp43MBntJDaJWneWILbVwd938Fwhn0dGcgBZjkEo2qURzy2xfTALyNsX zSQ401N0T1EWQTovS2Lw7xkX1WndTOHG+G0RPlGvFZUET1zF1z5f7NJSFKIzAfX4yd5j K209aj38rF/N+PcAbCItLX2VEzLGY0+bsHP951eZglHpL7VWRbWQa8PVpFmnsxJV8Gly gWCw==
X-Gm-Message-State: APjAAAVMPZsrMNxpJQ5bMI2/gLojV1YdMp7h6u8G+FyL2Ll/GYEt3H1F RM/xDMjRlReFeDxKt5Wdv6WP2RKqvaWnExaEFWI=
X-Google-Smtp-Source: APXvYqz6DRt9MVKuFrxqNO2tz0HTsGMGWelFYY+rQcbDCbM6Mly3I5imPAknuO9m3PxixHWm090xSN3i/EsMtoVaecE=
X-Received: by 2002:a6b:fb19:: with SMTP id h25mr315770iog.40.1576646466962; Tue, 17 Dec 2019 21:21:06 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMF3fMABM7_Nk15738OqrDEMUoQUyDOOqkUbUVk=iYkgBw@mail.gmail.com>
In-Reply-To: <CAOj+MMF3fMABM7_Nk15738OqrDEMUoQUyDOOqkUbUVk=iYkgBw@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 18 Dec 2019 00:20:55 -0500
Message-ID: <CAF4+nEEwzbHXxnQ-QyBRP1RWEFdYXvhju2dNHBkFfa11PZVUxA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/vblCMk1DbrlJqkl-fakMnNZXMVs>
Subject: Re: [Idr] draft-ietf-idr-flowspec-l2vpn-12
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2019 05:21:09 -0000

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 <robert@raszuk.net>; 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
 d3e3e3@gmail.com

> Kind regards,
> Robert