[Idr] Re: [Sidrops] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6
Claudio Jeker <cjeker@diehard.n-r-g.com> Thu, 22 August 2024 08:36 UTC
Return-Path: <cjeker@diehard.n-r-g.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 9D245C180B7B for <idr@ietfa.amsl.com>; Thu, 22 Aug 2024 01:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.205
X-Spam-Level:
X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXcXbuznEyDb for <idr@ietfa.amsl.com>; Thu, 22 Aug 2024 01:36:08 -0700 (PDT)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45467C169423 for <idr@ietf.org>; Thu, 22 Aug 2024 01:36:07 -0700 (PDT)
Received: (qmail 10164 invoked by uid 1000); 22 Aug 2024 08:36:01 -0000
Date: Thu, 22 Aug 2024 10:36:00 +0200
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
Message-ID: <Zsb4cBwCT7l3QYk_@diehard.n-r-g.com>
References: <SA1PR09MB81429DA3D95133F743EE2FF184BE2@SA1PR09MB8142.namprd09.prod.outlook.com> <CO1PR08MB6611189A21004F78179BDF24B38D2@CO1PR08MB6611.namprd08.prod.outlook.com> <ZsTuq46mz8lqQ-Ag@diehard.n-r-g.com> <SA1PR09MB81420D4FFD4A9E5DE21F72CF848F2@SA1PR09MB8142.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <SA1PR09MB81420D4FFD4A9E5DE21F72CF848F2@SA1PR09MB8142.namprd09.prod.outlook.com>
Message-ID-Hash: MY2MG73HACMYRYZBMHZRIVTCCOZI4ATX
X-Message-ID-Hash: MY2MG73HACMYRYZBMHZRIVTCCOZI4ATX
X-MailFrom: cjeker@diehard.n-r-g.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "idr@ietf.org" <idr@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, "grow@ietf.org" <grow@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: [Sidrops] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kjYZ_XF0kFhoFHRo-ppX9lreKF4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>
On Thu, Aug 22, 2024 at 03:46:11AM +0000, Sriram, Kotikalapudi (Fed) wrote: > [Jeff, Ketan, Sue, Keyur, all ... please share if you have some thoughts about this] > > Hi Claudio, > > >If a router sends you an AS_PATH without AS_SET and an AS4_PATH with AS_SET .... > > You raise a good question. Section 3.1 observations are based on the > premise that if RFC6793 is implemented correctly by the sender and > preceding ASes in the AS path, then the above will not happen. But you > think it could happen due to an intentional attack by the sender or a > preceding AS. If systems implement RFC6793 then why are they running without 4-byte ASN in the first place? Systems that only support 2-byte ASN do not follow RFC6793 since they don't support it. So you can not assume they will do anything regarding RFC6793 correctly. I doubt this is a widespread issue but at the same time this is a possible attack vector and security concern. It is a loop hole which should be closed. > All: > > OK, let us see if we can address this. > > Which of the following methods for modifying the recommendations at the top of Section 3 would be preferable (click to see Sec. 3: https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-15#name-recommendations )? > > Method A: Modify the second bullet in Sec. 3 as follows: > > * Upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs in the AS_PATH or AS4_PATH, MUST use the "treat-as-withdraw" error handling behavior as per [RFC7606]. > > Methos B. The second bullet in Sec. 3 remains as is but add a third bullet as follows: > > (unchanged second bullet) > * Upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs in the AS_PATH, MUST use the "treat-as-withdraw" error handling behavior as per [RFC7606]. > > (new third bullet) > * Upon reception of BGP UPDATE messages not containing AS_SETs or AS_CONFED_SETs in the AS_PATH but containing AS_SETs in the AS4_PATH, MUST use the "attribute discard" approach for the (malformed) AS4_PATH as per [RFC7606]. > > Note (with Choice B): The handling of UPDATES with AS_CONFED_SETs in the AS4_PATH is as specified in [RFC6793]. We did implement choice B and are therefor in favour of this method. > Thanks for you anticipated inputs. > > Sriram > > -----Original Message----- > From: Claudio Jeker <cjeker@diehard.n-r-g.com> > Sent: Tuesday, August 20, 2024 9:29 AM > To: idr@ietf.org > Subject: [Idr] Re: I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-15.txt > > On Mon, Aug 19, 2024 at 11:21:37AM -0700, internet-drafts@ietf.org wrote: > > Internet-Draft draft-ietf-idr-deprecate-as-set-confed-set-15.txt is > > now available. It is a work item of the Inter-Domain Routing (IDR) WG of the IETF. > > > > Title: Deprecation of AS_SET and AS_CONFED_SET in BGP > > Authors: Warren Kumari > > Kotikalapudi Sriram > > Lilia Hannachi > > Jeffrey Haas > > Name: draft-ietf-idr-deprecate-as-set-confed-set-15.txt > > Pages: 15 > > Dates: 2024-08-19 > > > > Abstract: > > > > BCP 172 (i.e., RFC 6472) recommends not using AS_SET and > > AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol > > (BGP). This document advances that recommendation to a standards > > requirement in BGP; it prohibits the use of the AS_SET and > > AS_CONFED_SET path segment types in the AS_PATH. This is done to > > simplify the design and implementation of BGP and to make the > > semantics of the originator of a BGP route clearer. This will also > > simplify the design, implementation, and deployment of various BGP > > security mechanisms. This document updates RFC 4271 by deprecating > > the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) > > and updates RFC 5065 by deprecating the origination of BGP routes > > with AS_CONFED_SET (Type 4 AS_PATH segment). Finally, it obsoletes > > RFC 6472. > > > > I had a look at this draft and think > Section 3.1 Considerations for AS4_PATH needs to be adjusted. > > 3.1. Considerations for AS4_PATH > > [RFC6793] created support for four-octet AS numbers in BGP using the > optional transitive AS4_PATH attribute. The mandatory AS_PATH > attribute is always present in a route [RFC4271], while the AS4_PATH > may or may not be present. If both AS_PATH and AS4_PATH attributes > are present, an AS_SET present in one would also be necessarily > present in the other. So, it is sufficient to perform the "treat-as- > withdraw" error handling as specified above using the AS_PATH alone. > > I think this is incorrect. You can not assume anything about AS4_PATH. The only thing RFC6793 mandates is that aspath length of AS4_PATH is smaller or equal to the aspath length of AS_PATH. > > If a router sends you an AS_PATH without AS_SET and an AS4_PATH with AS_SET then the reconstruction will introduce an AS_SET. This is possible and since AS4_PATH is transitive you can not even assume it was your peer playing games with you. > > So instead I would suggest what OpenBGPD does. By default reject AS4_PATH attributes that contain AS_SET and use "attribute discard" for them. > If the AS_PATH had a AS_SET as well then the prefix will be withdrawn anyway but if not then there will be no merge of this bad AS4_PATH. > If the user explicitly allows AS_SET then skip the above. > > I hope that after deprecating AS_SET for good we will be able to deprecate old 2-byte ASnum sessions as well since the hoops introduced by RFC6793 give me the heebie-jeebies. > -- > :wq Claudio > > _______________________________________________ > Sidrops mailing list -- sidrops@ietf.org > To unsubscribe send an email to sidrops-leave@ietf.org -- :wq Claudio
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Susan Hares
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Sriram, Kotikalapudi (Fed)
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… gengnan
- [Idr] Re: [Sidrops] Re: WG LC for draft-ietf-idr-… Lancheng
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Lancheng
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Susan Hares
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Claudio Jeker
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Sriram, Kotikalapudi (Fed)
- [Idr] Re: [Sidrops] Re: WG LC for draft-ietf-idr-… Claudio Jeker
- [Idr] Re: [Sidrops] Re: WG LC for draft-ietf-idr-… Sriram, Kotikalapudi (Fed)
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Sriram, Kotikalapudi (Fed)
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Susan Hares