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

Robert Raszuk <robert@raszuk.net> Wed, 23 September 2020 22:33 UTC

Return-Path: <robert@raszuk.net>
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 7DC4A3A1545 for <idr@ietfa.amsl.com>; Wed, 23 Sep 2020 15:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 BAzj9ZPUqMAc for <idr@ietfa.amsl.com>; Wed, 23 Sep 2020 15:32:59 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3559F3A153F for <idr@ietf.org>; Wed, 23 Sep 2020 15:32:59 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id z23so1710348ejr.13 for <idr@ietf.org>; Wed, 23 Sep 2020 15:32:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8U7xXFlcqFcf2Mlh+d7mPce8puPtlC4SBsOD4aaB4RQ=; b=F32gm9m90ygrlQk5vbm22jyr7noIirXwh9Sno9hQFxTfGzhVWvtN5kCjqJcx2sFInR 0PgWtvMJxG95hq+6VeytCPzC0RDcr9f3gX/jwQthX4RHs7MJS/UamOWKfDHXVc/yzLC/ qJkBvXjlgyJ3hEUK8KqOYijKktGHhDtdBDFT1Uwi8tyIOhOoDsMs0ILvPu84GqC51+oa aIu5OAoHaYrINxTWN5lPV4qMfmDSpftmCjgPqdwKkw4iVL+lZ8II1tFmgB7FJPTt4DzH K2MVBD26gDh8B7M5v0qaH3M+bZmjIiizoU470TJAddDn7R+gSf7/lXWHZDeoZ/BpayoK 53Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8U7xXFlcqFcf2Mlh+d7mPce8puPtlC4SBsOD4aaB4RQ=; b=peMR0nrpaHLL5GzqaHxcdZUxXtnBj1ZocsulWxhyF0yA6JAinzPyWi0JeeV3z81xzs i+hf3wDpOdNSx0Q2YI6lbWbZxr/wTICYZv8CTlzJbKnDRm+Y8gaMt2O10aRrqku93Ylw Ii8A+o1sWncTkOB1eTXkQOoyJohIwMcyk98Zs5/rcojNBGTEXdqtVyvZKeIpycm51tD3 X109+7sqsnw+hHp183t1Tm5FqXA122+n9mkxgc3WUA8B1BmSJs/sJCWgvcszjBfcFF4e i4iIwQCUFrsCQE00UU5B6fhZVwkuZwTzAhvqo0vnMoe4Jekj/hT/z0ChCScbS/3Pzs3S weQA==
X-Gm-Message-State: AOAM531wiLikmUlLw1rUYXbFZkGIXZZsLW9Gxi12FGjVd82gTyUbUIDM cJRSMuBgEqucJ81x2Sb9GI5nh9vKaOmsXxZ7kkh+tw==
X-Google-Smtp-Source: ABdhPJx0tQ3qhFYipAC0AYqSOv3ZpyfS8at6Lj6VZpYFK5Qt1tkZIXTt6JfHd6EbGWHP+xpp05QFYUewcXedmwqoktE=
X-Received: by 2002:a17:906:4941:: with SMTP id f1mr251813ejt.417.1600900377454; Wed, 23 Sep 2020 15:32:57 -0700 (PDT)
MIME-Version: 1.0
References: <303E54F6-833A-4458-B3E6-DE90E7CA121B@juniper.net> <CAMMESsy8uZb9GLgh12LD9SvYSxZeMczy52TDM30w88Fbx5+2Nw@mail.gmail.com> <CAOj+MMExdcyUP+eLdqPYRSYzg_9wVRRtSTGfQ4comC_pYteT7w@mail.gmail.com>
In-Reply-To: <CAOj+MMExdcyUP+eLdqPYRSYzg_9wVRRtSTGfQ4comC_pYteT7w@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 24 Sep 2020 00:32:47 +0200
Message-ID: <CAOj+MMHJ2n2Du1fpiz8TQuBi-F7SROrFDvRk-r4aqQqotS7osQ@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, John Scudder <jgs@juniper.net>, Christoph Loibl <c@tix.at>, Susan Hares <shares@ndzh.com>
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000051bd4505b002aa85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/T6xy66R5n685eV5SVed7seSL2J8>
Subject: Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
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, 23 Sep 2020 22:33:02 -0000

Btw some pointers to the archives of the discussions on this very point
below:

https://github.com/stoffi92/rfc5575bis/issues/20

https://github.com/stoffi92/rfc5575bis/issues/93

