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

Robert Raszuk <robert@raszuk.net> Mon, 18 November 2019 14:10 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D66C812092C for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 06:10:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 83HgNz2qIYDI for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 06:10:38 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 E2F2B1200F5 for <idr@ietf.org>; Mon, 18 Nov 2019 06:10:37 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id 205so14501950qkk.1 for <idr@ietf.org>; Mon, 18 Nov 2019 06:10:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=ogSAuYFQb2/9g0JGlMGIpRuX9OeCE1oRDeHN+9w5sB8=; b=N6S51W2ZJcM+DCEkJnFn/MTuRyINVlxkxM/ieRVymN7JXpw7Kyak/Xvjg6znLrAfXV wW8lWNl2x9cNweR2qkOZMI2sVBx2OoidgMPUU086rCo3oaTFZHGQLfIPn+xfXd1GDjtg m/EQApytbugRbAcfo2K8CC8At2Urei5Iu0cBhmlCEfiNAd/XRgl/mxRySE+/UymifYEB fYJs0PUgavfIr/VwzX/GNJJR73U6Q/Nou31IFswjZlW27EAlvimrgz0ZW8GGzYgJPDpE Wsrt4KertWqclc6CRs1ONc0wISeFQCHd1vEP3wEpXUBhp6Gn1i/NqEVCaERTUr7KJWlm puAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ogSAuYFQb2/9g0JGlMGIpRuX9OeCE1oRDeHN+9w5sB8=; b=JvoR0DYofQq8VDkZJaWtbqBnuS1GeltsV3PsLNyh4ollU5vzmt7LPCwXjZHx8tnZCL moW8Q+JS3p5q5JXE/n8LN4QjdzBqG4XfUvfnoR6r0SzwGlLnwYVO/slGy+gBXHcDk5mn vbK+NwuG72eaBBI+Gw2SqhbqKzKmkXrxtoabxqLch7j8NeQK311dVMrn/3iL3kLJhK9f HX8dMiZpu9ShLrm12h6rmRM3kp5mlKBRJa3opxoULxaHwwFDn4acHFl1HZFTXkuVWNAd lSivPeuxg7FafvFuqN1cIGQ8IR0ZKJ3OZhxmRycKFWp8HzD/Yn/P33MHCIEpT0mOy4YO UxiA==
X-Gm-Message-State: APjAAAVf+lm328GDzoQ3fX6wE1Let6iAvkB2bvVRMHFWd9hMBsCXh0JJ Fnt3W1BlLygTGn79R3QU2f0hzVpz/fIxz/vMWRRAa4yU
X-Google-Smtp-Source: APXvYqxYxJVfFtNVtezFcBU8QJOqa2Bw9C8BHpc2govw2OZ9vqL1ipBbLjsEyVEpSnPtCoxmE1QvqSdeN4HLauT77zY=
X-Received: by 2002:a37:6087:: with SMTP id u129mr24189548qkb.219.1574086236574; Mon, 18 Nov 2019 06:10:36 -0800 (PST)
MIME-Version: 1.0
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 18 Nov 2019 15:10:25 +0100
Message-ID: <CAOj+MMF3fMABM7_Nk15738OqrDEMUoQUyDOOqkUbUVk=iYkgBw@mail.gmail.com>
To: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fa308905979f8267"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ze3vM2K0bWU2E-oaCsTTbQLmcto>
Subject: [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: Mon, 18 Nov 2019 14:10:40 -0000

Dear WG,

I would like to highlight the change to IANA registry which is
being discussed here.

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.

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.

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.

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

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 ?

Is BGP really now not only Link State transport,  but also configuration
push and ACL push protocol ? Where is this going ? Just because we have a
TCP session there does it make it good idea to load so much new extensions
on top of it ? Oh I forgot the drafts which BGP as an SDN signalling
protocol :).

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 ?

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.

Kind regards,