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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Mon, 28 September 2020 23:23 UTC

Return-Path: <jheitz@cisco.com>
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 DE1D73A146C; Mon, 28 Sep 2020 16:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=b2y9Umv8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TE4hV3/E
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 5fjTxkt9FM6M; Mon, 28 Sep 2020 16:23:20 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B623A1456; Mon, 28 Sep 2020 16:23:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36460; q=dns/txt; s=iport; t=1601335400; x=1602545000; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7QYyR07NrrHWXWtZ5emoM7d7IrrlxvVf/fCq0m8EMrg=; b=b2y9Umv8jHiVpJza9n6I0myU6KFWGvkkYkDR5n88iP7y4ifjJtcwLPaO ng9ZnF3Mo2S1+48ZGgpQK1DDJ8JXEZHti8ijGq1ebK+Iysi5yf7Xdzdtg eImkhRib9ew2TpPvDZcx0dDY8ZJjmC7mn8LHPvde+bmFN1Q616jSv1BxN I=;
IronPort-PHdr: =?us-ascii?q?9a23=3AXtTeYBCIrMs3Vil9Nqi9UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00g3TVJ7J9vECjefK4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS9z3fE/PoTu04CJBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmBQD3bnJf/5NdJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCD4EjLyMuB3BZLyyEPYNGA419gQKJDI5ogUKBEQNVCwEBAQ0?= =?us-ascii?q?BASMKAgQBAYRLAheCGgIlOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAxI?= =?us-ascii?q?LBgQGEwEBNwEPAgEIEQQBASEBBgMCAgIfERQJCAIEAQ0FCBqDBYF+TQMuAQ6?= =?us-ascii?q?rKAKBOYhhdn8zgwEBAQWFBA0LghAJgTiCcoNpgQOBPoQSG4FBP4ERQ4FPSTU?= =?us-ascii?q?+gX4cQgEBAgGBQxsrCQiCWTOCLY9zIQODIocAi36QBThRCoJniHuGVYV+hSu?= =?us-ascii?q?DDYl+hTuOTZMJgXeIcoJqkjkCBAIEBQIOAQEFgWsjKoEtcBU7gjUBATIJRxc?= =?us-ascii?q?CDY4fgiiBSYUUhUJ0AjUCBgEJAQEDCXyLLi2CFwEB?=
X-IronPort-AV: E=Sophos;i="5.77,315,1596499200"; d="scan'208,217";a="567013207"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Sep 2020 23:23:19 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 08SNNJ5K007537 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2020 23:23:19 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 28 Sep 2020 18:23:19 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 28 Sep 2020 19:23:18 -0400
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 28 Sep 2020 18:23:18 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OS/LYk5ZgMtNigkOOi1rS4BMEXDD1aPEKyVsz0n6x1QWsYqSaMO3JoAsx5nhGoi6v6QVICNjuudIlOuNbsXSYWY9lllKN5nlIkp0QZF8nz1f+UL879haz08hy27+dvXPVTrANPuqTFvqCKCl8DI4A/Ryht9tH5L9jh8VHhBNjBkVffE18CJzWBiW5LW5D6W22kpxRt+Gpvic4KN1LX5o0qMbiDj3i3jXKMJ9umpbSnooLoqVtuL5PwXFYOSmdrssmCUU7R6jh/PHAuyutVA+yDxD0918U7sCAWu+l64K6u+oHDpo8Z5fv3Ee+vvRroQQVm7QpyFB1MYkaKJechMULg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7QYyR07NrrHWXWtZ5emoM7d7IrrlxvVf/fCq0m8EMrg=; b=RU4IikzGLU+Bt/7UpZKDQMpfYmH8REKOGKy9jHjHavDuhWckVo1vzKnlwdRNDGMII4vJfIOb5qiBpGrKD2H6LGI8pUMZo8BvQjQJfT+E33QW54EI/fzpt+xLuu18h8Kej4x6A6Snhlp4wCySBsd9khLJiW2FgMp8xFLfSuremCvzCSY6EHtrgk1qWduxx7noT4QhNHiMjUgsExwCefKXq/shK87/LkkCQ+vvOknkaN0oWcuWQa/isD10xjVzsTM9jZCbl46/P0zX74SzaAkHpraE9WOhQQvS3QxNRm7i9mmiRYS3p+yIFK3icthN1KasIizUKAPV1ih91WFWTxFHuw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7QYyR07NrrHWXWtZ5emoM7d7IrrlxvVf/fCq0m8EMrg=; b=TE4hV3/ENyoniTgKgiyAJxf3Nd2xwa55bFW+zKLwp4Qo+qI25bCbcsb+0dsWMPQj+LaQPtfV18mt6eud2oGMITAbe+b40FpoN8ongWZ7bLOy6BlsKHc1CCJhRfI7FiJcvB5TcK/aZV4Y+PkcTIPPNRkRCzJExJ5k3OSgaQkoo7w=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BY5PR11MB3880.namprd11.prod.outlook.com (2603:10b6:a03:184::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Mon, 28 Sep 2020 23:23:16 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::718c:ac63:d72e:f3c9]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::718c:ac63:d72e:f3c9%4]) with mapi id 15.20.3412.029; Mon, 28 Sep 2020 23:23:16 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, Christoph Loibl <c@tix.at>
CC: "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Hares Susan <shares@ndzh.com>
Thread-Topic: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
Thread-Index: AQHWlc+R8L0ZDtl3sUmjek4pM5QcAal+hHWAgAARbeA=
Date: Mon, 28 Sep 2020 23:23:16 +0000
Message-ID: <BYAPR11MB32079E5730B9B170C1ADF7E1C0350@BYAPR11MB3207.namprd11.prod.outlook.com>
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> <CAOj+MMESP=1EtTcuptE9xdyb+g36kDiD4sH6wSLezeZX74v2vw@mail.gmail.com>
In-Reply-To: <CAOj+MMESP=1EtTcuptE9xdyb+g36kDiD4sH6wSLezeZX74v2vw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:510d:11bd:4bb2:4566]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cf015657-c76b-45de-ea1e-08d864057aa6
x-ms-traffictypediagnostic: BY5PR11MB3880:
x-microsoft-antispam-prvs: <BY5PR11MB38803F1D243E8A8E50164C4EC0350@BY5PR11MB3880.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FJ6c6bs1+TSy4uPEmhTQUn3h+53rAPIIDRM2YGPOxasAxOj1kEReQTuzWEZrR0L2HUZF0omCMpnOjc4WzcfIQyAAgQy9ZIf680uzpA4nA4LNv8PodxnXuvu4HOhF6oA554vgdS/BgD3YOs77VhHYaSzhkh2C40wq05tF/azCaL7ULc+nb5bBvJyMcnmTN995hpr5baIzrEOlCK6y7LgIjQWr2TTMDXz8CBqsl/mjc0Fi6kW5H3aCkGYMBjh14ekGSlGK1WAcEy0sC/uDmJx5bvcMbhHBRrRcKHNBBko+vPPTQtl7vag2BORuioPFt93lss/b8I3QttfvAQ/1WHMtqKZd9NnmShDaInogUpyDhcDrT0VVd1kouj3xZIRu2HmdEhufHmisEjFhPDPJwv1X/YGMtVgo+tZJyCrrirWHucOA54LKoaIZLwz4viiPMp6GpyotT03o6lysrRvy/g2LAU4blfyl9FwM7DIHiEcPivDvv5qqZYhDVUU0SQU0jrgx
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(39860400002)(366004)(376002)(396003)(76116006)(66446008)(4326008)(966005)(86362001)(2906002)(316002)(110136005)(8936002)(478600001)(33656002)(8676002)(54906003)(66556008)(64756008)(66946007)(66476007)(5660300002)(6506007)(53546011)(186003)(7696005)(166002)(83380400001)(55016002)(9686003)(52536014)(83080400001)(71200400001)(781001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: GSa7hUraOYlWCWMbl57dAV05zd4LtFe/DO6XFq0dwzaSEtrqu3n98GPttoq75Tdy3hlgMNIVASxN9FSWqEcLRwavsG0Zmg7thmx1RL800AKopW8iMnZZIacSfoA1At96RURedFOy3JMofsdwz2zHyUzZJGAPntzPu4LOkJ22odNz+ziyFponLZln+o2xJh12o+1Pub223afsgqq566XsR9/ilwh9GJgraV2xRfX0StIObSLJ9YuQi1xBbcXrHAKd36VKEQkotS87zajybMQJLWKMa5uyzld+gyDrkk4j3K4VHmYTk8/D0gp0aMHEjmhKNaJz1ims/Il0nTV/YEWlw8iRhxD8eB0ssku4bKDo3koog/Nzhz9AWT10PNejq61ICj8usUVquQ4b+8DdE+AwD+94hoA1pc7BOF8hXlO0S0P8RoMShDLhpB8t8VDHJen/75NLbrU2OqBNlutbTTwbw6Or3dEQvn0/qtorsSpo2M7VzmV4AzCMpiBu0uzUxOKV9I2x7ip146jXa3lNxu9mitmaPtp0zlUFNlD14n+EieEQb6LBrvKIbHI0OJuXjLIVONg7xSBkWfqO+s3Nb3B6ezgLTIXA0U8HS0U7K+kV0eZz9gnsUyg8RKdxTVV95eIXorQxlX/T16ywmYqiXUX30LeeXOO3cIU3Mz/mMB5yj0NCA+GG35y8sc5kp1xm/G9aT+nwF5TMTlwbIl14dWo/dQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB32079E5730B9B170C1ADF7E1C0350BYAPR11MB3207namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cf015657-c76b-45de-ea1e-08d864057aa6
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2020 23:23:16.6119 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oJHuPElzTr0qMwFY7GXBvBHMphZBEUjiDVAfkAZSYrza/GEMFKjoneuI3qqCAsaAYIQZZjdzviZQD0T20oEkVw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3880
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/tr0NEpCrJyAmTpGcznUaEkJb1Xk>
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 23:23:23 -0000

Also to consider that in BGP, there are several examples of NLRI
where the NLRI key is not the whole NLRI, starting with RFC 3107,
where the label is not part of the key.

A speaker that receives an update with an unknown NLRI does not
know if that unknown NLRI servers to withdraw a (seemingly)
different unknown NLRI, if the parts that are different are not
key material.

Therefore, a BGP speaker must always be able to completely
parse and understand received NLRI.

Flowspec does not AFAIK have any such NLRI... yet.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Monday, September 28, 2020 1:44 PM
To: Christoph Loibl <c@tix.at>
Cc: idr@ietf. org <idr@ietf.org>; draft-ietf-idr-rfc5575bis@ietf.org; John Scudder <jgs=40juniper.net@dmarc.ietf.org>; bruno.decraene@orange.com; Hares Susan <shares@ndzh.com>
Subject: Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

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<mailto: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<mailto: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<mailto: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<mailto: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).