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

"McPherson, Danny" <dmcpherson@verisign.com> Thu, 24 September 2020 11:14 UTC

Return-Path: <dmcpherson@verisign.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 D6AC63A0972; Thu, 24 Sep 2020 04:14:04 -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=verisign.com
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 b0GmPIjmrmEc; Thu, 24 Sep 2020 04:14:03 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1613A096C; Thu, 24 Sep 2020 04:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=23816; q=dns/txt; s=VRSN; t=1600946044; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=od0ZjuGpPTBdLMBbKRpeI5FC/+v1bgyv8gR359pus5s=; b=eXV12D2UfU6cO5CyEsM9PZCwbjj1TfTQvS2CpFqG8rIeBljhrFeOBQhI LicU4xqeanR13PD1zjs2lbTIO3bfKKIj0vF9O2vXLSgokYJysBCQeZEeA gCYYnLxru0/BIkuUzfjhzEycv46REwurqAj6e+kmpl/5HPVDOQlvjJ5JV sPxq5po5ospKOEPSPS12qQIvpJeNk3DyInYMh1k6XwESwB7DVSbe3htJo T7MiHrzojCbFXdYXpZbUwB8BkDHv6AxjL4yehNBMExl5bztA9A9J+DxSU XgxfWheAFnlu6A8DwM6LVxLgrQ6n1O7bb4Zwf8qbYZEqq32QXaa0GWDaH Q==;
IronPort-SDR: jWJLXAQe992zLEOUY2TyN4+PGuKTqLfkTHzyN6HwhT1k+0Q9G8Ieb48TBfXGfmzbPfF8zOiWAs 4/jc4bHD6TiKxvFTLr0hZFgSvd8xQKalnXx1AU8dabXCrRNdSOQR+upFNDV+jPD1uQuLkU3yX6 xf4bh2NnCkKVvNDWCgcc/lvdBoI2/SSbtm0LnEAqjSp7+Ydaa3pmw32lfoAWQpbZEGj11Nq8wY xyuWmiInINTM+l7dqgRDbgQTqRgadUuCPcFjlNM3X7+UBbuOFBRkAmO3N/xeF3Dw38wp6/eS79 r74=
X-IronPort-AV: E=Sophos;i="5.77,297,1596513600"; d="scan'208,217";a="3021402"
IronPort-PHdr: =?us-ascii?q?9a23=3AnanC+x++YqeEif9uRHKM819IXTAuvvDOBiVQ1K?= =?us-ascii?q?B+0OgRIJqq85mqBkHD//Il1AaPAdyErasUwLGH++C4ACpcuMjH6ChDOLV3FD?= =?us-ascii?q?Y9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQk?= =?us-ascii?q?a3OgV6PPn6FZDPhMqrye+y54fTYwJVjzahfL9+Nhq7oRjTu8UMnIdvKak9xx?= =?us-ascii?q?XNr3BVf+ha2X5kKUickhrh58q85oJv/zhVt/k868NOTKL2crgiQ7dFFjomKW?= =?us-ascii?q?c15MPqtRnHUwSC42YXX3sVnBRVHQXL9Qn2UZjtvCT0sOp9wzSaMtbtTb8oQz?= =?us-ascii?q?Si7rxkRwHuhSwaKjM26mDXish3jKJGvBKsogF0zoDIbI2JMvd1Y7jQds0GS2?= =?us-ascii?q?VfQslRVjRBAoKiYIsJE+oBJvtTo43kq1cTsReyGQygCeXywTFKm3D2x7U33e?= =?us-ascii?q?Q/Hw/bwAwuEdEAsHrWo9rpO6gfSvq6wLXNzTjZc/9axTXw5Y7VeR4hu/GMWr?= =?us-ascii?q?dwfNLfxUcoCwzLlFWQppL/PzOO0eQNtXCX5PduW+21jW4nrQFwrjayzcorl4?= =?us-ascii?q?bJg54aykjE9Spn2oY1Ptq4SEhgbN66DpRQrSCaN5B3QsMtRWFkojo1yroDuZ?= =?us-ascii?q?OieiUB1ZsoyQLFZfOdb4iI/gzsVPyXITpgh39oerKxiwqs/ES+1ODxVMm63U?= =?us-ascii?q?tKoCRFj9XCtnAD2h/N5sWFSvVw/Ums1SqL2g3Q6OxKL105mKrZJpI8wLM+lp?= =?us-ascii?q?weulnNEC/xnUX5lq6WdkM89+iu9evmbanmppuGOI50lA7+KL4ildajAeggLg?= =?us-ascii?q?cOXnOb9vi71LH54UL5R7BKguU3kqbHrJDaK94XpqmjAw9a1Iso9hWxDy++3d?= =?us-ascii?q?gFgXULNkxJdR2GgoTzJl3DIO70Ae2hj1msljpg2urIMaf7AprXK3jOiLLhfb?= =?us-ascii?q?Fg5EFC0Acz1tVf545MCrEGPfLzRlf9tNzGAR89NAy52+XpBtN82I8DWW2BGq?= =?us-ascii?q?CXP6LOvVOV/O4vPfWDZIgPuDblMfQq/ePhgWUnmV8HZqmp24EbZ2y/HvRjO0?= =?us-ascii?q?mZYHzsjckdEWoSowYyUPbmhEONXDNSfXq+QqIx6i8hBI64DYrPXoWtj6aA3C?= =?us-ascii?q?e/EJ1WfGdGClWUHHj1coWLR+8MaCKMLc97iTwEUr6hRpQ/1R6wrg/6yqFnLu?= =?us-ascii?q?vb+i0er57syN915+jLmREo6TN0F9id032KT2xshGwIXSE53Lxlrkx70FiPy6?= =?us-ascii?q?l4jOJEFdxd/P5JXQI6OoTdz+x+Edz9RgXBftKRQla8XtqmGS0xTs42w9IWYU?= =?us-ascii?q?Z9FM6igwvB3yq3Bb8VlqSLC4Iu8q7G2Xj+Odp9wW7c1KY9l1kmXtdPNWq+i6?= =?us-ascii?q?5+6gfTHZXEk0SHmKa2e6QQxinN9H2MzWCWpkFXTBZwUbnZXXAYfkbWr9X56V?= =?us-ascii?q?3YQ7CzDrQnNARBxNWCKqtXcNLog0tJRPb5NNvCZGKxnn+6BQyUybOUcIrqZ2?= =?us-ascii?q?Id0T3GCEgEiQ8T52iJNRMlCyenvm3fDTxuGUjzbEPr9Ol0sGm7QVMszwGWc0?= =?us-ascii?q?1h0KK49QMPhfOGRfMTwqsIuCY/pDVoElaxxtPWBMeapwZ4ZqVcb88y7VdH2G?= =?us-ascii?q?/btwFyJZ2gL7t5i14fbQt3o03u2w9wCoVansggtGkqwxZqKaKEzFNBcCuV0o?= =?us-ascii?q?zrN73LK2nz8wqjZLTK2gKW7NHD0acV6e8krE3j9CWuF0AmuyFs+8VUwz2V+s?= =?us-ascii?q?OZIhAVVMe7d00P9xVgvLbcJmER7oXSxDckZaWxuSfC1sgyA+0N1Bu6fsxeP6?= =?us-ascii?q?XCHwj3RZ5JT/OyIfAnzgD6JikPO/pfoettZ5ur?=
X-IPAS-Result: =?us-ascii?q?A2HlBAAPf2xf/xmY9gpgHQEBAQEJARIBBQUBgg8CgSGBd?= =?us-ascii?q?4E0hDyUWGaGFJAqgSwXJgsBAQEBAQEBAQEIARMPDQQBAQKESQIXghclOQUNA?= =?us-ascii?q?gMBAQsBAQEFAQEBAQEGAwEBAQKGRQyCNykBcz0JPQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEEAggFNhkFNxIBHwYjPRkQAgEIDjEDA?= =?us-ascii?q?gICHxEUEQIEDgWDJgGBfk0DPbYZgTKEOwEDAoQDDYE8aIE4AYZagQOFa4FCP?= =?us-ascii?q?oERJxyCTT6BfhxCAQECAYFCAVeCWTOCLQSQB4JvATyGfoMjiFaQPEYLCoJni?= =?us-ascii?q?HuLaGqFCx+DRG+cWp1ogmqSNQIEAgQFAhWBQSuBenB6AYI+CUcZDY18gkuBS?= =?us-ascii?q?YUUhUJ0AgEKKgIGAQkBAQMJkBoBAQ?=
Received: from ILG1WNEX02.vcorp.ad.vrsn.com (10.246.152.26) by ILG1WNEX01.vcorp.ad.vrsn.com (10.246.152.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 24 Sep 2020 07:14:00 -0400
Received: from ILG1WNEX02.vcorp.ad.vrsn.com ([fe80::6829:4296:d4e1:9be5]) by ILG1WNEX02.vcorp.ad.vrsn.com ([fe80::6829:4296:d4e1:9be5%7]) with mapi id 15.01.1979.003; Thu, 24 Sep 2020 07:14:00 -0400
From: "McPherson, Danny" <dmcpherson@verisign.com>
To: Christoph Loibl <c@tix.at>
CC: Alvaro Retana <aretana.ietf@gmail.com>, John Scudder <jgs@juniper.net>, "idr@ietf.org" <idr@ietf.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Hares Susan" <shares@ndzh.com>, "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>
Thread-Topic: [EXTERNAL] Re: [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
Thread-Index: AQHWklfwALzjle5jzEmWzBCf9b/GIKl3ouv6
Date: Thu, 24 Sep 2020 11:14:00 +0000
Message-ID: <D962ABA4-D805-4DC9-96C7-46D31E830E7F@verisign.com>
References: <303E54F6-833A-4458-B3E6-DE90E7CA121B@juniper.net> <CAMMESsy8uZb9GLgh12LD9SvYSxZeMczy52TDM30w88Fbx5+2Nw@mail.gmail.com>, <C0952E92-34D8-4E05-A6A5-5ED0158BE751@tix.at>
In-Reply-To: <C0952E92-34D8-4E05-A6A5-5ED0158BE751@tix.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_D962ABA4D8054DC996C746D31E830E7Fverisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RRrKPhhrTiUHSBTnV2PMZRGsxvA>
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: Thu, 24 Sep 2020 11:14:05 -0000

I agree as well.

-danny

On Sep 24, 2020, at 5:49 AM, Christoph Loibl <c@tix.at> wrote:

 Hi,

I fully agree with Alvaro (to both statements).

John: If you want me to edit this phrase into the document I think there won't be any objections (while I believe it is not needed). How shall we continue (should I do the change or is this something RFC-editors are doing now?).

Cheers Christoph

--
Christoph Loibl
c@tix.at<mailto:c@tix.at> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at<http://secure-web.cisco.com/1cEXU7BTURyxeBLQHzaDtEia25k9TBqLCI0A2F7OPWhuNKjct1OsCPcm5PqMdliJoTDy8AAR6G8xznPT3I8ck0Nr2bpXNyJQPmk07LFh7VTpfAg9S0lvg5ADmnYDQ8xfrufPIoWWiC9MRl8uw5d1T9vxW1v_6BDWM97rj6DRCUPnkaK7GONrGhS-4ymzuYRB5ACDMs6O1a8JPUI_lNbGu2S8072yh6v0LrXK6SOyydpue1S9TlMWRDttWPiWM4UA5ouS2KunioqtviV8JQ4qgMw/http%3A%2F%2Fwww.nextlayer.at>



On 23.09.2020, at 23:37, Alvaro Retana <aretana.ietf@gmail.com<mailto: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<mailto: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://secure-web.cisco.com/1TLZgZGpDFqtnI2mJNLYf9XTaI2ut4-JFs012vxvkt1Jdiojqh8GRIf3cA3Pl1yKunmMj25sws1kaiwVyD3R42ozGNOdk568BE9H6IqHqoOO1g_CvOBp59Vd2pLRaO7a72R7HlyY6DqJL-GPPntoaTdpail5rDyuNoXHgt1yLonyLO3RpcLPHZ6zjOUK9n4cRIWDLCUZUd5sTU-kndI7z1wbRBy5LLjIu6j2xJdhY-5-A5noGLynYSZoq8BGWLXiMVp8T6xI3Dfx9eUqY-6lBlg/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-rfc5575bis-26%23section-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://secure-web.cisco.com/1TLZgZGpDFqtnI2mJNLYf9XTaI2ut4-JFs012vxvkt1Jdiojqh8GRIf3cA3Pl1yKunmMj25sws1kaiwVyD3R42ozGNOdk568BE9H6IqHqoOO1g_CvOBp59Vd2pLRaO7a72R7HlyY6DqJL-GPPntoaTdpail5rDyuNoXHgt1yLonyLO3RpcLPHZ6zjOUK9n4cRIWDLCUZUd5sTU-kndI7z1wbRBy5LLjIu6j2xJdhY-5-A5noGLynYSZoq8BGWLXiMVp8T6xI3Dfx9eUqY-6lBlg/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-rfc5575bis-26%23section-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.