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

Robert Raszuk <robert@raszuk.net> Mon, 28 September 2020 20:43 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 D4FDF3A13E9 for <idr@ietfa.amsl.com>; Mon, 28 Sep 2020 13:43:52 -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=unavailable 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 azpO2JgPJGe7 for <idr@ietfa.amsl.com>; Mon, 28 Sep 2020 13:43:50 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 285F03A13E2 for <idr@ietf.org>; Mon, 28 Sep 2020 13:43:50 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id n13so3447976edo.10 for <idr@ietf.org>; Mon, 28 Sep 2020 13:43:50 -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=bsfuHkjcijJUCEOZ4Wfq9V6HtxjQg1JVGpiyhdR0R18=; b=XyODP2zA0864xzcjwRZz2yzG6ygP9ytwYJO76hhI9iZVp8FTvB8Iq2c1u3DrV7d3YL GYNQA/pRv3yGvOEgDgGjCJZlm+Wv1SOwjj3vLO3mLtmgviZSLavnaR86jWoHzS/tfXnT bVRqrpFxQ5UJRGYAQoBwUzIFO/q+jCF83lAywa+IO4IkNhRpCDEyEKIMEA59WK3nyScu JttSleyu9hl67PqbxPZRxA5uHFDOsegJ4tJKRTiDQrmX3W+2gOo4bQa7aKuzSVD+xoZN viMFpTb/KqsUHpzW1KJlvQGRP1+ZnUh5BngHzbEr11IpzgWuF2j9goVDL7s3HlH7dpwY e2nA==
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=bsfuHkjcijJUCEOZ4Wfq9V6HtxjQg1JVGpiyhdR0R18=; b=SDza9wuiAqnoffN5Zcb/54OmyG29mn7NQ31gl64tTJzk0CsFm+HyVLN8ZlK4a7COe2 SCh0twbELhcjHGjjrzDCN1ZeiRNqFqMw2Mf4dn7NaGDkjYOKIABsjwaXa3BlC0calXqX kYkFbFbVMzBKDnbYPR7tbg949z4wNHeF0hdfa0poaOkkIa7SvnEXQd0rgl1CSFDpwHRU ijJlch0JxQbrjA6QaNjM4Ec2BQwKDyqiNv//uNMrPw0mb07yEuATdDTbTH3zAs6eu9FC uMGqDknf0M2yxL1N5YIdIIRmMNPCpeoffyVVqNNb/Cl9M4SkF+jfAAOepBWne6AK2HdZ fzuA==
X-Gm-Message-State: AOAM533deinj5UonjBNtks4+8pdwJ2qvzeuv1kS7CGq1bQIQTmTvELgO xYxQtQ5gc9x4AexZ4IZFHRCr0NNi03iIyQOBF78nzA==
X-Google-Smtp-Source: ABdhPJwQiac+TnEGKNgYT4PR/PqFHM6fvIojJObRv1y/tB6IhdW5JlKZClGi2TyqUzExNUOPtwEv257A4TZ04r+lQ14=
X-Received: by 2002:a50:9f6f:: with SMTP id b102mr3840617edf.272.1601325828460; Mon, 28 Sep 2020 13:43:48 -0700 (PDT)
MIME-Version: 1.0
References: <303E54F6-833A-4458-B3E6-DE90E7CA121B@juniper.net> <22341_1601052988_5F6E213C_22341_268_1_53C29892C857584299CBF5D05346208A48F82C17@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <DEE76A95-339B-433C-BD46-AD0243F72FBE@juniper.net> <3366_1601300732_5F71E8FC_3366_6_3_53C29892C857584299CBF5D05346208A48F86028@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <21B4E52C-38F4-4C94-985C-8C1DF88F4A92@juniper.net> <CAMMESsxG+ASdax1USizop-1bzYELcSdvND-f3RNEJ78zDUPrng@mail.gmail.com> <A9128F3D-948E-4F22-B000-7B470AFAC219@tix.at>
In-Reply-To: <A9128F3D-948E-4F22-B000-7B470AFAC219@tix.at>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 28 Sep 2020 22:43:37 +0200
Message-ID: <CAOj+MMESP=1EtTcuptE9xdyb+g36kDiD4sH6wSLezeZX74v2vw@mail.gmail.com>
To: Christoph Loibl <c@tix.at>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, Jeffrey Haas <jhaas@pfrc.org>, Hares Susan <shares@ndzh.com>, "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002cf52005b065b950"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7dsYNisBDtv7BBMI7e6ZN5GVmRk>
Subject: Re: [Idr] [BULK] 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: Mon, 28 Sep 2020 20:43:53 -0000

All,

To me the real question is if we really should validate the content of NLRI
or just make sure that NLRI boundaries meet BGP MP_REACH definition and
treat NLRI values completely opaque to BGP (as per original RFC5575).

If NLRI is really malformed resulting in MP_REACH attribute being malformed
I do not see that much harm in session reset.

But if we dive into each atomic type parsing of the NLRI value itself at
each BGP speaker talking SAFI 133/134 I think this is going to be a mess.

Best,
R.



On Mon, Sep 28, 2020 at 9:41 PM Christoph Loibl <c@tix.at> wrote:

> Hi,
>
> 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
> c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at
>
>
>
> On 28.09.2020, at 21:16, Alvaro Retana <aretana.ietf@gmail.com> 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:
> https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/
>
> Jeff: if you get a chance, please chime in.
>
> Thanks!
>
> Alvaro.
>
> On September 28, 2020 at 2:16:38 PM, John Scudder (
> jgs=40juniper.net@dmarc.ietf.org) 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 <https://tools.ietf.org/html/rfc7606>] and [RFC4760 <https://tools.ietf.org/html/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)**.*
>
>
>