Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 -> Updated Version -18 and Flowspec v6

Alvaro Retana <> Wed, 18 December 2019 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 318C61209BD; Wed, 18 Dec 2019 08:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NF4tit_wVDvs; Wed, 18 Dec 2019 08:24:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 604FA1209F9; Wed, 18 Dec 2019 08:24:04 -0800 (PST)
Received: by with SMTP id i16so2143437edr.5; Wed, 18 Dec 2019 08:24:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=qW7SEToyVXLOGzSRZHQ7Cab5TKqD3Pbp80Eov55X5r8=; b=fjM9GpTIecFlYslHDNLTbTHFnLehSP/VDP5IvCb56m3iV0S343uuU9SQj0FXULsuBi mNEihSZYKhCCKeZ4d5xcEC/7+AwPqzsPRuoLEeFulq0Pj6msnjc1AC+kmrBU0zKLI4/i wD0pe7uIT/5P2Vs+iZQIf6PXMqJUg1YCzbmQiyisv2yma1HUssWyQa6xKlzMvRtxPLZX 0ZT/K8tOvTnONH/vWRi1qzDFqI/KqzFY2sNw/3nwgrGZZlC2F9wDUJx/lrfaNJHA6Huy 1X5AtIWpPec7rQ4CwExvsxWJhz3e4GYLN4mzXWzn9i0hDsOcWrd8BxVEbyNDdwYnNr2s FiBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=qW7SEToyVXLOGzSRZHQ7Cab5TKqD3Pbp80Eov55X5r8=; b=YMExI/9EvxkZhX7gkvUzQuc6ISUs8+KwcsR1R8tgWIM8YBCVBkMNIq0UVNhUX3Ixd4 EskmCO7byvWttsw/mCj2RovDjhmG6dqRaX6BewxZITfHXPI4x6+uiQZt9Qg6czE/Pgqj jKBMmmYyUodZoj6lWsjNA+oHNqF1d+jUzKKhGx143JoQGYUc32kVBCA7Oy7KHPZR8wHD Avq+s6G1runQBYk1zoV9yad3x8P4QYFOAPzyd+kSeOUi6OOR6E5T2YOVMIUnZgh58NgI Ct9D6lLRw1Dda/w+Jr0P3MgsXfEKHb6d5Eg/My1T/mi06gOKrC9a0A70t01Nvb684bu5 fVJA==
X-Gm-Message-State: APjAAAWHlsbElPgExYhQ8gXVUv1lQrI0WbViBsRy3yaY8bhmQBrDHfRG scRyQV42OViBzWZZ/eCnt/ZWe3VLi6uKnSwZpT8=
X-Google-Smtp-Source: APXvYqxpnY0zO7s3Lea1QktiIysLFqNGRvDEeTj4qKZbLSJGvE8rbFHT8gAWr8n9t6bD7gcxw2flfCL72/7V0jE/mfA=
X-Received: by 2002:a05:6402:1777:: with SMTP id da23mr3350233edb.292.1576685826918; Wed, 18 Dec 2019 08:17:06 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 18 Dec 2019 08:17:05 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Date: Wed, 18 Dec 2019 08:17:05 -0800
Message-ID: <>
To: Jeffrey Haas <>, Christoph Loibl <>
Cc:, "idr@ietf. org" <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 -> Updated Version -18 and Flowspec v6
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Dec 2019 16:24:13 -0000

On December 18, 2019 at 7:08:06 AM, Jeffrey Haas wrote:



As I read the responses it sounded to me as if we were all going in
the same direction: discard if an unknown component is found.  But
reading more into it, I think we're talking about different cases...

> On Wed, Dec 18, 2019 at 08:11:37AM +0100, Christoph Loibl wrote:
> > > On 17.12.2019, at 23:09, Jeffrey Haas wrote:
> > >
> > > > If an unknown Flow Specification component exists, then the entire
> > > > NLRI cannot be "successfully parsed"...which results in not being able
> > > > to use treat-as-withdraw. The text above leaves us with AFI/SAFI
> > > > disable, which is not extension-friendly.
> > >
> > > This is exactly my largest concern about flowspec right now. There is no
> > > safe way to extend the spec at this point.
> > > > NEW (suggestion)>
> > > > An advertisement containing an unknown Flow Specification component
> > > > should be discarded as specified in Section 5.4 of [RFC7606].
> > >
> > > You can't parse it, therefore it's malformed.

Jeff: I interpreted this response as agreeing that if the NLRI can't
be parsed then it should be discarded (even maybe buying the Typed
NLRI argument).  It sounds like we're agreeing.  Is that true?

> > In case of an unknown flowspec component the parser can run until decoding
> > the component type (always the first byte of the component). When it reads
> > a unknown type-value it can easily jump over the remaining bytes of the
> > entire NLRI (the length of the the complete NLRI is encoded in the first
> > bytes of the NLRI) without needing to understand what is in there, because
> > it should treat it as withdraw. I do not see the problem. It is supposed to
> > “ignore” the entire NLRI not only a single component of it.

Christoph: It seems to me that we're getting to the same behavior: I
call it "discard", you call it "treat it as withdraw...“ignore”".
While discarding, ignoring and treat-as-withdraw are different things,
the effect seems to be the same: we won't use the NLRI.  We can find
the right words...  Do you also think we're going in the same

> Sigh. Into example-land we go:
> You receive the following byte-stream as NLRI in a single BGP PDU:
> NLRI-1, length X components 1,2,3
> NLRI-2, length Y components 1,2,3,?,?,?
> NLRI-3, length Z components 1,2,3
> In the case of NLRI-1,3 if you had received these individually, you'd know
> they were correct because the implementation understands them.
> In NLRI-2, you don't know what some of the components are starting at first ?.
> The _best_ you can do in these circumstances is walk the list of NLRI by
> length and see if you can arrive at NLRI boundaries and have a valid BGP
> Update PDU.
> However, you also don't know if you actually have an NLRI-3 or not. It
> might actually be a random byte stream that just happens to parse as an NLRI
> and accidentally lands on a packet boundary. NLRI-2 may be corrupt and the
> length mis-calculated.
> We have seen these bugs before, even in simple RFC 4271 PDUs.

In theory, if the length is set correctly, and the unknown components
are "well behaved" (i.e. they are actually correct, the receiver just
doesn't understand them), then it seems to me that we could safely
just discard NLRI-2.  In theory...

I think that we are talking about two different actions when bumping
into an unknown component: discarding an NLRI in the list (e.g. just
NLRI-2 above), vs discarding the whole advertisement (i.e. all NLRIs
to protect against potential bugs).

Going back to rfc7606/§3, it talks about parsing the "entire NLRI
field" (not just a single entry).  But the Typed NLRI behavior
(rfc7606/§5.4) talks about discarding "routes with unrecognized NLRI
types" (not the entire advertisement).

Personal opinion:  If we (WG) don't buy into the Typed NLRI-like
argument, then we deal with the "entire NLRI field", but we're also
stuck with AFI/SAFI disable (or session reset).  If we buy into the
Typed NLRI-like argument, then it seems like we have the option to
specify either discard behavior.