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 <cje...@diehard.n-r-g.com> > Sent: Tuesday, August 20, 2024 9:29 AM > To: i...@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-dra...@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 -- sidr...@ietf.org > To unsubscribe send an email to sidrops-le...@ietf.org -- :wq Claudio _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
