draft-liu-sidrops-community-authentication-00.txt		draft-liu-sidrops-community-authentication-01.txt
	sidrops Y. Liu		sidrops Y. Liu
	Internet-Draft J. Wang		Internet-Draft J. Wang
	Intended status: Standards Track Y. Wang		Intended status: Standards Track Y. Wang
	Expires: 30 March 2024 M. Xu		Expires: 26 September 2024 M. Xu
	Tsinghua University		Tsinghua University
	27 September 2023		25 March 2024
	BGP Community-based Attacks and Community Origin Authentication		BGP Community-based Attacks and Community Origin Authentication
	draft-liu-sidrops-community-authentication-00		draft-liu-sidrops-community-authentication-01
	Abstract		Abstract
	BGP community usage has continued to increase during the past decade.		BGP community usage has continued to increase during the past decade.
	Unfortunately, while BGP community is a seemingly innocuous feature,		Unfortunately, while BGP community is a seemingly innocuous feature,
	it can be used to influence routing in unintended ways. Existing		it can be used to influence routing in unintended ways. Existing
	defense mechanisms are insufficient to defend community-based		defense mechanisms are insufficient to prevent community-based
	attacks. This document describes some of the scenarios that may be		attacks. This document describes some of the scenarios that may be
	used to launch these attacks and make recommendations on practices		used to launch these attacks and make recommendations on practices
	that may defend them. In particular, this document proposes		that may defend them. In particular, this document proposes
	SecCommunity, an extension to the Border Gateway Protocol (BGP) that		SecCommunity, an extension to the Border Gateway Protocol (BGP) that
	can authenticate the ASes who added action community values on the		can authenticate the ASes who added action community values on the
	announcements.		announcements.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 30 March 2024.		This Internet-Draft will expire on 26 September 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	RFC Community Origin Authentication September 2023
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 4		2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 4
	3. Community-based Attack Cases . . . . . . . . . . . . . . . . 4		3. Community-based Attack Cases . . . . . . . . . . . . . . . . 4
	3.1. Remotely Triggered Blackholing . . . . . . . . . . . . . 5		3.1. Remotely Triggered Blackholing . . . . . . . . . . . . . 6
	3.2. Tuning Local Prference . . . . . . . . . . . . . . . . . 9		3.2. Tuning Local Prference . . . . . . . . . . . . . . . . . 9
	4. Community-based Attacks in the Wild . . . . . . . . . . . . . 12		4. Community-based Attacks in the Wild . . . . . . . . . . . . . 13
	5. BGP Community Origin Authentication . . . . . . . . . . . . . 13		5. BGP Community Origin Authentication . . . . . . . . . . . . . 13
	5.1. SecCommunity Attribute . . . . . . . . . . . . . . . . . 15		5.1. SecCommunity Attribute . . . . . . . . . . . . . . . . . 14
	5.2. Adding action community values to the SecCommunity		5.2. Adding action community values to the SecCommunity
	Attribute . . . . . . . . . . . . . . . . . . . . . . . . 16		Attribute . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.3. Validating a Received SecCommunity UPDATE Message . . . . 17		5.3. Validating a Received SecCommunity UPDATE Message . . . . 17
	5.4. Removing action community values from the SecCommunity		5.4. Removing action community values from the SecCommunity
	Attribute . . . . . . . . . . . . . . . . . . . . . . . . 19		Attribute . . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Operational Considerations . . . . . . . . . . . . . . . . . 19		6. Operational Considerations . . . . . . . . . . . . . . . . . 19
	6.1. Private AS Numbers . . . . . . . . . . . . . . . . . . . 19		6.1. Private AS Numbers . . . . . . . . . . . . . . . . . . . 19
	6.2. Deployment Considerations . . . . . . . . . . . . . . . . 20		6.2. Deployment Considerations . . . . . . . . . . . . . . . . 20
	6.3. Incremental Deployment Considerations . . . . . . . . . . 20		6.3. Incremental Deployment Considerations . . . . . . . . . . 20
	6.4. Considerations for Four-octet Community Values . . . . . 20		6.4. Considerations for Four-octet Community Values . . . . . 20
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	BGP community is a group of destinations which share some common		BGP community is a group of destinations which share some common
	property [RFC1997]. It is an optional transitive BGP attribute used		property [RFC1997]. It is an optional transitive BGP attribute used
	to tag meta-data in route announcements. It provides the ability to		to tag meta-data in route announcements. It provides the ability to
	signal opaque information within separate namespaces to aid in		signal opaque information within separate namespaces to aid in
	routing management [RFC8092].		routing management [RFC8092].
	RFC Community Origin Authentication September 2023
	Roughly speaking, BGP community is used by Autonomous Systems (ASes)		Roughly speaking, BGP community is used by Autonomous Systems (ASes)
	mainly for two kinds of purposes [RFC8195], i.e., labeling the routes		mainly for two kinds of purposes [RFC8195], i.e., labeling the routes
	that have particular attributes (named as informational community) or		that have particular attributes (named as informational community) or
	notifying upstream ASes to conduct some actions (named as action		notifying upstream ASes to conduct some actions (named as action
	community) [DB08]. Informational community values are used by an AS		community) [DB08]. Informational community values are used by an AS
	to label the routes that have particular attributes, including		to label the routes that have particular attributes, including
	business relationship, the geographical locations of original		business relationship, the geographical locations of original
	prefixes and inter-AS interconnections, or simply the ASN of next-hop		prefixes and inter-AS interconnections, or simply the ASN of next-hop
	AS. Action community values are used by an AS to notify other ASes		AS. Action community values are used by an AS to notify other ASes
	to conduct specific actions for it, such as tuning local preference,		to conduct specific actions for it, such as tuning local preference,
	selective announcement, AS path prepending, and remotely triggered		selective announcement, AS path prepending, and remotely triggered
	blackholing [RFC7999].		blackholing.
	Because action communities can be used to notify upstream ASes to		Because action communities can be used to notify upstream ASes to
	conduct some actions, their values must be negotiated between the AS		conduct some actions, their values must be negotiated between the AS
	who tags these community values and the AS who takes actions. A		who tags these community values and the AS who takes actions. A
	simple way is that one AS (usually the larger one) defines the		simple way is that one AS (usually the larger one) defines the
	actions associated with specific community values and the other AS		actions associated with specific community values and the other AS
	just tags values according to the definitions to notify that AS.		just tags values according to the definitions to notify that AS.
	Currently, BGP communities provide one of the most convenient way for		Currently, BGP communities provide one of the most convenient way for
	signaling information between ASes and are an essential component for		signaling information between ASes and are an essential component for
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 4 ¶
	of their community values transparent to anyone else. It increases		of their community values transparent to anyone else. It increases
	the risk of being attacked by ASes who do not negotiate with the		the risk of being attacked by ASes who do not negotiate with the
	community value definers through community-based attacks.		community value definers through community-based attacks.
	The necessity of restricting the usage of BGP community has been		The necessity of restricting the usage of BGP community has been
	noticed in [RFC5635] and [RFC7999], which point out that "BGP		noticed in [RFC5635] and [RFC7999], which point out that "BGP
	announcements carrying the BLACKHOLE community should only be		announcements carrying the BLACKHOLE community should only be
	accepted and honored if the neighboring network is authorized to		accepted and honored if the neighboring network is authorized to
	advertise the prefix". However, they only focus on one type of BGP		advertise the prefix". However, they only focus on one type of BGP
	community, i.e., blackholing, and do not explicitly specify how to		community, i.e., blackholing, and do not explicitly specify how to
	RFC Community Origin Authentication September 2023
	implement the rules. Furthermore, measurements in [GV17] showed that		implement the rules. Furthermore, measurements in [GV17] showed that
	almost 30% of the blackholing community values traveled more than one		almost 30% of the blackholing community values traveled more than one
	hop, which indicates that the receiver of an announcement cannot know		hop, which indicates that the receiver of an announcement cannot know
	who tags the community value on the announcement and then it is		who tags the community value on the announcement and then it is
	incapable of judging whether the tagger is authorized to advertise		incapable of judging whether the tagger is authorized to ask for
	the prefix. The measurment result suggests that community-based		blackholing the prefix. The measurment result suggests that
	attacks can be launched several hops away from the AS who defines the		community-based attacks can be launched several hops away from the AS
	action community values. We highlight some cases of community-based		who defines the action community values. We highlight some cases of
	attacks in Section 3.		community-based attacks in Section 3.
	As BGP community-based attacks do not modify AS_PATH attribute,		As BGP community-based attacks do not modify AS_PATH attribute,
	existing hijacking defense methods including Resource Public Key		existing hijacking defense methods including Resource Public Key
	Infrastructure (RPKI) [RFC6480] and BGPsec [RFC8205] are insufficient		Infrastructure (RPKI) [RFC6480] and BGPsec [RFC8205] are insufficient
	to prevent community-based attacks. For this reason, this document		to prevent community-based attacks. For this reason, this document
	suggests to take the origin authentication of BGP community into		suggests to take the origin authentication of BGP community into
	consideration. We propose a BGP extension to authenticate the ASes		consideration. We propose a BGP extension to authenticate the ASes
	who adds a community value on the announcement. See Section 5 for		who adds a community value on the announcement. See Section 5 for
	more details.		more details.
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	[RFC7999], RPKI [RFC6480], and BGPsec [RFC8205].		[RFC7999], RPKI [RFC6480], and BGPsec [RFC8205].
	3. Community-based Attack Cases		3. Community-based Attack Cases
	We introduced the risk that BGP action community can be used to		We introduced the risk that BGP action community can be used to
	attack routing in unintended ways though it seems harmless in		attack routing in unintended ways though it seems harmless in
	Section 1. In this section, we will highlight different cases where		Section 1. In this section, we will highlight different cases where
	transitive community propagation can be used to launch community-		transitive community propagation can be used to launch community-
	based attacks.		based attacks.
	RFC Community Origin Authentication September 2023
	As defined in [RFC8195], "action community values are added as labels		As defined in [RFC8195], "action community values are added as labels
	to request that a route be treated in a particular way within an AS.		to request that a route be treated in a particular way within an AS.
	The operator of the AS defines a routing policy that adjusts path		The operator of the AS defines a routing policy that adjusts path
	attributes based on the community. For example, the route's		attributes based on the community. For example, the route's
	propagation characteristics, the LOCAL_PREF (local preference), the		propagation characteristics, the LOCAL_PREF (local preference), the
	next hop, or the number of AS_PATH prepends to be added when it is		next hop, or the number of AS_PATH prepends to be added when it is
	received or propagated can be changed." From it, we can see there		received or propagated can be changed." From it, we can see there
	are four kinds of action communities which are generally used.		are four kinds of action communities which are generally used.
	(1) Remotely Triggered Blackholing (RTBH) [RFC7999]. See		(1) Remotely Triggered Blackholing (RTBH) [RFC7999]. See
	skipping to change at page 5, line 31 ¶		skipping to change at page 5, line 29 ¶
	(3) Selective NO_EXPORT [RFC8195]. As part of an agreement between		(3) Selective NO_EXPORT [RFC8195]. As part of an agreement between
	AS1 and AS2, AS1 might request AS2 to selectively filter routes		AS1 and AS2, AS1 might request AS2 to selectively filter routes
	learned from AS1 to certain eBGP neighbors.		learned from AS1 to certain eBGP neighbors.
	(4) Selective AS_PATH prepending [RFC8195]. As part of an agreement		(4) Selective AS_PATH prepending [RFC8195]. As part of an agreement
	between AS1 and AS2, AS1 might request AS2 to selectively		between AS1 and AS2, AS1 might request AS2 to selectively
	prepend the AS_PATH with AS2 on routes learned from AS1 to		prepend the AS_PATH with AS2 on routes learned from AS1 to
	certain eBGP neighbors.		certain eBGP neighbors.
	Not all kinds of action communities can be used to attack routing		These four kinds of action communities can be classified into two
	behaviors. If an action community value can change the priority of		categories according to their impact on the community value definer.
	the routes that it is tagged on, it can be used to launch community-		The first category of action community values can directly change the
	based attacks. In other words, it can influence best route selection		priority of the community value definer on the routes that they are
	process and force the community value definer to choose a backup path		tagged on, including RTBH community values and TLP community values.
	that is harmful to itself. Two kinds of action community values		In other words, this category of community values can influence the
	satisfy this requirement, i.e., RTBH community values and TLP		best route selection process and force the community value definer to
	community values.		choose a backup path that is harmful to itself. Attacks launched
			using this category of action community values can directly attack
			the community value definer and take effect without a deep
			understanding of its topology and routing policies. The second
			category of action community values can only enable the community
			value definer to modify the AS path length or propagation range of
			the routes that they are tagged on, including selective NO_EXPORT
			community values and selective AS_PATH prepending community values.
			In other words, this category of community values can influence the
			best route selection process of the community value definer's
			upstream ASes. Attacks launched using this category of community
			values may affect many upstream ASes of the community value definer
			and require familiarity with topology and routing policies of the
			community value definer and its upstream ASes to take effect. These
			attacks are more demanding on the attackers and environment than
			attacks launched using the first category of action community values,
			so they are more difficult to occur in reality. Therefore, we mainly
			introduce the community-based attacks launched by using RTBH
			community values and TLP community values in the following
			paragraphs.
	3.1. Remotely Triggered Blackholing		3.1. Remotely Triggered Blackholing
	Distributed Denial of Service attacks can heavily degrade network		Distributed Denial of Service attacks can heavily degrade network
	performance and even make the services unavailable [AM17]. One		performance and even make the services unavailable [AM17]. One
	mitigation option is blackholing, i.e., dropping all traffic going to		mitigation option is blackholing, i.e., dropping all traffic going to
	a destination under attack, which makes the victim prefix become		a destination under attack, which makes the victim prefix become
	intentionally unreachable. Many networks enable blackholing by		intentionally unreachable. Many networks enable blackholing by
	leveraging BGP community attribute as a signaling mechanism		leveraging BGP community attribute as a signaling mechanism
	[RFC7999]. The AS who provides remotely triggered blackholing		[RFC7999]. The AS who provides remotely triggered blackholing
	service defines an action community value. Other ASes trigger		service defines an action community value. Other ASes trigger
	blackholing requests by sending BGP announcements to the RTBH service		blackholing requests by sending BGP announcements to the RTBH service
	provider for specific destination prefixes with the chosen		provider for specific destination prefixes with the chosen
	blackholing value.		blackholing value.
	RFC Community Origin Authentication September 2023
	In order to prevent community-based attacks using blackholing		In order to prevent community-based attacks using blackholing
	community values, the usage scope is strictly limited in previous		community values, the usage scope is strictly limited in previous
	RFCs. As defined in RFC 5635 [RFC5635] and RFC 7999 [RFC7999], an		RFCs. As defined in RFC 5635 [RFC5635] and RFC 7999 [RFC7999], an
	operator configured with RTBH filtering MUST only accept		operator configured with RTBH filtering MUST only accept
	announcements from the neighboring network for prefixes that it is		announcements from the neighboring network for prefixes that it is
	authorized to advertise. Moreover, a BGP speaker receiving an		authorized to advertise. Moreover, a BGP speaker receiving an
	announcement tagged with the blackholing community values SHOULD add		announcement tagged with the blackholing community values SHOULD add
	the NO_ADVERTISE or NO_EXPORT community values [RFC1997], or a		the NO_ADVERTISE or NO_EXPORT community values [RFC1997], or a
	similar community value, to prevent propagation of the prefix outside		similar community value, to prevent propagation of the prefix outside
	the local AS [RFC7999]. If all the ASes obey the rules defined in		the local AS [RFC7999]. If all the ASes obey the rules defined in
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 17 ¶
	service. AS3 receives two paths to AS1 for p. The first path is via		service. AS3 receives two paths to AS1 for p. The first path is via
	path "AS2, AS1" and the second is via path "AS4, AS5, AS1". Let us		path "AS2, AS1" and the second is via path "AS4, AS5, AS1". Let us
	assume AS3 prefers the first path since it is the shorter one. In		assume AS3 prefers the first path since it is the shorter one. In
	this example, if AS2 adds the blackholing community value defined by		this example, if AS2 adds the blackholing community value defined by
	AS3 (i.e., AS3:666 ) [RFC7999] to its announcement for p to AS3,		AS3 (i.e., AS3:666 ) [RFC7999] to its announcement for p to AS3,
	traffic to p would be dropped at AS3. Compared with that AS2 (the		traffic to p would be dropped at AS3. Compared with that AS2 (the
	attacker) directly drops the traffic to p at its own network by		attacker) directly drops the traffic to p at its own network by
	itself, RTBH-based attacks can prevent AS3 from selecting the backup		itself, RTBH-based attacks can prevent AS3 from selecting the backup
	path "AS4, AS5, AS1" to reach AS1.		path "AS4, AS5, AS1" to reach AS1.
	RFC Community Origin Authentication September 2023
	+-------+		+-------+
	+---| AS3 |--+		+---| AS3 |--+
	| +-------+ |		| +-------+ |
	AS3:666 | |		AS3:666 | |
	| |		| |
	+-------+ +-------+		+-------+ +-------+
	+--| AS2 | | AS4 |		+--| AS2 | | AS4 |
	| +-------+ +-------+		| +-------+ +-------+
	| |		| |
	| |		| |
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 17 ¶
	customer of AS4, tags the blackholing community values of AS4 on the		customer of AS4, tags the blackholing community values of AS4 on the
	announcement to AS4 for p, AS4 will prefer path (2) rather than path		announcement to AS4 for p, AS4 will prefer path (2) rather than path
	(1). This case is already discussed in [SF18]. The reason is that		(1). This case is already discussed in [SF18]. The reason is that
	routers often treat community values before best path selection,		routers often treat community values before best path selection,
	which is shown in the Cisco router configuration sample in [RFC5635].		which is shown in the Cisco router configuration sample in [RFC5635].
	The router might set the local preference of an announcement to a		The router might set the local preference of an announcement to a
	value above the value for general customer routes if the announcement		value above the value for general customer routes if the announcement
	is tagged with blackholing community values. Then in the best route		is tagged with blackholing community values. Then in the best route
	selection phase, the router will select this announcement as the best		selection phase, the router will select this announcement as the best
	route and set the next-hop of the announcement to a discard		route and set the next-hop of the announcement to a discard
	RFC Community Origin Authentication September 2023
	interface. Therefore, ASes on a backup path can tag blackholing		interface. Therefore, ASes on a backup path can tag blackholing
	community values on the announcement to make the RTBH service		community values on the announcement to make the RTBH service
	provider select the backup path as the best and then drop all the		provider select the backup path as the best and then drop all the
	traffic to the blackholed prefix.		traffic to the blackholed prefix.
	It should be emphasized that the attacker on the backup path can be		It should be emphasized that the attacker on the backup path can be
	out of the customer cone of the RTBH service provider, e.g. AS6. In		out of the customer cone of the RTBH service provider, e.g. AS6. In
	the example in Figure 2, if AS6, the attacker, tags the blackholing		the example in Figure 2, if AS6, the attacker, tags the blackholing
	community values of AS4 on the announcement to AS5 for p. Similar as		community values of AS4 on the announcement to AS5 for p. Similar as
	the previous example, AS4 might increase the local preference of path		the previous example, AS4 might increase the local preference of path
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 38 ¶
	+-------+ customer		+-------+ customer
	Figure 2: Attacker on the backup path blackholes the traffic at		Figure 2: Attacker on the backup path blackholes the traffic at
	RTBH service provider through RTBH-based attacks		RTBH service provider through RTBH-based attacks
	In summary, attackers can blackhole the traffic from the RTBH service		In summary, attackers can blackhole the traffic from the RTBH service
	provider to the destination by launching RTBH-based attacks, whether		provider to the destination by launching RTBH-based attacks, whether
	they are on the best path or backup paths. For the attackers on the		they are on the best path or backup paths. For the attackers on the
	best path, they can achieve the same result by simply dropping the		best path, they can achieve the same result by simply dropping the
	traffic to the destination at their own networks, but the usage of		traffic to the destination at their own networks, but the usage of
	RFC Community Origin Authentication September 2023
	RTBH community values can help the attackers prevent the RTBH		RTBH community values can help the attackers prevent the RTBH
	provider from selecting any backup path. But for the attackers on		provider from selecting any backup path. But for the attackers on
	backup paths, it is impossible for them to block the traffic from the		backup paths, it is impossible for them to block the traffic from the
	RTBH service provider to the destination without launching RTBH-based		RTBH service provider to the destination without launching RTBH-based
	attacks. RTBH-based attacks make them capable of unauthorized		attacks. RTBH-based attacks make them capable of unauthorized
	blackholing the traffic to the prefixes at the RTBH service provider.		blackholing the traffic to the prefixes at the RTBH service provider.
	3.2. Tuning Local Prference		3.2. Tuning Local Prference
	According to [RFC8195], as part of an agreement between two peering		According to [RFC8195], as part of an agreement between two peering
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 38 ¶
	| Backup customer route | ASX:9:0 |		| Backup customer route | ASX:9:0 |
	| Peering route | ASX:10:0 |		| Peering route | ASX:10:0 |
	| Upstream transit route | ASX:11:0 |		| Upstream transit route | ASX:11:0 |
	| Fallback route, to be installed | ASX:12:0 |		| Fallback route, to be installed | ASX:12:0 |
	| if no other path is available | |		| if no other path is available | |
	+-------------------------------------------------------------+		+-------------------------------------------------------------+
	Figure 3: Preference Classes and Example Community Values in TLP		Figure 3: Preference Classes and Example Community Values in TLP
	Service		Service
	RFC Community Origin Authentication September 2023
	As LOCAL_PREF attribute strongly affects the best route selection		As LOCAL_PREF attribute strongly affects the best route selection
	process, TLP community values must be negotiated between the TLP		process, TLP community values must be negotiated between the TLP
	service provider and the community value tagger. But if the AS who		service provider and the community value tagger. But if the AS who
	offers the TLP service does not inspect whether the community value		offers the TLP service does not inspect whether the community value
	tagger is allowed to tag this value, it might be used to launch TLP-		tagger is allowed to tag this value, it might be used to launch TLP-
	based attacks.		based attacks.
	An attackers on the backup path may use TLP community values that set		An attackers on the backup path may use TLP community values that set
	the local preference to the class "normal customer route" or "backup		the local preference to the class "normal customer route" or "backup
	customer route" to launch TLP-based attacks. An example is shown in		customer route" to launch TLP-based attacks. An example is shown in
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 23 ¶
	Only prefixes whose best path are learned from peers or providers can		Only prefixes whose best path are learned from peers or providers can
	be attacked by using the TLP community values that set local		be attacked by using the TLP community values that set local
	preference to class "normal customer route" or "backup customer		preference to class "normal customer route" or "backup customer
	route". But these two kinds of TLP community values are supported by		route". But these two kinds of TLP community values are supported by
	many networks that provides TLP service and all ASes on backup paths		many networks that provides TLP service and all ASes on backup paths
	for these prefixes are capable to launch TLP-based attacks using		for these prefixes are capable to launch TLP-based attacks using
	them. It means that such attacks can be launched from a wide range		them. It means that such attacks can be launched from a wide range
	of ASes on the backup path.		of ASes on the backup path.
	RFC Community Origin Authentication September 2023
	+-------+ provider		+-------+ provider
	| AS4 |----------+		| AS4 |----------+
	+-------+ |		+-------+ |
	AS3:9:0 | provider |		AS3:9:0 | provider |
	| |		| |
	| customer | customer		| customer | customer
	+-------+ +-------+ +------+		+-------+ +-------+ +------+
	| AS2 |-------| AS3 | | AS5 |		| AS2 |-------| AS3 | | AS5 |
	+-------+ peer +-------+ +------+		+-------+ peer +-------+ +------+
	| provider | provider		| provider | provider
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 17 ¶
	instead of the path directly received from AS1, making a financial		instead of the path directly received from AS1, making a financial
	loss for AS2. Compared with the attacks in Figure 4, although few		loss for AS2. Compared with the attacks in Figure 4, although few
	Internet service providers support the TLP community values of "above		Internet service providers support the TLP community values of "above
	customer route", this kind of attacks can cause a bigger financial		customer route", this kind of attacks can cause a bigger financial
	loss and have a wider range of victims. Even prefixes whose best		loss and have a wider range of victims. Even prefixes whose best
	path are learned from customers can be attacked rather than only		path are learned from customers can be attacked rather than only
	prefixes whose best path are learned from peers or providers. All		prefixes whose best path are learned from peers or providers. All
	ASes on backup paths for these prefixes are capable to launch this		ASes on backup paths for these prefixes are capable to launch this
	kind of TLP-based attacks.		kind of TLP-based attacks.
	RFC Community Origin Authentication September 2023
	AS2:7:0 +-------+		AS2:7:0 +-------+
	+-----------| AS4 |		+-----------| AS4 |
	| provider +-------+		| provider +-------+
	| | provider		| | provider
	| |		| |
	| customer | customer		| customer | customer
	+-------+ +-------+		+-------+ +-------+
	| AS2 | | AS3 |		| AS2 | | AS3 |
	+-------+ +-------+		+-------+ +-------+
	| provider | provider		| provider | provider
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 22 ¶
	One reported community-based attack in the Internet is as follows.		One reported community-based attack in the Internet is as follows.
	Oracle reported a BGP hijack towards authoritative DNS servers of US		Oracle reported a BGP hijack towards authoritative DNS servers of US
	payment processing companies in July 2018 that misdirected users to		payment processing companies in July 2018 that misdirected users to
	malicious websites through directing the DNS requests of the users to		malicious websites through directing the DNS requests of the users to
	a forged DNS server [oracle]. At the beginning of this BGP hijack,		a forged DNS server [oracle]. At the beginning of this BGP hijack,
	the hijack prefixes were only propagated to three peers. But later,		the hijack prefixes were only propagated to three peers. But later,
	the attacker changed a community value of the hijack announcements,		the attacker changed a community value of the hijack announcements,
	then the hijack announcements were propagated to 48 peers. It can be		then the hijack announcements were propagated to 48 peers. It can be
	seen that community values have been used in attacks to increase the		seen that community values have been used in attacks to increase the
	scope of route propagation. [SF18] conducted an experiment to		scope of route propagation. [SF18] conducted an experiment to
	RFC Community Origin Authentication September 2023
	explore the potential of the 307 verified RTBH community values		explore the potential of the 307 verified RTBH community values
	identified in [GV17] to be used to launch attacks. The researchers		identified in [GV17] to be used to launch attacks. The researchers
	advertised prefix p twice, the first time without community values		advertised prefix p twice, the first time without community values
	and the second time with one of the 307 RTBH community values. They		and the second time with one of the 307 RTBH community values. They
	issued probes from 200 vantage points to p to detect whether the		issued probes from 200 vantage points to p to detect whether the
	traffic to p was blackholed. The result showed that 25 distinct		traffic to p was blackholed. The result showed that 25 distinct
	community values among the 307 RTBH community values sucessfully		community values among the 307 RTBH community values sucessfully
	blackholed the traffic from at least one vantage point to p, i.e., at		blackholed the traffic from at least one vantage point to p, i.e., at
	least one vantage point is responsive after the first advertisement		least one vantage point is responsive after the first advertisement
	and then becomes unresponsive after the second advertisement.		and then becomes unresponsive after the second advertisement.
	skipping to change at page 14, line 5 ¶		skipping to change at page 13, line 48 ¶
	Community-based attacks may cause serious consequences for the		Community-based attacks may cause serious consequences for the
	networks that define community values. However, BGP contains no		networks that define community values. However, BGP contains no
	specific mechanism to prevent community-based attacks. As a result,		specific mechanism to prevent community-based attacks. As a result,
	there is a strong need for a mechanism to solve the problem. BGP		there is a strong need for a mechanism to solve the problem. BGP
	community values are essentially a convention between two ASes.		community values are essentially a convention between two ASes.
	Therefore, community-based attacks can be mitigated by the signature		Therefore, community-based attacks can be mitigated by the signature
	of the community value tagger and the validation of the community		of the community value tagger and the validation of the community
	recipient.		recipient.
	RFC Community Origin Authentication September 2023
	This document describes SecCommunity, an extension to BGP that		This document describes SecCommunity, an extension to BGP that
	provides the ability to authenticate the AS who adds a community		provides the ability to authenticate the AS who adds a community
	value on an announcement. As informational community values are only		value on an announcement. As informational community values are only
	used to label the routes that have particular attributes, they cannot		used to label the routes that have particular attributes, they cannot
	be used to change the routing behaviors of other ASes directly, so		be used to change the routing behaviors of other ASes directly, so
	there is little use for the community value recipient to verify the		there is little use for the community value recipient to verify the
	identity of the informational community value tagger. Therefore,		identity of the informational community value tagger. Therefore,
	SecCommunity is only used for action community values that may be		SecCommunity is only used for action community values that may be
	leveraged to launch attacks through notifying other ASes to conduct		leveraged to launch attacks through notifying other ASes to conduct
	specific actions. Before adopting SecCommunity, the community value		specific actions. Before adopting SecCommunity, the community value
	skipping to change at page 14, line 31 ¶		skipping to change at page 14, line 23 ¶
	who adds an action community value needs to make sure its identity is		who adds an action community value needs to make sure its identity is
	authentic and knowable to the recipient by generating a digital		authentic and knowable to the recipient by generating a digital
	signature. The recipient of the action community value (i.e., the AS		signature. The recipient of the action community value (i.e., the AS
	who needs to take actions according to this community value) should		who needs to take actions according to this community value) should
	verify the digital signature to know the identity of the community		verify the digital signature to know the identity of the community
	tagger and then check whether the community tagger is allowed to add		tagger and then check whether the community tagger is allowed to add
	this community value by consulting its pre-configured CACL. The		this community value by consulting its pre-configured CACL. The
	recipient will conduct the specific actions only if the community		recipient will conduct the specific actions only if the community
	tagger is allowed to add this community value in the CACL.		tagger is allowed to add this community value in the CACL.
	SecCommunity is implemented through an optional transitive BGP path		SecCommunity extension is implemented through an optional transitive
	attribute SecCommunity. This document specifies the format of		BGP path attribute SecCommunity. This document specifies the format
	SecCommunity attribute. It also describes how a SecCommunity-		of SecCommunity attribute. It also describes how a SecCommunity-
	compliant BGP speaker (referred to hereafter as a SecCommunity		compliant BGP speaker (referred to hereafter as a SecCommunity
	speaker) generates, propagates, and validates BGP UPDATE messages		speaker) generates, propagates, and validates BGP UPDATE messages
	containing this attribute (referred to hereafter as SecCommunity		containing this attribute (referred to hereafter as SecCommunity
	UPDATE message) to achieve BGP community origin authentication.		UPDATE message) to achieve BGP community origin authentication.
	SecCommunity relies on the BGPsec router certificates [RFC8209] to		SecCommunity relies on the BGPsec router certificates [RFC8209] to
	generate and validate the digital signatures. Each BGPsec router		generate and validate the digital signatures. Each BGPsec router
	certificate is issued to routers under a Resource Public Key		certificate is issued to routers under a Resource Public Key
	Infrastructure (RPKI) certificate. A BGPsec route certificate		Infrastructure (RPKI) certificate. A BGPsec route certificate
	contains a private key, a public key, AS Resources field and Subject		contains a private key, a public key, AS Resources field and Subject
	Key Identifier (SKI) field. The AS Resources field includes at least		Key Identifier (SKI) field. The AS Resources field includes at least
	one AS number that the router belongs to. The SKI field is used to		one AS number that the router belongs to. The SKI field is used to
	identify the certificates that contain a particular pair of public		identify the certificates that contain a particular pair of public
	key and private key [RFC6487]. Any SecCommunity speaker who wishes		key and private key [RFC6487]. Any SecCommunity speaker who wishes
	to send SecCommunity UPDATE messages to eBGP peers needs to possess a		to send SecCommunity UPDATE messages to eBGP peers needs to possess a
	private key associated with an BGPsec router certificate. Note,		private key associated with an BGPsec router certificate. Note,
	however, that a SecCommunity speaker does not need such a certificate		however, that a SecCommunity speaker does not need such a certificate
	in order to validate received SecCommunity UPDATE messages.		in order to validate received SecCommunity UPDATE messages.
	RFC Community Origin Authentication September 2023
	5.1. SecCommunity Attribute		5.1. SecCommunity Attribute
	SecCommunity attribute is an optional transitive BGP path attribute.		SecCommunity attribute is an optional transitive BGP path attribute.
	SecCommunity attribute carries the digital signatures used to		SecCommunity attribute carries the digital signatures used to
	authenticate the ASes that added action community values to the BGP		authenticate the ASes that added action community values to the BGP
	announcement.		announcement.
	SecCommunity attribute is made up of several Secure_Community		SecCommunity attribute is made up of several Secure_Community
	segments. Figure 6 provides the specification of the format for		segments. Figure 6 provides the specification of the format for
	SecCommunity attribute.		SecCommunity attribute.
	skipping to change at page 16, line 5 ¶		skipping to change at page 15, line 46 ¶
	| Signature (variable) |		| Signature (variable) |
	+----------------------------------------------------+		+----------------------------------------------------+
	Figure 7: Secure_Community Segment Format		Figure 7: Secure_Community Segment Format
	The AS Number field in Figure 7 is the AS number of the BGP speaker		The AS Number field in Figure 7 is the AS number of the BGP speaker
	that added the action community value in the Action Community Value		that added the action community value in the Action Community Value
	field. The AS Number field MUST be encoded as a 4-octet quantity to		field. The AS Number field MUST be encoded as a 4-octet quantity to
	support 4-octet AS numbers defined in [RFC6793].		support 4-octet AS numbers defined in [RFC6793].
	RFC Community Origin Authentication September 2023
	The Action Community Value field in Figure 7 is the action community		The Action Community Value field in Figure 7 is the action community
	value that needs origin authentication. It should support the		value that needs origin authentication. It should support the
	community values in Communities attribute [RFC1997] and BGP Large		community values in Communities attribute [RFC1997] and BGP Large
	Communities attribute [RFC8092]. The community attribute values are		Communities attribute [RFC8092]. The community attribute values are
	4 octets and the large community values are 12 octets. The Action		4 octets and the large community values are 12 octets. The Action
	Community Value field in Figure 7 SHOULD be encoded as a 12-octet		Community Value field in Figure 7 SHOULD be encoded as a 12-octet
	quantity to support large community values. The considerations for		quantity to support large community values. The considerations for
	4-octet community values are detailed in Section 6.4. The Action		4-octet community values are detailed in Section 6.4. The Action
	Community Value field, like BGP large community, is made up of two		Community Value field, like BGP large community, is made up of two
	parts. The first 4 octets contain the AS number who defines the		parts. The first 4 octets contain the AS number who defines the
	skipping to change at page 17, line 5 ¶		skipping to change at page 16, line 46 ¶
	5.2. Adding action community values to the SecCommunity Attribute		5.2. Adding action community values to the SecCommunity Attribute
	In order to add a new action community value to a SecCommunity UPDATE		In order to add a new action community value to a SecCommunity UPDATE
	message with a given algorithm suite, the SecCommunity speaker MUST		message with a given algorithm suite, the SecCommunity speaker MUST
	possess a private key suitable for generating signatures to this		possess a private key suitable for generating signatures to this
	algorithm suite. This private key must correspond to the public key		algorithm suite. This private key must correspond to the public key
	in a valid BGPsec router certificate whose AS Resources field		in a valid BGPsec router certificate whose AS Resources field
	[RFC8209] includes the SecCommunity speaker's AS number.		[RFC8209] includes the SecCommunity speaker's AS number.
	RFC Community Origin Authentication September 2023
	When a SecCommunity speaker wants to add a new action community		When a SecCommunity speaker wants to add a new action community
	value, it needs to create a Secure_Community segment for this action		value, it needs to create a Secure_Community segment for this action
	community value. The following steps are used to create a new		community value. The following steps are used to create a new
	Secure_Community segment and update the SecCommunity attribute.		Secure_Community segment and update the SecCommunity attribute.
	(1) Set the AS Number field. The AS Number field MUST match the AS		(1) Set the AS Number field. The AS Number field MUST match the AS
	number of this SecCommunity speaker.		number of this SecCommunity speaker.
	(2) Set the Action Community Value field. The Action Community		(2) Set the Action Community Value field. The Action Community
	Value field SHOULD be the action community value that the		Value field SHOULD be the action community value that the
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 5 ¶
	Upon receiving a SecCommunity UPDATE message from an external peer, a		Upon receiving a SecCommunity UPDATE message from an external peer, a
	SecCommunity speaker SHOULD determine whether the action community		SecCommunity speaker SHOULD determine whether the action community
	values need origin authentication validation. If the first 4 octets		values need origin authentication validation. If the first 4 octets
	of the Action Community Value field in all Secure_Community segments		of the Action Community Value field in all Secure_Community segments
	do not match the AS number of the SecCommunity speaker, there is no		do not match the AS number of the SecCommunity speaker, there is no
	need to validate. Otherwise, a validation procedure is necessary		need to validate. Otherwise, a validation procedure is necessary
	before conducting the actions associated with the action community		before conducting the actions associated with the action community
	values.		values.
	RFC Community Origin Authentication September 2023
	Validation of a SecCommunity UPDATE message makes use of data from		Validation of a SecCommunity UPDATE message makes use of data from
	BGPsec router certificates [RFC8209]. Therefore, it is necessary		BGPsec router certificates [RFC8209]. Therefore, it is necessary
	that the recipient has access to the following fields that are		that the recipient has access to the following fields that are
	obtained from all valid BGPsec router certificates: AS Number, Public		obtained from all valid BGPsec router certificates: AS Number, Public
	Key, and SKI from each valid BGPsec router certificate.		Key, and SKI from each valid BGPsec router certificate.
	The validation procedure is described as follows.		The validation procedure is described as follows.
	First, check to ensure that the SecCommunity attribute is		First, check to ensure that the SecCommunity attribute is
	syntactically correct (conforms to the specification in this		syntactically correct (conforms to the specification in this
	skipping to change at page 19, line 4 ¶		skipping to change at page 19, line 4 ¶
	(3) Compute the digest function for the Action Community Value field		(3) Compute the digest function for the Action Community Value field
	of the NV segment.		of the NV segment.
	(4) Use the signature validation algorithm to verify the Signature		(4) Use the signature validation algorithm to verify the Signature
	field of the NV segment. That is, invoke the signature		field of the NV segment. That is, invoke the signature
	validation algorithm on the following three inputs: the value of		validation algorithm on the following three inputs: the value of
	the Signature field in the Secure_Community segment, the digest		the Signature field in the Secure_Community segment, the digest
	value computed in (3) and public key obtained in (2). If the		value computed in (3) and public key obtained in (2). If the
	signature validation algorithm determines that the signature is		signature validation algorithm determines that the signature is
	RFC Community Origin Authentication September 2023
	invalid, then the SecCommunity speaker SHOULD mark the		invalid, then the SecCommunity speaker SHOULD mark the
	Secure_Community as 'Invalid' and proceed to the next NV		Secure_Community as 'Invalid' and proceed to the next NV
	segment.		segment.
	If a Secure_Community segment passes the above four-step validation,		If a Secure_Community segment passes the above four-step validation,
	it is marked as 'Valid'. Then the SecCommunity speaker SHOULD check		it is marked as 'Valid'. Then the SecCommunity speaker SHOULD check
	whether the AS in the AS Number field of this Secure_Community		whether the AS in the AS Number field of this Secure_Community
	segment is permitted to add this community value by consulting its		segment is permitted to add this community value by consulting its
	pre-configured CACL. If permitted, the SecCommunity speaker will		pre-configured CACL. If permitted, the SecCommunity speaker will
	conduct the action associated with this community value. For each		conduct the action associated with this community value. For each
	skipping to change at page 20, line 5 ¶		skipping to change at page 20, line 5 ¶
	6.1. Private AS Numbers		6.1. Private AS Numbers
	The generation of a Secure_Community segment requires a private key		The generation of a Secure_Community segment requires a private key
	corresponding to the public key in a valid BGPsec router certificate		corresponding to the public key in a valid BGPsec router certificate
	to generate the digest signature. However, SecCommunity speakers in		to generate the digest signature. However, SecCommunity speakers in
	private ASes cannot be issued router certificates in the Global RPKI		private ASes cannot be issued router certificates in the Global RPKI
	[RFC8205]. It is a common problem in RPKI system. This document		[RFC8205]. It is a common problem in RPKI system. This document
	recommends to solve this problem through the method proposed in		recommends to solve this problem through the method proposed in
	[RFC8416].		[RFC8416].
	RFC Community Origin Authentication September 2023
	6.2. Deployment Considerations		6.2. Deployment Considerations
	SecCommunity attribute can coexist with Communities attribute in a		SecCommunity attribute can coexist with Communities attribute in a
	SecCommunity UPDATE message. SecCommunity attribute only offers		SecCommunity UPDATE message. SecCommunity attribute only offers
	origin authentication for action community values. Informational		origin authentication for action community values. Informational
	community values SHOULD still be added to Communities attribute.		community values SHOULD still be added to Communities attribute.
	If a BGP speaker does not support SecCommunity, it can still add		If a BGP speaker does not support SecCommunity, it can still add
	action community values to Communities attribute. Yet, the recipient		action community values to Communities attribute. Yet, the recipient
	of these action community values has no way to know the identity of		of these action community values has no way to know the identity of
	skipping to change at page 21, line 4 ¶		skipping to change at page 21, line 4 ¶
	6.4. Considerations for Four-octet Community Values		6.4. Considerations for Four-octet Community Values
	As defined in [RFC1997], community attribute values are four octets.		As defined in [RFC1997], community attribute values are four octets.
	The first two octets SHALL be an AS number and the semantics of the		The first two octets SHALL be an AS number and the semantics of the
	last two octets may be defined by this AS [RFC1997]. When adding a		last two octets may be defined by this AS [RFC1997]. When adding a
	new four-octet community value to SecCommunity attribute, the third		new four-octet community value to SecCommunity attribute, the third
	and fourth octets of Action Community Value field SHOULD be populated		and fourth octets of Action Community Value field SHOULD be populated
	with the first two octets of this four-octet community value and the		with the first two octets of this four-octet community value and the
	last two octets of Action Community Value field SHOULD be populated		last two octets of Action Community Value field SHOULD be populated
	with the last two octets of this four-octet community value. The		with the last two octets of this four-octet community value. The
	RFC Community Origin Authentication September 2023
	other octets of Action Community Value field SHOULD be populated with		other octets of Action Community Value field SHOULD be populated with
	value "0".		value "0".
	If the four-octet community value that a SecCommunity speaker wants		If the four-octet community value that a SecCommunity speaker wants
	to add is not encoded as [RFC1997] defines, it is not supported by		to add is not encoded as [RFC1997] defines, it is not supported by
	SecCommunity.		SecCommunity.
	7. Security Considerations		7. Security Considerations
	7.1. Security Guarantees		7.1. Security Guarantees
	skipping to change at page 21, line 35 ¶		skipping to change at page 21, line 32 ¶
	target for denial-of-service attacks against a SecCommunity speaker.		target for denial-of-service attacks against a SecCommunity speaker.
	To mitigate the effectiveness of such denial-of-service attacks,		To mitigate the effectiveness of such denial-of-service attacks,
	SecCommunity speakers should implement a validation algorithm that		SecCommunity speakers should implement a validation algorithm that
	performs expensive checks (e.g., signature verification) after		performs expensive checks (e.g., signature verification) after
	performing checks that are less expensive (e.g., syntax checks).		performing checks that are less expensive (e.g., syntax checks).
	8. IANA Considerations		8. IANA Considerations
	IANA needs to register a new path attribute described in Section 5 in		IANA needs to register a new path attribute described in Section 5 in
	the "BGP Path Attribute" subregistry under the "Border Gateway		the "BGP Path Attribute" registry in the "Border Gateway Protocol
	Protocol (BGP) Parameters" registry. The code for this new attribute		(BGP) Parameters" registry group. The code for this new attribute is
	is "SecCommunity". This document is the reference for the new		"SecCommunity". This document is the reference for the new
	attribute.		attribute.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities		[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
	Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,		Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
	<https://www.rfc-editor.org/info/rfc1997>.		<https://www.rfc-editor.org/info/rfc1997>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006,		DOI 10.17487/RFC4271, January 2006,
	<https://www.rfc-editor.org/info/rfc4271>.		<https://www.rfc-editor.org/info/rfc4271>.
	RFC Community Origin Authentication September 2023
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates", RFC 6487,		X.509 PKIX Resource Certificates", RFC 6487,
	DOI 10.17487/RFC6487, February 2012,		DOI 10.17487/RFC6487, February 2012,
	<https://www.rfc-editor.org/info/rfc6487>.		<https://www.rfc-editor.org/info/rfc6487>.
	[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,		[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
	I., and N. Hilliard, "BGP Large Communities Attribute",		I., and N. Hilliard, "BGP Large Communities Attribute",
	RFC 8092, DOI 10.17487/RFC8092, February 2017,		RFC 8092, DOI 10.17487/RFC8092, February 2017,
	<https://www.rfc-editor.org/info/rfc8092>.		<https://www.rfc-editor.org/info/rfc8092>.
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	<https://dl.acm.org/doi/10.5555/3241189.3241275>.		<https://dl.acm.org/doi/10.5555/3241189.3241275>.
	[DB08] Donnet, B. and O. Bonaventure, "On BGP Communities",		[DB08] Donnet, B. and O. Bonaventure, "On BGP Communities",
	CCR'08, DOI 10.1145/1355734.1355743, March 2008,		CCR'08, DOI 10.1145/1355734.1355743, March 2008,
	<https://dl.acm.org/doi/pdf/10.1145/1355734.1355743>.		<https://dl.acm.org/doi/pdf/10.1145/1355734.1355743>.
	[gtt] GTT, "Semantics of community values defined by AS 3257",		[gtt] GTT, "Semantics of community values defined by AS 3257",
	2023, <https://www.gtt.net/us-en/services/managed-		2023, <https://www.gtt.net/us-en/services/managed-
	networking/internet/ip-transit/bgp-communities/>.		networking/internet/ip-transit/bgp-communities/>.
	RFC Community Origin Authentication September 2023
	[GV17] Giotsas, V., Smaragdakis, G., Dietzel, C., Richter, P.,		[GV17] Giotsas, V., Smaragdakis, G., Dietzel, C., Richter, P.,
	Feldmann, A., and A. Berger, "Inferring BGP blackholing		Feldmann, A., and A. Berger, "Inferring BGP blackholing
	activity in the internet", IMC'17,		activity in the internet", IMC'17,
	DOI 10.1145/3131365.3131379, November 2017,		DOI 10.1145/3131365.3131379, November 2017,
	<https://dl.acm.org/doi/10.1145/3131365.3131379>.		<https://dl.acm.org/doi/10.1145/3131365.3131379>.
	[irrdatabase]		[irrdatabase]
	Internet Routing Registry, "IRR database", 2023,		Internet Routing Registry, "IRR database", 2023,
	<https://www.irr.net/>.		<https://www.irr.net/>.
	skipping to change at page 24, line 5 ¶		skipping to change at page 24, line 5 ¶
	[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet		[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
	Autonomous System (AS) Number Space", RFC 6793,		Autonomous System (AS) Number Space", RFC 6793,
	DOI 10.17487/RFC6793, December 2012,		DOI 10.17487/RFC6793, December 2012,
	<https://www.rfc-editor.org/info/rfc6793>.		<https://www.rfc-editor.org/info/rfc6793>.
	[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods		[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods
	for Generating Key Identifiers Values", RFC 7093,		for Generating Key Identifiers Values", RFC 7093,
	DOI 10.17487/RFC7093, December 2013,		DOI 10.17487/RFC7093, December 2013,
	<https://www.rfc-editor.org/info/rfc7093>.		<https://www.rfc-editor.org/info/rfc7093>.
	RFC Community Origin Authentication September 2023
	[RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G.		[RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G.
	Hankins, "BLACKHOLE Community", RFC 7999,		Hankins, "BLACKHOLE Community", RFC 7999,
	DOI 10.17487/RFC7999, October 2016,		DOI 10.17487/RFC7999, October 2016,
	<https://www.rfc-editor.org/info/rfc7999>.		<https://www.rfc-editor.org/info/rfc7999>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP		[RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP
	skipping to change at page 25, line 4 ¶		skipping to change at page 25, line 4 ¶
	100084		100084
	China		China
	Email: jessiewang@tsinghua.edu.cn		Email: jessiewang@tsinghua.edu.cn
	Yangyang Wang		Yangyang Wang
	Tsinghua University		Tsinghua University
	Beijing		Beijing
	100084		100084
	China		China
	Email: wangyy@cernet.edu.cn		Email: wangyy@cernet.edu.cn
	RFC Community Origin Authentication September 2023
	Mingwei Xu		Mingwei Xu
	Tsinghua University		Tsinghua University
	Beijing		Beijing
	100084		100084
	China		China
	Email: xumw@tsinghua.edu.cn		Email: xumw@tsinghua.edu.cn
End of changes. 38 change blocks.
	84 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/