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

Christoph Loibl <c@tix.at> Wed, 18 December 2019 07:11 UTC

Return-Path: <c@tix.at>
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 4C29C1208D1; Tue, 17 Dec 2019 23:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Gp0e5hb1TNc8; Tue, 17 Dec 2019 23:11:48 -0800 (PST)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A572F1200E9; Tue, 17 Dec 2019 23:11:47 -0800 (PST)
Received: from 80-110-104-164.cgn.dynamic.surfer.at ([80.110.104.164] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1ihTKd-00035c-0Y; Wed, 18 Dec 2019 08:01:18 +0100
From: Christoph Loibl <c@tix.at>
Message-Id: <44C0D224-1C71-4B88-B3D9-A12F417AD3F0@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A2EA93AC-87D6-4B57-AC27-0730DB07AE91"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Wed, 18 Dec 2019 08:11:37 +0100
In-Reply-To: <20191217220936.GE4858@pfrc.org>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, "idr@ietf. org" <idr@ietf.org>
To: Jeffrey Haas <jhaas@pfrc.org>
References: <CAMMESsxHXUB_jQk7E9FkeNef2C7DDcbiEvnROFdbEjAVtMqcFA@mail.gmail.com> <F9C8F51F-FB7C-4530-93EA-BF188D007C98@tix.at> <CAMMESsxDYo2JPQ=tw3m9EQrDwyGCjWMem_oiH4WZy4FHRBOFtQ@mail.gmail.com> <20191217220936.GE4858@pfrc.org>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5dDmAcHpeiXXhy4oRytQJkAoig8>
Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 -> Updated Version -18 and Flowspec v6
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 07:11:50 -0000

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 <jhaas@pfrc.org> 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. 

Cheers
Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at