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

John Scudder <jgs@juniper.net> Mon, 28 September 2020 18:16 UTC

Return-Path: <jgs@juniper.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 7DF063A1338; Mon, 28 Sep 2020 11:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.196
X-Spam-Level:
X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, 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_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=Xzpzo48A; dkim=pass (1024-bit key) header.d=juniper.net header.b=HBhgkM3S
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 MRFo5xRfaTaI; Mon, 28 Sep 2020 11:16:10 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 D9B193A133A; Mon, 28 Sep 2020 11:16:09 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08SID4qZ024971; Mon, 28 Sep 2020 11:16:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=fH59Qn8gvLYpFjO6s+P3Jv6xIL2Jm2GhiAdz9pljHJg=; b=Xzpzo48AtnsKi7Ue2cgPYqj0TKXN4SGrKLYB92Lhye2W03pcqNC83xWZHnvl+U9HSQAS 65V0RsGm51pHo66EhpbIYg3pYaklKBNh5tE0DOJKjesp2WqYnFaEBN+iV2G66+RJhiGd /soE5BDdWVqi9KQ4ApeydTbdMQo2RXBNLlHD7z7Zv7gbRqPLwR3+NIdyOSBR6tdBv5Q+ O+G8RUQKPb6DucoIwjSFsGc2bNBnERjC4GP6RR3KzlbFwEpPZTEwRkJbRZIfVy/mImyL zm7IVxtLyb+NSVDOpdgb/KV6xKXF34kqiTbLrs2sMXsTkJyzczIC08v9s/Rbl5rmowIq QA==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2050.outbound.protection.outlook.com [104.47.37.50]) by mx0b-00273201.pphosted.com with ESMTP id 33t4ryjwr3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Sep 2020 11:16:08 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h/4/0vKcbnhlQl/Su/PVUvMB2KJhe9eDZrfbSIqS+2riKa/5iqmHteBBXeQYEvFcmSC1grU3t9ZJVGIfrKjxDdx0TUhQWwAQH/VsgZsdWW+GaRPKJI/KZ585M5ClvhNAmcTVaDWFirAFfmKFI8ZWPrV22grvwerlAr26Jr2NYME3Ry6cTBQ7xLkMr7DOkXZGp0FH9uFf7JlTTIlOsJYmAs3gYDAhku/Si9v4t+SuQfE9VFPf0H3yw61MME9vMQUBQArEpxr5QX1Vff+VkbuK0Ez2KJ1rxgaJxnX1A+tJiROzB3xENxjkt2oCk3LM1zqpqAbnNCTzzDxd56LCt9OL/w==
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=fH59Qn8gvLYpFjO6s+P3Jv6xIL2Jm2GhiAdz9pljHJg=; b=jel5cZiTio5JzbS4BvsgWCkIj2AU30qZEcSoSll0Xc3+xhkXlU8iQDAUHOqK5QaLYpR/WdxvhFUjePllocGIMaL/8Tj1y/RC9UihpfywfPvSL4uFRZ7f6YrwvjuIvHntpinn2IjmW71UAyTTPoSDf6QNGpKOBKBp6OBHIMrha/YMu9CVqwxPvQmnwx91jaYbzpHO3b7vTHy3/X6hH40cH7jHuYc+RwErF7RxO5urpeQa4Q4EblGG87+Mkjfg/S86MEy0i9BxAKN42bIGaewijMOtjqbPxokwEIuLRnv4gLqS4besxnV44bKrY/fWxtYSgbI/c724zv/j6U2sI5u6qw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fH59Qn8gvLYpFjO6s+P3Jv6xIL2Jm2GhiAdz9pljHJg=; b=HBhgkM3S4Jxvlrb6rt6EypkPvBHmGLu8BYfMMZ/SX2luEBZcRZ9U5JmY510xbR2GT6MRSrsOVB3ae9Cq/y+nF4XJc35fx7vmyPNDnr7zctBsFHL4J5Tcwnt5uKvwOUbhtztDc/S3LKxBfgxXbjV8lgzdy9Ml/i9pGvWNK0DECm4=
Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BLAPR05MB7475.namprd05.prod.outlook.com (2603:10b6:208:29a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.11; Mon, 28 Sep 2020 18:16:06 +0000
Received: from BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::e542:8237:ac48:ef5c]) by BL0PR05MB5076.namprd05.prod.outlook.com ([fe80::e542:8237:ac48:ef5c%7]) with mapi id 15.20.3433.031; Mon, 28 Sep 2020 18:16:06 +0000
From: John Scudder <jgs@juniper.net>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>
CC: "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>, Hares Susan <shares@ndzh.com>
Thread-Topic: Bug in draft-ietf-idr-rfc5575bis, worth fixing?
Thread-Index: AQHWke6RJ/7GqRzh40q9dKt5uqwGhKl5lcCAgAAjvQCABE7wEIAAWpGA
Date: Mon, 28 Sep 2020 18:16:06 +0000
Message-ID: <21B4E52C-38F4-4C94-985C-8C1DF88F4A92@juniper.net>
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>
In-Reply-To: <3366_1601300732_5F71E8FC_3366_6_3_53C29892C857584299CBF5D05346208A48F86028@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.1)
authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [162.225.191.192]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 7ddec013-5abd-4a80-d91d-08d863da9154
x-ms-traffictypediagnostic: BLAPR05MB7475:
x-microsoft-antispam-prvs: <BLAPR05MB74755CEA85600EDB01E7C766AA350@BLAPR05MB7475.namprd05.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: UGaMGcBxjypcnfMo/q5RWhhgta6lag2w5R6pWOnsTr7KuKQnJxGjL33KVSHi1Qm/aOZMb65ytYH/0aQYJjxDc6qJfE28INP4SS1Wj06JxN0BDYIP7yWkhC/fB3QQWka/icsNSbmoKExeMSZj3G3C2vsAP6F1RnJku8FMUEii40E9Pb2ru0eOFX28VyUeW0dEOkK+V9wbPJs+kfMPXfoFvOjoXyVl4lh4U/4YHojGAJz9SVdKs/6KyF7496ZrZgbUAhqPMVke84q+7sMGQNXoEBeyI6QYyELWwuajfNP2UwqOXzRexeTbYV/nt6p2vUfbNohJ4SMf32guUaek20IJLmrLlr32crSwv9jDGG5kfCsYn0wnSPztogAYZVHoKjqeg4/lnWJUgZLYGAn+Oi1Y512l5XpP7DbgzwxVVgoiwWtVlSkTx62uvceQvdw6iSm+
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5076.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(396003)(136003)(346002)(376002)(316002)(26005)(186003)(54906003)(6916009)(64756008)(66446008)(86362001)(71200400001)(66946007)(478600001)(6486002)(66476007)(2616005)(76116006)(6512007)(5660300002)(91956017)(966005)(36756003)(66556008)(2906002)(8936002)(6506007)(8676002)(83380400001)(33656002)(53546011)(4326008)(166002)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: a50kfyPjTYaGmx9ByxiO+XQ/9AoCyxh9KCX+PnDEYeHAXQcPN3BSDaqkjJJVZmVkMTH4GLAT+sgKx7e7bY6p9ovdONjAn1fWRNkNahwymtnEfIzUvliPeIGDPYZ58HQ/In8Ee/5EHLP5BeJWKrwpDwF3Tf9mTKRhfC1Krl3tqOLcADgPbegwycJNhJUTKSEfznoiAaUr1s1URL4sAuTbqkxpIqcJAvg34TttsUWvi+thY9uDnSZV7twv2WtvwlSmwaFtwciCBOsupF5GxREmp0XaLwMdi3u3huqdjYxOjSqburmcVGana9n8rDFJS4Vw2f6RU2mWDtz/B5MgHlGRFoFGFro4gjE3rk1e7f0Z0AzNhfI0R/7pskpiVqnGS0GjgHyEYxdbrXrYp04k91xePbIamUdjfsAYpEclO7C+hfWebjX8NWi60dru5NxZ476nL/ZIPBkjXdbaJadFS3U9fycjVlJSawqm1eYN8OkXcVZWkKBKofD1B24iIYK9vFWJrJBqUm8+1khJ8Iy9taYRcRrxQr1G7luPu8tTiR9/BcUvuKeXo+finxlRr8FRddmL091bcfwSChyCyg1la1B8wvjkCv9IIWp8CYjAPsCDg+psZ6PiLhJSCrsowd7UzAjKACpy0ndUv4sZIi2dnldBIw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_21B4E52C38F44C94985C8C1DF88F4A92junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5076.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ddec013-5abd-4a80-d91d-08d863da9154
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2020 18:16:06.2693 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XqTXmkE35qGcPVjs7v3271Ga7pFPDcbeKTHi1fzsNM+OvHPAMtXUBYCU/fCT75aM
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7475
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-28_16:2020-09-28, 2020-09-28 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 phishscore=0 lowpriorityscore=0 clxscore=1015 mlxlogscore=999 spamscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 mlxscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009280141
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xGVpgyqtYc29hmmx1n7r3yI3Rr8>
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: Mon, 28 Sep 2020 18:16:13 -0000

