[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