Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Christoph Loibl <> Mon, 28 September 2020 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 133073A1393; Mon, 28 Sep 2020 12:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 s7gTzyqihZ6N; Mon, 28 Sep 2020 12:41:11 -0700 (PDT)
Received: from ( [IPv6:2001:858:58::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EEC73A1390; Mon, 28 Sep 2020 12:41:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=upCKRDW0MbhKH0B+f66aF7FvCqPP6L8boiCCLWmc8KY=; b=JC71jACtYfShiiAkEWdYlI7w3o FySjVUMhFv6N+G1Ww5sqdxtz4FV8ToFLUtkdIhQcg4/6wvDLf0saNUcI+/FzaSbi11mvchHLw4pAp hqWbSCJUFIP6JwZafucwEkrZi41kgWp4AVJi3cIkm/Wf0JdijAcztpmCCsKR4IqrA+GSlnwdzwK1K KxfTd0VCYX8aOl5WNoiW93jERHubBe/7woS4F6dThSYTBhVvWhd2OuqAiVukDnjaNpSqVYH2KizEN d6/ypVr5+u/JG4LoXrPoHfxu6IydQATbyfZNgUiDccD/7Pp7axs0Cooz/oXfF8EZlR5ZH0G+dWEdL ASJOjVlQ==;
Received: from ([] helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1kMz1D-0008Zk-4p; Mon, 28 Sep 2020 21:41:03 +0200
From: Christoph Loibl <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_33463C5A-3413-449E-82D0-42596ADE1640"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 28 Sep 2020 21:41:01 +0200
In-Reply-To: <>
Cc: "" <>, John Scudder <>, Jeffrey Haas <>, Hares Susan <>, "idr@ietf. org" <>, "" <>
To: Alvaro Retana <>
References: <> <22341_1601052988_5F6E213C_22341_268_1_53C29892C857584299CBF5D05346208A48F82C17@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <3366_1601300732_5F71E8FC_3366_6_3_53C29892C857584299CBF5D05346208A48F86028@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <>
X-Mailer: Apple Mail (2.3608.
X-Scanned-By: primary on (; Mon, 28 Sep 2020 21:41:03 +0200
Archived-At: <>
Subject: Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
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: Mon, 28 Sep 2020 19:41:15 -0000


I do not really want to repeat the whole discussion here (seems that we are going in circles) if not needed. I think that we agreed that if the NLRI is malformed the only option is to reset (+send notification) the session (even if we consider rfc7606). And from draft-rfc5575bis it is clear that we are talking about a malformed NLRI:

   A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10 is performed.

-> I think that adding the small term that John suggested is sufficient.

Cheers Christoph

Christoph Loibl | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 |

> On 28.09.2020, at 21:16, Alvaro Retana <> wrote:
> [Explicitly adding Jeff to the To list.]
> Hi!
> During my AD review there was a discussion on the list about this point, and whether we could avoid resetting the session.  Jeff presented some examples and, I think, made a very convincing case of why we really can’t: even if we can look at the length, we would still be guessing.
> I think this is one of the messages: <> 
> Jeff: if you get a chance, please chime in.
> Thanks!
> Alvaro.
> On September 28, 2020 at 2:16:38 PM, John Scudder ( <>) wrote:
>>> I think that is the right thing, too: FS uses T,V and not T,L,V for its component types, the lengths are implicit. So, if my parser encounters an unknown type code it is impossible for me to know how to skip over that type code. At that point, parsing breaks down.
>>> [Bruno] I had in mind the higher level of hierarchy:
>>>    The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
>>>    one or more 2-tuples of the form <length, NLRI value>.  It consists
>>>    of a 1- or 2-octet length field followed by a variable-length NLRI
>>>    value.  The length is expressed in octets.
>>>                      +-------------------------------+
>>>                      |    length (0xnn or 0xfnnn)    |
>>>                      +-------------------------------+
>>>                      |    NLRI value   (variable)    |
>>>                      +-------------------------------+
>>>                 Figure 1: Flow Specification NLRI for IPv4
>>> At this level, assuming that the NLRI value is found semantically incorrect, it seems to me that one could:
>>> -          Skip this NLRI (thanks to the ‘length’ field) and continue with the next NLRI
>>> -          Read the ‘NLRI value’ as an opaque data, and treat this NLRI as withdraw. (In the context of the discussion, this NLRI would never had been accepted, so ‘treat-as-withdraw’  could even be replaced with ‘ignore’. But I’m _not_ calling for this).
>>> Hence it seems to me that treat-as-withdraw is technically possible.
>> Fair enough. It’s a little unfortunate that the draft contains this ambiguity; in retrospect it would have been better to be explicit about the error-handling strategy chosen rather than simply referencing RFC 7606. Whether or not we want to respin the draft in order to clarify it, is a question for the WG. If we were to make a change, it could potentially be the addition of this sentence, in Section 10:
>>    Error handling according to [RFC7606 <>] and [RFC4760 <>] applies to this
>>    specification. Notably, an NLRI that is found to be semantically
>>    incorrect (for example due to an unknown component type) MUST be 
>>    handled using the “treat-as-withdraw” strategy (which in this case,
>>    it must be noted, works out to be the same as skipping over the NLRI).