Hi Bruno,

Thanks for your further comments. My responses in line.

On Sep 28, 2020, at 9:45 AM, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote:



Hi John,

Thanks for your answer.
Please see two replies inline [Bruno]

From: John Scudder [mailto:jgs@juniper.net]
Sent: Friday, September 25, 2020 9:04 PM
To: DECRAENE Bruno TGI/OLN <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Cc: idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>; draft-ietf-idr-rfc5575bis@ietf.org<mailto:draft-ietf-idr-rfc5575bis@ietf.org>; Hares Susan <shares@ndzh.com<mailto:shares@ndzh.com>>
Subject: Re: Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi Bruno,

Thanks for your comments. Some replies in line.


On Sep 25, 2020, at 12:56 PM, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> 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.
https://tools.ietf.org/html/rfc7606#section-8<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7606*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 https://tools.ietf.org/html/rfc7606#section-5.3<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7606*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.
[Bruno]
I agree that this is a valid reading.
However my reading was that draft-ietf-idr-rfc5575bis was saying that the NLRI was semantically malformed. Then that 7606 was calling for session reset only for the malformed MP_REACH attribute or syntactically incorrect NRLI, while calling for treat as withdraw when the NLRI could be recovered and hence withdrawn.

I’m fine to be declared in the rough, but so far (assuming I’m not wrong on the below second point), I do not support the proposed change.

