diff --git a/draft-wang-sidrops-fcbgp-protocol.md b/draft-wang-sidrops-fcbgp-protocol.md index 8bb91a3..91588b8 100644 --- a/draft-wang-sidrops-fcbgp-protocol.md +++ b/draft-wang-sidrops-fcbgp-protocol.md @@ -173,9 +173,9 @@ FC-BGP speaker: # FC-BGP Negotiation -FC-BGP does not need to negotiate with neighbors since it is considered a transitive path attribute within the BGP UPDATE message. BGP speakers that do not recognize the FC path attribute or do not support FC-BGP, SHOULD still transmit the FC path attribute to their neighbors. As a result, there is no need to establish a new BGP capability as defined in {{RFC5492}}. +FC-BGP does not need to negotiate with neighbors since it is considered a transitive path attribute within the BGP UPDATE message. BGP speakers that do not recognize the FC path attribute or do not support FC-BGP SHOULD still transmit the FC path attribute to their neighbors. As a result, there is no need to establish a new BGP capability as defined in {{RFC5492}}. - + However, if one AS has uploaded its keys to RPKI, it would be deemed to support FC-BGP. The reason and process are defined in {{Validation}}. # FC Path Attribute @@ -257,12 +257,12 @@ Subject Key Identifier (SKI, 20 octets): Algorithm ID (1 octet): : The current assigned value is 1, indicating that SHA256 is used to hash the content to be signed, and ECDSA is used for signing. It follows the algorithm suite defined in {{RFC8208}} and its updates. Each FC segment has an Algorithm ID, so there is no need to worry about sudden changes in its algorithm suite. The key in FC-BGP uses the BGPsec Router Key, so its generation and management follow {{RFC8635}}. - + {: vspace="0"} Flags (1 octet): -: Several flag bits. The leftmost bit of the Flags field in {{figure2}} is the Confed_Segment flag (Flags-CS). The Flags-CS flag is set to 1 to indicate that the FC-BGP speaker that constructed this FC segment is sending the UPDATE message to a peer AS within the same AS confederation {{RFC5065}}. (That is, a sequence of consecutive Confed_Segment flags are set in an FC-BGP UPDATE message whenever, in a non-FC-BGP UPDATE message, an AS_PATH segment of type AS_CONFED_SEQUENCE occurs.) In all other cases, the Flags-CS flag is set to 0. The second leftmost bit (i.e., the second highest) of the Flags field in {{figure2}} is the Route_Server flag (Flags-RS). The Flags-RS flag is set to 1 to indicate that a route server adds this FC segment, but the AS number will never appear in the AS_PATH attribute. If the AS number of a router server is inserted into AS_PATH, this Flags-RS flag MUST be set to 0. The third leftmost bit (i.e., the third highest) of the Flags field in {{figure2}} is the Only_to_Customer flag (Flags-OTC). The Flags-OTC flag is set to 1 to indicate that the FC segment's issuer AS sends routes to its customer or peer. If this Flags-OTC flag is set, the next route propagation will only be permitted to the following customers. The remaining 5 bits of the Flags field are unassigned. They MUST be set to 0 by the sender and ignored by the receiver. +: Several flag bits. The leftmost bit of the Flags field in {{figure2}} is the Confed_Segment flag (Flags-CS). The Flags-CS flag is set to 1 to indicate that the FC-BGP speaker that constructed this FC segment is sending the UPDATE message to a peer AS within the same AS confederation {{RFC5065}}. (That is, a sequence of consecutive Confed_Segment flags is set in an FC-BGP UPDATE message whenever, in a non-FC-BGP UPDATE message, an AS_PATH segment of type AS_CONFED_SEQUENCE occurs.) In all other cases, the Flags-CS flag is set to 0. The second leftmost bit (i.e., the second highest) of the Flags field in {{figure2}} is the Route_Server flag (Flags-RS). The Flags-RS flag is set to 1 to indicate that a route server adds this FC segment, but the AS number will never appear in the AS_PATH attribute. If the AS number of a router server is inserted into AS_PATH, this Flags-RS flag MUST be set to 0. The third leftmost bit (i.e., the third highest bit) of the Flags field in {{figure2}} is the AS_Path_Prepending flag (Flags-ASPP). This Flags-ASPP flag is set to 1 when AS path prepending is used; otherwise, this flag MUST be set to 0. The fourth and fifth leftmost bits (i.e., the fourth highest and fifth highest bits) of the Flags field in {{figure2}} are the Provider_to_Customer flag (Flags-P2C) and Peer_to_Peer flag (Flags-P2P) separately. The Flags-P2C flag is set to 1 to indicate that the FC segment's issuer AS sends routes to its customer, and the Flags-P2P flag is set to 1 to indicate that the FC segment's issuer AS sends routes to its peer. If the Flags-P2C or Flags-P2P flags are set, the next route propagation will only be permitted to the following customers. The remaining bits of the Flags field are unassigned. They MUST be set to 0 by the sender and ignored by the receiver. Signature Length (2 octets): : It only contains the length of the Signature field in octets, not including other fields. @@ -272,7 +272,7 @@ Signature Length (2 octets): {: vspace="0"} Signature (variable length): -: The signature content and order are Signature=ECDSA(SHA256(PASN, CASN, NASN, Prefix, Prefix Length)), where the Prefix is the IP address prefix which is encapsulated in the BGP UPDATE, i.e. NLRI, and only one prefix is used each time. When hashing and signing, the full IP address and IP prefix length are used, i.e., IPv4 uses 4 octets and IPv6 uses 16 octets. +: The signature content and order are Signature=ECDSA(SHA256(PASN, CASN, NASN, SKI, Algorithm ID, Flags, Signature Length, Prefix, Prefix Length)), where the Signature Length is kept as 0, the Prefix is the IP address prefix which is encapsulated in the BGP UPDATE, i.e., NLRI, and only one prefix is used each time. When hashing and signing, the full IP address and IP prefix length are used, i.e., IPv4 uses 4 octets and IPv6 uses 16 octets. # FC-BGP UPDATE Messages {#fcbgp-update} @@ -280,47 +280,47 @@ Signature (variable length): This part defines the generation of the FC path attribute and the FC segment. An FC-BGP speaker SHOULD generate a new FC segment or even a new FC path attribute when it propagates a route to its external neighbors. For internal neighbors, the FC path attribute in the BGP UPDATE message remains unchanged. - -The FC-BGP speaker follows a specific process to create the FC path attribute for the ongoing UPDATE message. Firstly, it generates a new FC Segment containing the necessary information for the FC path. This new FC Segment is then added to the FCList of the outer format defined in {{figure1}}. It is important to note that if the FC-BGP speaker is not the origin AS and there is already an existing FC path attribute of the UPDATE message, it MUST prepend its new FC segment to the FCList of the existing FC path attribute like the insertion process of ASN in AS_PATH attribute. This allows the FC-BGP speaker to contribute to its own FC segment while maintaining the existing FC path information. Otherwise, if it is the source AS, the FC-BGP speaker generates the FC path attribute defined in {{figure1}} and inserts it into the UPDATE message. + +The FC-BGP speaker follows a specific process to create the FC path attribute for the ongoing UPDATE message. Firstly, it generates a new FC Segment containing the necessary information for the FC path. This new FC Segment is then added to the FCList of the outer format defined in {{figure1}}. It is important to note that if the FC-BGP speaker is not the origin AS and there is already an existing FC path attribute of the UPDATE message, it MUST prepend its new FC segment to the FCList of the existing FC path attribute, like the insertion process of ASN in the AS_PATH attribute. This allows the FC-BGP speaker to contribute to its own FC segment while maintaining the existing FC path information. Otherwise, if it is the source AS, the FC-BGP speaker generates the FC path attribute defined in {{figure1}} and inserts it into the UPDATE message. -There are three AS numbers in one FC segment as {{figure2}} shows. The populating of the Current AS number (CASN) within the FC segment is like the AS number in BGPsec, it MUST match the AS number in the Subject field of the RPKI router certificate that will be used to verify the FC segment constructed by this FC-BGP speaker (see {{Section 3.1.1 of RFC8209}} and {{RFC6487}}). The Previous AS number (PASN) is typically set to the AS number from which the UPDATE message receives. However, if the FC-BGP speaker is located in the origin AS, the PASN SHOULD be filled with 0. The Nexthop AS number (NASN) is set to the AS number of the peer to whom the route is advertised. So if there are several neighbors, the FC-BGP speaker should generate separate FCs for different neighbors. But it would never generate a new FC segment for the iBGP neighbor. +There are three AS numbers in one FC segment, as {{figure2}} shows. The populating of the Current AS number (CASN) within the FC segment is like the AS number in BGPsec; it MUST match the AS number in the Subject field of the RPKI router certificate that will be used to verify the FC segment constructed by this FC-BGP speaker (see {{Section 3.1.1 of RFC8209}} and {{RFC6487}}). The Previous AS number (PASN) is typically set to the AS number from which the UPDATE message is received. However, if the FC-BGP speaker is located in the origin AS, the PASN SHOULD be filled with 0. The Nexthop AS number (NASN) is set to the AS number of the peer to whom the route is advertised. So if there are several neighbors, the FC-BGP speaker should generate separate FCs for different neighbors. But it would never generate a new FC segment for the iBGP neighbor. The Subject Key Identifier field (SKI) within the new FC segment is populated with the identifier found in the Subject Key Identifier extension of the RPKI router certificate associated with the FC-BGP speaker. This identifier serves as a crucial piece of information for recipients of the route advertisement. It enables them to identify the appropriate certificate to employ when verifying the signatures in FC segments attached to the route advertisement. This practice adheres to the guidelines outlined in {{RFC8209}}. +The second-highest/leftmost one is representative of pCount in RS. The last sentence is not really. It is correct in BGPsec but not in FC-BGP. --> Typically, the Flags field is set to 0. -A route server (RS) is a third-party brokering system that interconnects three or more BGP-speaking routers using eBGP in IXPs {{RFC7947}}. Typically, RS performs like a transit AS except that it does not insert its AS number to the AS_PATH attribute. The route server also can participate in the FC-BGP process. If the RS is an FC-BGP-enabled RS, it may choose to set the Flags-RS bit to 1 when it populates its FC segment. However, when the RS chooses to add its AS number to the AS_PATH attribute, the Flags-RS bit SHOULD be set to 0. If the RS is a non-FC-BGP RS, it propagates the FC-BGP UPDATE message directly. Anyway, the AS number of RS would be used in the FC segment no matter if it appears in the AS_PATH attribute. +A route server (RS) is a third-party brokering system that interconnects three or more BGP-speaking routers using eBGP in IXPs {{RFC7947}}. Typically, RS performs like a transit AS except that it does not insert its AS number into the AS_PATH attribute. The route server can also participate in the FC-BGP process. If the RS is an FC-BGP-enabled RS, it may choose to set the Flags-RS bit to 1 when it populates its FC segment. However, when the RS chooses to add its AS number to the AS_PATH attribute, the Flags-RS bit SHOULD be set to 0. If the RS is a non-FC-BGP RS, it propagates the FC-BGP UPDATE message directly. Anyway, the AS number of RS would be used in the FC segment, no matter if it appears in the AS_PATH attribute. -Typically, the route server does not insert ASN into AS_PATH. Take {{fig-rs-ex}} as an example where AS A advertises a BGP UPDATE to AS C and RS connects AS A and AS B. When RS supports the FC-BGP mechanism, AS A adds its FC segment: FC(NULL, A, RS), RS adds its FC segment: FC(A, RS, B, Flags-RS), and AS B adds its FC segment: FC(RS, B, C). If RS does not support the FC-BGP mechanism, FC(A, RS, B, Flags-RS) is missed in FCList, which SHOULD be considered as a partial deployment scenario. +Typically, the route server does not insert ASN into AS_PATH. Take {{fig-rs-ex}} as an example, where AS A advertises a BGP UPDATE to AS C and RS connects AS A and AS B. When RS supports the FC-BGP mechanism, AS A adds its FC segment: FC(NULL, A, RS), RS adds its FC segment: FC(A, RS, B, Flags-RS), and AS B adds its FC segment: FC(RS, B, C). If RS does not support the FC-BGP mechanism, FC(A, RS, B, Flags-RS) is missed in FCList, which SHOULD be considered as a partial deployment scenario. ~~~~~~ +--------+ +--------+ +--------+ +--------+ | AS A | --> | RS | --> | AS B | --> | AS C | +--------+ +--------+ +--------+ +--------+ ~~~~~~ -{: #fig-rs-ex title="A network topology with Router Server linked two ASs."} +{: #fig-rs-ex title="A network topology with a Router Server linking two ASs."} -AS Path Prepending is a traffic engineering mechanism in BGP to deprioritize a route or alternate path, which will prepend the local AS number multiple times to the AS_PATH attribute {{ASPP}}. To minimize unnecessary processing load during the validation of FC segments, an FC-BGP speaker SHOULD NOT generate multiple consecutive FC segments with the same AS number. Instead, the FC-BGP speaker SHOULD aim to produce a single FC segment once, even if the intention is to achieve the semantics of prepending the same AS number multiple times. +AS Path Prepending is a traffic engineering mechanism in BGP to deprioritize a route or alternate path, which will prepend the local AS number multiple times to the AS_PATH attribute {{ASPP}}. To minimize unnecessary processing load during the validation of FC segments, an FC-BGP speaker SHOULD NOT generate multiple consecutive FC segments with the same AS number. Instead, the FC-BGP speaker SHOULD aim to produce a single FC segment once, even if the intention is to achieve the semantics of prepending the same AS number multiple times. Flags-ASPP MUST be set to 1 if the local AS uses AS Path Prepending. -The Algorithm ID field is set to 1. FC-BGP only supports one algorithm suite in this document as BGPsec Algorithm defined in {{RFC8208}}. That is the signature algorithm used MUST be the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 and the hash algorithm used MUST be SHA-256. If it transits from one algorithm suite to another, the FC-BGP speaker MUST place its router certificate in the RPKI repository first and then specify the Algorithm ID in the FC segment. +The Algorithm ID field is set to 1. FC-BGP only supports one algorithm suite in this document as the BGPsec Algorithm defined in {{RFC8208}}. That is the signature algorithm used MUST be the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256, and the hash algorithm used MUST be SHA-256. If it transits from one algorithm suite to another, the FC-BGP speaker MUST place its router certificate in the RPKI repository first and then specify the Algorithm ID in the FC segment. The Signature Length field is populated with the length (in octets) of the value in the Signature field. -The Signature field in the new FC segment is a variable length field. It contains a digital signature encapsulated in DER format that binds the prefix, its length, and triplet to the RPKI router certificate corresponding to the FC-BGP speaker. The digital signature is computed as follows: Signature=ECDSA(SHA256(PASN, CASN, NASN, Prefix, Prefix Length)). +The Signature field in the new FC segment is a variable-length field. It contains a digital signature encapsulated in DER format that binds the prefix, its length, and triplet to the RPKI router certificate corresponding to the FC-BGP speaker. The digital signature is computed as follows: Signature=ECDSA(SHA256(PASN, CASN, NASN, SKI, Algorithm ID, Flags, Signature Length, Prefix, Prefix Length)). -The signatures within the FC segments of an FC-BGP UPDATE message ensure the protection of crucial information including the AS number of the neighbor involved in the message exchange. This information is explicitly included in the generated FC segment. Consequently, if an FC-BGP speaker intends to transmit an FC-BGP UPDATE message to multiple BGP neighbors, it MUST generate a distinct FC-BGP UPDATE message for each unique neighbor AS to whom the UPDATE message is being sent. +The signatures within the FC segments of an FC-BGP UPDATE message ensure the protection of crucial information, including the AS number of the neighbor involved in the message exchange. This information is explicitly included in the generated FC segment. Consequently, if an FC-BGP speaker intends to transmit an FC-BGP UPDATE message to multiple BGP neighbors, it MUST generate a distinct FC-BGP UPDATE message for each unique neighbor AS to whom the UPDATE message is being sent. Indeed, an FC-BGP UPDATE message is REQUIRED to advertise a route to just one prefix. This is because if an FC-BGP speaker receives an UPDATE message containing multiple prefixes, it would be unable to construct a valid FC-BGP UPDATE message, including valid path signatures, with a subset of the received prefixes. To advertise routes to multiple prefixes, the FC-BGP speaker MUST generate individual FC-BGP UPDATE messages for each prefix. This ensures the proper construction of valid path signatures for each advertised prefix. - + All FC-BGP UPDATE messages MUST conform to BGP's maximum message size. If the resulting message exceeds the maximum message size, then the guidelines in {{Section 9.2 of RFC4271}} MUST be followed. @@ -335,7 +335,7 @@ The RPKI allows the legitimate holder of IP address prefix(es) to issue a digita If an FC-BGP router receives a non-FC-BGP UPDATE message from an external neighbor, meaning that the origin BGP speaker does not support FC-BGP, the router processes the UPDATE message as a regular BGP UPDATE message typically. In this case, it SHOULD NOT add its own FC segment to the UPDATE message. On the other hand, when the FC-BGP speaker advertises routes belonging to its local AS and receives them from an internal neighbor, it MUST add its FC segment to the UPDATE message if it decides to propagate those routes. Furthermore, if the FC-BGP router receives an FC-BGP UPDATE message from a neighbor for a specific prefix and chooses to propagate that neighbor's route for the prefix, it MUST propagate the route as an FC-BGP UPDATE message containing the FC path attribute. - + When an FC-BGP speaker sends an FC-BGP UPDATE message to an iBGP (internal BGP) neighbor, the process is straightforward. When the FC-BGP speaker originates a new route advertisement and sends it to an iBGP neighbor, it MUST NOT include the FC path attribute of the UPDATE message. In other words, the FC-BGP speaker omits the FC path attribute. Similarly, when an FC-BGP speaker decides to forward an FC-BGP UPDATE message to an iBGP neighbor, it MUST refrain from adding a new FC segment to the FC-BGP UPDATE message. @@ -353,20 +353,20 @@ When an FC-BGP speaker in an AS confederation receives an FC-BGP UPDATE message Within a confederation, the verification of FC-BGP signatures added by other members of the confederation is optional. Note that if a confederation chooses not to verify digital signatures within the confederation, then FC-BGP is not able to provide any assurances about the integrity of the Member-AS Numbers placed in FC segments where the Confed_Segment flag is set to 1. -When a confederation member receives an FC-BGP UPDATE message from a peer within the confederation and propagates it to a peer outside the confederation, it needs to remove all of the FC segments added by confederation members when it removes all path segments of the AS_PATH with the type of AS_CONFED_SEQUENCE or AS_CONFED_SET. To do this, the confederation members propagated the route outside the confederation the following: +When a confederation member receives an FC-BGP UPDATE message from a peer within the confederation and propagates it to a peer outside the confederation, it needs to remove all of the FC segments added by confederation members when it removes all path segments of the AS_PATH with the type of AS_CONFED_SEQUENCE or AS_CONFED_SET. To do this, the confederation members propagated the route outside the confederation the follows: 1. Starting with the most recently added FC segment, remove FC segments whose Flags-CS bit is 1. Stop this process once an FC segment that has its Confed_Segment flags set to 0 is reached. 2. Add an FC segment containing, in the CASN field, the AS Confederation Identifier (the public AS number of the confederation). Note that all fields other than the CASN field are populated. -Finally, as discussed above, an AS confederation MAY optionally decide that its members will not verify digital signatures added by members. In such a confederation, when an FC-BGP speaker runs the algorithm in {{validation-steps}}, the FC-BGP speaker, during the process of signature verifications, first checks whether the Confed_Segment flag in an FC segment is set to 1. If the flag is set to 1, the FC-BGP speaker skips the verification for the corresponding signature and immediately moves on to the next FC segment. It is an error when an FC-BGP speaker receives, from a neighbor who is not in the same AS confederation, an FC-BGP UPDATE message containing a Confed_Segment flag set to 1. +Finally, as discussed above, an AS confederation MAY optionally decide that its members will not verify digital signatures added by members. In such a confederation, when an FC-BGP speaker runs the algorithm in {{validation-steps}}, the FC-BGP speaker, during the process of signature verifications, first checks whether the Confed_Segment flag in an FC segment is set to 1. If the flag is set to 1, the FC-BGP speaker skips verification for the corresponding signature and proceeds immediately to the next FC segment. It is an error when an FC-BGP speaker receives, from a neighbor who is not in the same AS confederation, an FC-BGP UPDATE message containing a Confed_Segment flag set to 1. ## Processing Instructions for BGP Route Leak Prevention -BGP routing system suffers lots of vulnerabilities. The systemic vulnerability of the BGP routing system is known as "route leaks" {{RFC7908}}. There are 6 types of route leaks defined in {{RFC7908}}. +The BGP routing system is susceptible to numerous vulnerabilities. The systemic vulnerability of the BGP routing system is known as "route leaks" {{RFC7908}}. There are 6 types of route leaks defined in {{RFC7908}}. {{RFC9234}} can detect and prevent BGP route leaks by adding a new BGP OPEN Role capability and OTC transitive path attribute. However, it may be forged. -When using BGP route leak prevention with FC-BGP, it SHOULD tell the neighbor its BGP Role as {{Section 4 of RFC9234}}. If the peer's role is Customer, Peer, or RS-Client, the Flags-OTC MUST be set to 1 on route advertisement. Then, the route SHOULD subsequently go only to the Customers. It is worth noting that if the recently added FC Segment already set the Flags-OTC flag, it MUST NOT be propagated to Providers, Peers, or RSes. +When using BGP route leak prevention with FC-BGP, it SHOULD tell the neighbor its BGP Role as {{Section 4 of RFC9234}}. If the peer's role is Customer or RS-Client, the Flags-P2C MUST be set to 1 on route advertisement. If the peer's role is peer, the Flags-P2P MUST be set to 1 on route advertisement. Then, the route SHOULD subsequently go only to the Customers. It is worth noting that if the recently added FC Segment already set the Flags-P2C or Flags-P2P flags to 1, it MUST NOT be propagated to Providers, Peers, or RSes. # Processing a Received FC-BGP UPDATE Message @@ -382,18 +382,18 @@ The FC-BGP speaker stores the router certificates in the RPKI repository, and an ## Validation {#Validation} -When verifying the authenticity of an FC-BGP UPDATE message, information from the RPKI router certificates is utilized. The RPKI router certificates provide the data including the triplet to verify the AS_PATH and FC path attributes. As a prerequisite, the recipient MUST have access to these RPKI router certificates. +When verifying the authenticity of an FC-BGP UPDATE message, information from the RPKI router certificates is utilized. The RPKI router certificates provide the data, including the triplet to verify the AS_PATH and FC path attributes. As a prerequisite, the recipient MUST have access to these RPKI router certificates. - -Note that if an AS uploads its router certificates to RPKI, it would be deemed to support FC-BGP. The validation process MUST check that to ensure no malicious on-path AS removes FCs from FC-BGP UPDATE. + +Note that if an AS uploads its router certificates to RPKI, it would be deemed to support FC-BGP. The validation process MUST check to ensure no malicious on-path AS removes FCs from FC-BGP UPDATE. - + Note that the FC-BGP speaker could perform the validation of RPKI router certificates on its own and extract the required data, or it could receive the same data from a trusted cache that performs RPKI validation on behalf of (some set of) FC-BGP speakers. (For example, the trusted cache could deliver the necessary validity information to the FC-BGP speaker by using the Router Key PDU (Protocol Data Unit) for the RPKI-Router protocol {{RFC8210}}.) -The recipient validates an FC-BGP UPDATE message containing the FC path attribute and obtains one result of two states: 'Valid' and 'Not Valid'. We will describe the validation procedure in {{validation-steps}} in this document. The validation result will be used at BGP route selection, thus it will be discussed at {{BGP-route-selection}}. +The recipient validates an FC-BGP UPDATE message containing the FC path attribute and obtains one of two states: 'Valid' and 'Not Valid'. We will describe the validation procedure in {{validation-steps}} in this document. The validation result will be used at BGP route selection, thus it will be discussed at {{BGP-route-selection}}. -As the FC-BGP UPDATE message generates at the eBGP router, the FC-BGP validation needs only to be performed at the eBGP router. The iBGP route plays a crucial role in the FC-BGP UPDATE message propagation and distribution. The function of iBGP is to convey the validation status of an FC-BGP UPDATE message from an ingress edge router to an egress edge router within an AS. The specific mechanisms used to convey the validation status can vary depending on the implementation and local policies of the AS. By propagating this information through iBGP, the eBGP router, and other routers within the AS, can be aware of the validation status of the FC-BGP UPDATE messages and make routing decisions accordingly. As stated in {{fcbgp-update}}, when an FC-BGP speaker decides to forward a syntactically correct FC-BGP UPDATE message, it is RECOMMENDED to do so while preserving the FC path attribute. This recommendation applies regardless of the validation state of the UPDATE message. +As the FC-BGP UPDATE message is generated at the eBGP router, the FC-BGP validation needs only to be performed at the eBGP router. The iBGP route plays a crucial role in the FC-BGP UPDATE message propagation and distribution. The function of iBGP is to convey the validation status of an FC-BGP UPDATE message from an ingress edge router to an egress edge router within an AS. The specific mechanisms used to convey the validation status can vary depending on the implementation and local policies of the AS. By propagating this information through iBGP, the eBGP router and other routers within the AS can be aware of the validation status of the FC-BGP UPDATE messages and make routing decisions accordingly. As stated in {{fcbgp-update}}, when an FC-BGP speaker decides to forward a syntactically correct FC-BGP UPDATE message, it is RECOMMENDED to do so while preserving the FC path attribute. This recommendation applies regardless of the validation state of the UPDATE message. Ultimately, the decision to forward the FC-BGP UPDATE message with the FC path intact and the choice to perform independent validation at the egress router are both determined by local policies implemented within the AS. Note that the decision to perform validation on the received FC-BGP UPDATE message is left to the discretion of the egress router, which is the router receiving the message within its own AS. The egress router has the freedom to choose whether or not it wants to independently validate the FC path attribute based on its local policy, even if the FC path attribute has already been validated by the ingress router. This additional validation performed at the egress router helps ensure the integrity and security of the received FC-BGP UPDATE message. @@ -401,7 +401,7 @@ Ultimately, the decision to forward the FC-BGP UPDATE message with the FC path i This section specifies the concrete validation algorithm of FC-BGP UPDATE messages. A compliant implementation MUST have an FC-BGP UPDATE validation algorithm that behaves the same as the specified algorithm. This ensures consistency and security in validating FC-BGP UPDATE messages across different implementations. It allows for interoperability and standardized communication between FC-BGP-enabled networks. -First, the integrity of the FC-BGP UPDATE message MUST be checked. Both syntactical and protocol violation errors are checked. The FC path attribute MUST be present when an FC-BGP UPDATE message is received from an external FC-BGP neighbor and also when such an UPDATE message is propagated to an internal FC-BGP neighbor. The error checks specified in {{Section 6.3. of RFC4271}} are performed, except that for FC-BGP UPDATE messages the checks on the FC path attribute do not apply and instead, the following checks on the FC path attribute are performed: +First, the integrity of the FC-BGP UPDATE message MUST be checked. Both syntactical and protocol violation errors are checked. The FC path attribute MUST be present when an FC-BGP UPDATE message is received from an external FC-BGP neighbor and also when such an UPDATE message is propagated to an internal FC-BGP neighbor. The error checks specified in {{Section 6.3. of RFC4271}} are performed, except that for FC-BGP UPDATE messages, the checks on the FC path attribute do not apply, and instead, the following checks on the FC path attribute are performed: 1. Check to ensure that the entire FC path attribute is syntactically correct (conforms to the specification in this document). 2. For each AS on AS_PATH that has a router certificate in RPKI, check whether the FC path attribute contains a corresponding FC segment whose CASN field has the same value as the AS number. @@ -411,20 +411,21 @@ First, the integrity of the FC-BGP UPDATE message MUST be checked. Both syntacti 6. If the UPDATE message was received from an FC-BGP neighbor that is not a member of the FC-BGP speaker's AS confederation, check to ensure that the FC Segment corresponding to that peer does not contain a Flags field with the Flags-CS flag set to 1. 7. If the UPDATE message was received from an FC-BGP neighbor that is a member of the FC-BGP speaker's AS confederation, check to ensure that the FC Segment corresponding to that peer contains a Flags field with the Flags-CS flag set to 1. 8. If the UPDATE message was received from a neighbor that is not expected to set Flags-RS bit to 0 (see {{fcbgp-update}}), then check to ensure that the Flags-RS bit in the most recently added FC Segment is not equal to 0. -9. If the UPDATE message was received from a neighbor that is expected to set Flags-RS bit to 0 (see {{fcbgp-update}}), then check to ensure that the Flags-RS bit in the most recently added FC Segment is equal to 0. -10. If the UPDATE message was received from a neighbor that is not expected to set Flags-OTC bit to 1 (see {{fcbgp-update}}), then check to ensure that the Flags-OTC bit in the most recently added FC Segment is not equal to 1. -11. If the UPDATE message was received from a neighbor that is expected to set Flags-OTC bit to 1 (see {{fcbgp-update}}), then check to ensure that the Flags-OTC bit in the most recently added FC Segment is equal to 1. +9. If the UPDATE message was received from a neighbor that is not expected to set the Flags-ASPP bit to 0, i.e., the AS doesn't use the ASPP mechanism, then check to ensure that the Flags-RS bit in the most recently added FC Segment is not equal to 0. +10. If the UPDATE message was received from a neighbor that is expected to set the Flags-RS bit to 0 (see {{fcbgp-update}}), then check to ensure that the Flags-RS bit in the most recently added FC Segment is equal to 0. +11. If the UPDATE message was received from a neighbor that is not expected to set the Flags-P2C bit or Flags-P2P bit to 1 (see {{fcbgp-update}}), then check to ensure that the Flags-P2C bit or Flags-P2P bit in the most recently added FC Segment is not equal to 1. +12. If the UPDATE message was received from a neighbor that is expected to set the Flags-P2C bit or Flags-P2P bit to 1 (see {{fcbgp-update}}), then check to ensure that the Flags-P2C bit or Flags-P2P bit in the most recently added FC Segment is equal to 1. If any of the checks for the FC path attribute fail, indicating a syntactical or protocol error, it is considered an error. In such cases, FC speakers are REQUIRED to handle these errors using the "treat-as-withdraw" approach as defined in {{RFC7606}}. This approach means that the FC-BGP speaker SHOULD treat the FC path attribute as if it were a withdraw message, effectively removing the route from consideration. It's worth noting that when a transparent route server is involved, and its AS number appears in the FC (with the Flags-RS bit set to 1), the route server has the option to check if its local AS is listed in the FC. This additional check can be included as part of the loop-detection mechanism mentioned earlier in the specification. -When an AS appears on the AS_PATH of a UPDATE message and has uploaded router certificates in RPKI, it MUST add its FC segment to the FC path attribute. Otherwise, the downstream ASs SHOULD consider that the FC of this AS has been removed by other ASs and the UPDATE message is falsified. +When an AS appears on the AS_PATH of an UPDATE message and has uploaded router certificates in RPKI, it MUST add its FC segment to the FC path attribute. Otherwise, the downstream ASs SHOULD consider that the FC of this AS has been removed by other ASs and the UPDATE message is falsified. -When one FC Segment has set the Flags-OTC flag to 1, the subsequent FC Segments added by the following ASs MUST all set the Flags-OTC flag to 1 in their corresponding FC Segments. The Flags-OTC flag is set to 1 only when the role of its neighbor, to whom the propagator AS sends routes, is Customer, Peer, or RS-Client. +When one FC Segment has set the Flags-P2C flag to 1, the subsequent FC Segments added by the following ASs MUST all set the Flags-P2C flag to 1 in their corresponding FC Segments. The Flags-P2C flag is set to 1 only when the role of its neighbor, to whom the propagator AS sends routes, is Customer or RS-Client. The Flags-P2P flag is set to 1 only when the role of its neighbor, to whom the propagator AS sends routes, is Peer. -The following ingress procedure applies to the processing of the Flags-OTC flag on route receipt: +The following ingress procedure applies to the processing of the Flags-P2C flag and the Flags-P2P flag on route receipt: -1. If a route, with the Flags-OTC flag in the recently added FC Segment, is received from a Customer or an RS-Client, then it is a route leak and MUST be considered ineligible. -2. If a route is received from a Peer (i.e., remote AS with a Peer Role) and with the Flags-OTC flag in both two recently consecutively added FC Segments, then it is a route leak and MUST be considered ineligible. +1. If a route, with the Flags-P2C flag in the recently added FC Segment, is received from a Customer, a Peer, or an RS-Client, then it is a route leak and MUST be considered ineligible. +2. If a route is received from a Peer (i.e., remote AS with a Peer Role) and with the Flags-P2P flag in both two recently consecutively added FC Segments, then it is a route leak and MUST be considered ineligible. Next, the FC-BGP speaker iterates through the FC segments. Once the FC-BGP speaker has examined the signature field in the FC attribute, it proceeds to validate the signature using the supported algorithm suites. However, if the FC-BGP speaker encounters a signature corresponding to an algorithm suite indexed by an Algorithm ID that it does not support, that particular signature is not considered in the validation process. If there are no signatures corresponding to any algorithm suites supported by the FC-BGP speaker, a specific action is taken to ensure the continuity of the route selection process. To consider the UPDATE message in the route selection process, the FC-BGP speaker has to treat the message as if it were received as an unsigned BGP UPDATE message. By treating the UPDATE message as unsigned, the FC-BGP speaker acknowledges that it cannot verify the integrity and authenticity of the message through the provided signatures. However, it still allows the message to be considered for route selection, ensuring that important routing information is not disregarded solely due to the lack of supported signature algorithms. @@ -619,15 +620,17 @@ Suppose the distance between AS(m), i.e., the compromised AS, and AS(n) is L hop In the full path deployment scenario, i.e., `K=N+1`, FC-BGP and BGPsec have the same path protection rate. However, in the partial path deployment scenario, i.e., `K