>I doubt this is a widespread issue but at the same time this is a possible >attack vector and security concern.
Yes, I think the attack type you allude to would be rare. It is an attack by a rogue OLD BGP speaker (i.e., one that is not upgraded to RFC6793) in the path. The rouge speaker removes AS_SET from the AS_PATH, but it leaves unperturbed the AS4_PATH attribute (with AS_SET in it). >We did implement choice B and are therefore in favour of this method. However, for such security concern as described above, wouldn't it be better to just not trust the UPDATE and use choice A (treat-as-withdraw)? Choice A also seems consistent with deprecation of AS_SET and AS_CONFED_SET. Let us see what others have to say about it. Sriram ===================== -----Original Message----- From: Claudio Jeker <cje...@diehard.n-r-g.com> Sent: Thursday, August 22, 2024 4:36 AM To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=40nist....@dmarc.ietf.org> Cc: Ketan Talaulikar <ketant.i...@gmail.com>; i...@ietf.org; sidr...@ietf.org; grow@ietf.org Subject: [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 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 > _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