I’m unclear on this point: the only change proposed so far (other than the one you’ll come to later in this message) is to add the clause "including an NLRI that contains an unknown component type” to Section 4.2. I don’t think that has any effect on the discussion we are now having about choice of error handling strategy, treat-as-withdraw vs. session reset, so your comment that you do not support it seems like a bit of a non sequitur.

I also note that this action may be seen as a local decision not impacting interop. Hence if we chose to modify the text, we could allow for both, allowing both types of implementation to be compliant with the RFC.

Also reviewing https://github.com/stoffi92/rfc5575bis/issues/20 I think that the outcome of the discussion was that the NRLI should not be propagated but “throw[n] away”.
I also see a specific concluding comment from stoffi92 (Christoph Loibl, the editor of the document) specifically referring to treat-as-withdraw  “unknown flow components / NLRI that are not understood completely lead to treat-as-withdraw (and thus are not propagated) -> error handling.”



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

With either ‘session reset’ or ‘treat as withdraw”, this NLRI is equally dead/withdrawn. The question is about punishing the other NLRIs from this AFI/SAFI and even all other AFI/SAFI sharing this BGP session.

I also note that RFC 7606 is opening another error handling strategy in between (called AFI/SAFI disable)

Just as a footnote, that strategy actually comes from RFC 4760, RFC 7606 merely cites it (and gives it a name).

—John


but this seem out of scope of the discussion as “session reset” does not appear in draft-ietf-idr-rfc5575bis. Hence this would be about RFC 7606 interpretation. (my interpretation is that 7606 allows for both, with no preference given)



Thank you.

--Bruno



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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.