Thx and all credit to Christoph for making is so open and transparent like
no one has ever done it before when editing and reviewing an ietf
document.

Kind regards,
R.


On Thu, Sep 24, 2020 at 12:22 AM Robert Raszuk <robert@raszuk.net> wrote:

> Hi Alvaro & John
>
> That change originated based on your below review comments:
>
> [major] "...for the purposes of BGP route propagation, this prefix should
> still be transmitted since BGP route distribution is independent on NLRI
> semantics." I think this is a vulnerability: a (large) set of meaningless
> Flow Specifications may be injected in the routing system...
>
> [major] Also, propagating these unknown components may result in a router
> down the line, which understands them, reacting. While the reaction
> shouldn't result in reset adjacencies, it may result in inconsistent
> forwarding or other unexpected outcomes...
>
> [major] This treatment of unknown extensions is in conflict with the text
> in §11. See my comments there.
>
>
> - - -
>
>
> It seems clear we have few point of view here to consider:
>
>
> a) Yes John is right that just because my RRs do not recognize the NLRI
> encoding should I block myself for propagating it ... well today it is
> dropped in all other AFI/SAFIs so why should flowspec be any different ?
>
>
> b) Alvaro's review was (I believe) targeting more inter-as propagation
> cases and we discussed this and decided it is better to be safe than sorry
> and removed that text.
>
>
> c) We are talking here about BGP NLRI ... not some opaque attribute. If
> you allow "garbage" to be sent within NLRI - which as we all know is a BGP
> db key to store information - I think we are opening a much bigger security
> hole as our imagination can reach.
>
>
> To summarize at the end of the day I support current text.
>
>
> Thx,
>
> Robert (as co-author of this change).
>
>
>
>
>
>
>
> On Wed, Sep 23, 2020 at 11:37 PM Alvaro Retana <aretana.ietf@gmail.com>
> wrote:
>
>> John:
>>
>> Hi!
>>
>> Personal opinion:  I believe that the “specified here” part (meaning this
>> document) is already covering the unknown case.  However, I have no
>> objections to adding the phrase in.
>>
>>
>> Thanks!
>>
>> Alvaro.
>>
>> On September 23, 2020 at 5:14:50 PM, John Scudder (jgs@juniper.net)
>> wrote:
>>
>> Hi All,
>>
>> I’m a little concerned about a change I failed to notice earlier in
>> 5575bis. Version 17 had this paragraph in Section 4.2:
>>
>>    All combinations of component types within a single NLRI are allowed,
>>    even if the combination makes no sense from a semantical perspective.
>>    *If a given component type within a prefix in unknown, the prefix in*
>>    *question cannot be used for traffic filtering* purposes by the
>>    receiver.  Since a Flow Specification has the semantics of a logical
>>    AND of all components, if a component is FALSE, by definition it
>>    cannot be applied.  However, for the purposes of BGP route
>>    propagation, this prefix should still be transmitted since BGP route
>>    distribution is independent on NLRI semantics.
>>
>>
>> Version 18 removed the paragraph. I believe it was removed because of
>> good and reasonable concerns about the “prefix should still be transmitted”
>> part. But, it appears we threw out the baby with the bathwater: the final
>> version of the draft has nothing that corresponds to the underlined part.
>> It is underspecified with respect to what should be done with unknown
>> component types. The closest it comes is this paragraph in Section 4.2 of
>> version 26:
>>
>>    A NLRI value not encoded as specified specified here is considered
>>    malformed and error handling according to Section 10 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.
>>
>>
>> But I think this falls well short of being either clear or unambiguous,
>> because what does “as specified here” mean exactly?
>>
>> I’d like to open a discussion of whether the WG agrees that this is a bug
>> and if so, whether it’s concerning enough to request a last-minute patch to
>> the document, which is currently with the RFC Editor, so it’s almost an
>> RFC. I think the least intrusive fix would be to insert the clause
>> “including an NLRI that contains an unknown component type”, as in:
>>
>>    A NLRI value not encoded as specified here,
>>
>>    including an NLRI that contains an unknown component type,
>>
>>    is considered
>>    malformed and error handling according to Section 10 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.
>>
>>
>> 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.
>>
>> Until we get a chance to discuss this, I’ve sent a note to the RFC Editor
>> asking them to hold publication.
>>
>> Thanks,
>>
>> —John
>>
>> P.S.: The version 26 text also has a proofreading error, “specified
>> specified”. But I assume the RFC Editor would fix that anyway.
>>
>>