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

Jeffrey Haas <> Wed, 18 December 2019 12:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F86312004C; Wed, 18 Dec 2019 04:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R5z8qlSwhJhm; Wed, 18 Dec 2019 04:08:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A2707120919; Wed, 18 Dec 2019 04:08:06 -0800 (PST)
Received: by (Postfix, from userid 1001) id 125431E2F6; Wed, 18 Dec 2019 07:12:35 -0500 (EST)
Date: Wed, 18 Dec 2019 07:12:35 -0500
From: Jeffrey Haas <>
To: Christoph Loibl <>
Cc: Alvaro Retana <>,,, "idr@ietf. org" <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 12:08:08 -0000

On Wed, Dec 18, 2019 at 08:11:37AM +0100, Christoph Loibl wrote:
> Hi Jeffrey, Alvaro!
> I only pick out this single issue from the complete list, because I do not 100% agree with this statement:
> > 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.
> > 
> > There are two options available to us, IMO:
> > 1. Flowspec v2, which we stalled out until 5575bis was done.
> > 2. We decide that for 5575-bis that all future extensions MUST be encoded
> > with a TLV format (length being mandatory).  And perhaps even protect a
> > compliant extension with a capability.  This is a major change, but perhaps
> > provides an upgrade path without waiting on v2.
> >> 
> >> 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.
> 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. 

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.

-- Jeff