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

Robert Raszuk <> Fri, 25 September 2020 22:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B88B3A0A1C for <>; Fri, 25 Sep 2020 15:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZmUG2k9fTaXu for <>; Fri, 25 Sep 2020 15:05:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 164403A0A20 for <>; Fri, 25 Sep 2020 15:05:35 -0700 (PDT)
Received: by with SMTP id lo4so648419ejb.8 for <>; Fri, 25 Sep 2020 15:05:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r7gFI3n09Miwz6z7ZfmGZE7Q4bKHkMcTrUEujQIlUEQ=; b=a6+9lEHrkbV+vqqOuuYyC2xX81o4tOBFWUbnJ47Vb24u+bveXmmzcyEOAp6xktjm9K /OO8cOmgQPUyD8q1mZQX4UaZJhNnQs8dku/utMlkaXQYk9VkHSOwqVWa7l3u4seeHSH1 xrJljHIUJjLjKvLov7E4mS8/7QbgZpk8IZ7LGSwWW7BbcJalznzCP0Z4mNgDXh6JzP5t wwwFA9wYHNbAOMeFu1zZwtFJWqmyJDxqkoL+nzfA8cSo3hLwdJ+3V5yTJ5a0hIB+rOnR UwEJfg25dUWFGXC0VR5vP9wx3h+zr1aFStZgS2KITBv8pIJDpZ9tOFeHEPzdn0qQePhw rOig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r7gFI3n09Miwz6z7ZfmGZE7Q4bKHkMcTrUEujQIlUEQ=; b=VSgDCGnVFTo5Gn9C/7WXLW+ANvUUtA4qHuzp90l6gm2/jg2wlMEambYVowVK8WqYjJ 3rQTqLq31WkP1P5Leqt4EavTiY02zgsl33KmznmUgPUkGXQWq3yt4w34vrAdlUNWzaQ3 akP/2wZS13nq1SenYDWx5MY8d+ugqSGbr044KZ5Ioov2zNZnSapLuBRnql/Ns+b4K/px +r3dEBKEp/i/6SHw/eZ+lwKcfO8o4wYyJC+JU15tdG/ZH6Qmq3Gci0gYlc087c743L6k lP1j+uNcFOHzZSqEjKjq3gsGIsvfI6IRy5xMyFdIpKHXENM5Ogo+1skleQKJ3KU0rosq OoqQ==
X-Gm-Message-State: AOAM530PEOH6xDHRMck7RePeYpLv+qUm6rx1AkkYebXilaq6+pW/O03S 7pWseYB0PT6B7JgLNN2Z++tKrKa64U5w9AWbXgVoUg==
X-Google-Smtp-Source: ABdhPJzFEYgkJVekuqmwFOqtbd3687f477lOGo+dYeaODz7votP0xwza371Uw3ZlGXwjLUWyGAZKkPsl9qK720ViiUM=
X-Received: by 2002:a17:906:7f15:: with SMTP id d21mr4957257ejr.470.1601071534246; Fri, 25 Sep 2020 15:05:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <22341_1601052988_5F6E213C_22341_268_1_53C29892C857584299CBF5D05346208A48F82C17@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sat, 26 Sep 2020 00:05:24 +0200
Message-ID: <>
To: John Scudder <>
Cc: "" <>, "idr@ietf. org" <>, "" <>, Hares Susan <>
Content-Type: multipart/alternative; boundary="0000000000000f21ba05b02a845f"
Archived-At: <>
Subject: Re: [Idr] 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: Fri, 25 Sep 2020 22:05:38 -0000


> FS uses T,V and not T,L,V for its component types, the lengths are

That's not completely right ... number of types in NLRI include length
(called numeric_op) :) as spec defines them as 1 or 2 bytes values.

- - -

Original 5575 treated entrie NLRI as one value, allowing it to be
propagated and when locally some match was not supported it was not applied
to the data plane - but BGP still was propagating it. Here this change is
now asking for each BGP speaker involved in FS propagation that it MUST
parse all types of the NLRI and if it does not recognize any type reset the

Putting aside if this is good or bad how are we going to actually roll in
such change while keeping same capabilities ?

Say someone just upgrades the OS with FS code compliant to 5575bis and
suddenly his sessions will be going down ...

I think some of my previous comments were just based on the view ... oh yes
let's make sure we propagate valid information only .. but do we all
realize the consequences of this change ? Do we check by default if prefix
is a valid IP prefix and not part of bogons or do we need policy line to do
it for us ?

I am not saying what you proposed is bad ... but I am scared about the
consequences to now validate all types encoded as part of each FS NLRI. And
if you sent 1000 and you get 1 more with new unknown type or worse some new
draft will define new numeric_op on the existing type - and receiver will
not recognize it .. all 1000 previously advertised NLRIs are going to be
withdrawn (if sessions gets reset) ...

- - -

Also, I don’t see capability negotiation so how is the sender supposed to
know the list of component types which is supported by the receiver?

> It’s not, this is a deficiency in FS that I think the WG needs to address
in the proposed FSv2 work.

Well I think this is a deficiency of BGP that only my directly connected
(in BGP sense) peer has a chance to know my capabilities.

But putting this aside - in any multi vendor network you will often have
discrepancy among vendors on the supported features. For FS primary use
there is no loops .. you drop and mitigate DDoS when and where you can.

If not and even if you would have a map of entire BGP network in terms of
supported match and actions - what would you propose to do ? Least common
denominator ?


On Fri, Sep 25, 2020 at 9:04 PM John Scudder <> wrote:

> Hi Bruno,
> Thanks for your comments. Some replies in line.
> On Sep 25, 2020, at 12:56 PM, wrote:
> ...
> Just as a side note, “error handling according to Section 10” points us to
> RFCs 7606 and 4760, which end up telling us to reset the session if the NLRI
>  is malformed.
> [Bruno] Thanks for providing the full picture and hence the importance of
> the point.
> _*IMHO*_, RFC 7606 calls for session reset as a ‘last’  resort error
> handling behaviour.
> 8.  Guidance for Authors of BGP Specifications
> […]
> The "treat-as-withdraw" approach is generally preferred and the "session
> reset" approach is discouraged.
> <*section-8__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOnjLHVOBw$>
> Treat-as-withdraw cannot be performed when the NLRI can’t be found in the
> update, or the NLRI can’t be effectively withdrawn typically because the
> peer won’t accept it in the withdraw (e.g. and IPv4 address of 5 octets).
> Or (my reading) we feel that the received NLRI seem so wrong that what we
> read may not be what was intended to be send. IOW, there is an error in the
> syntax.
> Exactly right.
> IHMO, RFC 7606 specifies “session reset” when the MP_REACH_NLRI attribute is
> malformed or the NLRI is syntactically incorrect.
> I’m not familiar with FS, but so far, I don’t feel that an unknown
> component type in FS:
> - prevents the “treat-as-withdraw” approach.
> - matches the RFC 7606 description of a syntactically incorrect NLRI field
> <*section-5.3__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOmjo43yJQ$>
> My reading was that since the FS document carefully says “is considered
> malformed” and then references Section 10, which in turn references 7606
> and 4760, and since 7606 and 4760 both say “reset the session if it’s
> malformed” that a session reset was called for. 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.
> Also, I don’t see capability negotiation so how is the sender supposed to
> know the list of component types which is supported by the receiver?
> It’s not, this is a deficiency in FS that I think the WG needs to address
> in the proposed FSv2 work.
> Regards,
> —John