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

John Scudder <jgs@juniper.net> Fri, 25 September 2020 19:04 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 0EAF63A03F4; Fri, 25 Sep 2020 12:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.703
X-Spam-Level:
X-Spam-Status: No, score=-4.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, 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=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=K8jBaXto; dkim=pass (1024-bit key) header.d=juniper.net header.b=OwHIF4YW
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 wLbPKBI-Yvxl; Fri, 25 Sep 2020 12:04:28 -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 BED763A03F1; Fri, 25 Sep 2020 12:04:27 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08PJ4Dpm007136; Fri, 25 Sep 2020 12:04:26 -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=2+PbJT3rb8HKozh+p+PxegDyJL401ckc4sgAVffgz3g=; b=K8jBaXtoANVPacPPyvTWfRsF8v3+W2TJQPKOoPdF/UlsK9/ZnAsMqFy8xW3jvcheg0JR 5WGhSqrgqXQsjPcvzqvD771ogyXMK0I8ZnUePbGVyZcXRWH+mn7rZmIERwR3JU9+mClX 1Br4f8BFPCfDbsWFcmmhJnf3/9AaM9uTVz8ibyWa+CIcLlBKC9eQjOnxClWaFrTFyg9e 4WffWxkatDBRP2TuApzvqQcCrrNsO/DVD33QdYkrgV+MXISLk847bAd2xSzcX4CxBqBW T+Z5MPQhfvPDHu1Qq2P6zX78lQ311MFYV7OiaXOWfoSCfSbn//L8PzNfk7/v7YM5inUx Kw==
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 33r6sa4xpj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Sep 2020 12:04:26 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dSDrx5C+l+2mWNBpSwdl8e4fMYnXclBy/zvA1AU3oemyS3h1fyCdjHhHcUfcwGiVOlFtW7Eoub3efWBIMyRQuJmJOHPXXUk6UMpGZovUbLhFKfnIMc9laRNpItEJanSbzCDtNgCoFV1X5u1JKdMK1IZ5tD0Rh7huICxKHj06rKPTSITrj4bgDbmgfpNmq19m8I/w5oSA/d+5jzxx3eVT2s9O9MFwCnalw+kx6RfqjoFKjTLIvRUkdKXiuKvfJScZmvgKrJaVFSXpdsgnUzY9IyvmJe4cQRRz3mhTcdSFp/xaMHYDhPxeC3vOKLy6lOqwxLfv8we4C0H7BcoKpm8viA==
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=2+PbJT3rb8HKozh+p+PxegDyJL401ckc4sgAVffgz3g=; b=UlzSkspFzTh1+wvR/s0OA4NiLVAVbgYtnqv5bSwa8YwTjyaQRaJy7Tzzn6gbdrfWPG+T56TRjFmA6jOrszot5n0Z9uMM2Va83q/bjgEGwDqyBmJhNstcgJSrqMQ9sEi4KQ2z2h8NnftLmYaUgEYzZDPzUGlC9DRAN4EiyAkabY2JP1FSWrl3cwLuDq/K+4qfFNtiE2z73Osvo/Rge8rVSAIenrACB+zisTscRPWRBGzCUmYVj/cnND7XzlAF5/j3VBGGKVV8aL5JZr9E+GSeqonZp1jeBWv7BvKuZFKTwMQxdykCNHZGg9BiVqJzh5CAZQirEeZr9NCi29e87DKCEQ==
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=2+PbJT3rb8HKozh+p+PxegDyJL401ckc4sgAVffgz3g=; b=OwHIF4YWv0p66/g5mc2A6pA7Mdmuqax8BlzkJDh0ygBUUhxgmVRgWabt3LWO0Fg/g8CCvH+7aGtko06bOJLK8bzKYZLIJuYF8XBM5rXwucA9SMucT93yeANV/eEh2rwTp+neaLm7rmuzpf+LiD6wW1dAouSOgSTYj+mOVPk0yhc=
Received: from BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) by BL0PR05MB5332.namprd05.prod.outlook.com (2603:10b6:208:62::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.18; Fri, 25 Sep 2020 19:04:22 +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.013; Fri, 25 Sep 2020 19:04:22 +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/7GqRzh40q9dKt5uqwGhKl5lcCAgAAjvQA=
Date: Fri, 25 Sep 2020 19:04:22 +0000
Message-ID: <DEE76A95-339B-433C-BD46-AD0243F72FBE@juniper.net>
References: <303E54F6-833A-4458-B3E6-DE90E7CA121B@juniper.net> <22341_1601052988_5F6E213C_22341_268_1_53C29892C857584299CBF5D05346208A48F82C17@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <22341_1601052988_5F6E213C_22341_268_1_53C29892C857584299CBF5D05346208A48F82C17@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: c790ba93-3e1b-4d1b-a730-08d86185d070
x-ms-traffictypediagnostic: BL0PR05MB5332:
x-microsoft-antispam-prvs: <BL0PR05MB53328B5BE94B8BC07CB332F6AA360@BL0PR05MB5332.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: KuXGru96b8NNwd8ECphIvgGaC1KyIBNIfQNhFHtE2sUDQFGf++lnR2MlZBB0lHdSreznfYCztFaoPDjn23TvkX5AkF5m+WDVvR7C+yDJ/ifgxLHcLhjHwhqQLDGPGqFBsnJ0lWAbmguvfO7weo5bL0ZZpl+l3JZcZa44dF+uzYIefrX3kehswqooS10SllDu0YvhAzMboRMPh340Qk/M5MxMeUeLRuHNeXIosOqOMUQYR3nafngC32Qlc0IVepdcqeVQxnklvkcEMfy7morkJOCm9/5KEXXsLq0E6PhIj4rhHDpJoPJ8sJaMuAc0zmobjz7ttUbFhdVGrf4E1njJJaDkrxUAWjQxKlIDdHriTmfTWK+Phq2eP2DFyEVZjq5sU04QNxKugrBxNt3S1X6RWA==
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)(396003)(39860400002)(346002)(376002)(136003)(86362001)(83080400001)(83380400001)(66446008)(33656002)(26005)(66476007)(66556008)(2616005)(64756008)(186003)(71200400001)(36756003)(5660300002)(166002)(6506007)(53546011)(478600001)(6916009)(316002)(6486002)(54906003)(8936002)(8676002)(76116006)(91956017)(4326008)(66946007)(6512007)(966005)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: pIl18Z2DrPEp6mVXqHCGqKvppDYDNlyvaU/pAk5XV1Sq0missulqamTYxnl7DOHcVPoaio4aIPEGj9e7yQbupLKCtETFyI9Osnfnyw/Y9lRt/gB9d7KCTtQBCNlgBMiwkdiB0H/u66ilLCSpLNQzKDx2PCoysNSntiUg383skOBPeVyW0uybIQeKhHF6GNC3At38meJwtnZZaOJ6rWiTMJnI9YInCMltfWUz5tV1U3ss6KNvMbWEPEE5ro+1dqzBP6N4HrBdVlW3PV9SBFUMIqhvBH8eVV0D80m9wnrkphOCzMKv3oPIg5Kg/wi8JCtrF+LEm/yOhVyWgYdoH1ovzsgjwfgZdOUrBaGmkX/UeNVzEpRuFmkGYg5CvsYdK5uCKaaaQ3zUg9S3Nb9cvilAO5Uu+XSnR+0UuCwW1k7Z8ZPM8oF1U4SU/ji90AOqbRfiwLTwpYrp089LJYTuWn7MzMFhZ/XCHsLy5dXFDAvsGkxCsf00vb5tyau5W7AyD+fCz+JEzdxa+Grkg+CB9TENHLj52ESbYwmSafnkVwEECIu/2bwSOmwK92BSnCU1ymeqnoyDyp26f6y94fry/9/Dw5UkG0LQCXku7x9++052FpzMIyi6FwD3awkyuv14kjY5lJJj40cPzKsu5hE9CYH20w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DEE76A95339B433CBD46AD0243F72FBEjunipernet_"
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: c790ba93-3e1b-4d1b-a730-08d86185d070
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 19:04:22.6854 (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: aUy+u/4MoiRde++Fp2H6AwHHI26hBnaklel7ouRV4uGcw6MiOBz4yEQFXZqY8Qxh
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5332
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-25_17:2020-09-24, 2020-09-25 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 impostorscore=0 mlxlogscore=999 lowpriorityscore=0 spamscore=0 mlxscore=0 malwarescore=0 phishscore=0 adultscore=0 suspectscore=0 clxscore=1011 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009250132
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/riX3T9mnhMpRF6YkM7QbeRB9aI4>
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: Fri, 25 Sep 2020 19:04:30 -0000

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

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