Hi Folks, This review call for Security Section of draft-ietf-idr-rfc4360-bis-07 is now closed. Draft version -08 seems to have incorporated review comments received so far.
Best Regards, Keyur From: Keyur Patel <[email protected]> Date: Thursday, June 4, 2026 at 4:18 PM To: Nat Kao <[email protected]>; Ketan Talaulikar <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; idr@ietf. org <[email protected]> Subject: [Idr] One week review for Security Section of draft-ietf-idr-rfc4360-bis-07 (06-04-2026 - 06-11-2026) ****Sender is not from Arrcus*** Hi Folks, The security consideration section of draft-ietf-idr-rfc4360-bis-07 has changed significantly as part of our AD review and chairs wanted to ensure that working group members had a chance to review it. The GitHub PR is at https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/pull/58 where you can find the updated draft text for the Security section. Please review and send your comments to the mailing list by June 11 2026. Best Regards, Keyur Suggested Text from authors: 9. Security Considerations The BGP Extended Communities provide a general mechanism for labeling BGP routes and thus share security considerations similar to BGP Communities [RFC1997] and BGP Large Communities [RFC8092]. Additionally, extended communities are used in several specialized ways to implement or augment other BGP signaling mechanisms. For example, the route-target extended community, defined in this document, is used to signal Layer 3 VPN membership. Since any intermediate AS in the path may have added, deleted, or altered the BGP Extended Communities attribute, an AS relying on such an attribute carried in the BGP Update message must have trust in every other AS in the path. Specifying the mechanism to provide such trust is beyond the scope of this document. The BGP Extended Communities attribute itself does not protect the integrity of each extended community value. The operator should be aware that any BGP speaker along the path can alter the attribute without notice. Protecting the integrity of the handling of BGP Extended Communities attribute in a manner consistent with the intent of expressed BGP routing policies falls within the broader scope of securing BGP and is therefore not addressed here. To prevent information leakage or privacy breach across different administrative domains, proper filtering of the extended communities should always be exercised: * Operators should filter transitive and non-transitive extended communities at the boundary of different administrative domains on both transmission and reception using appropriate routing policies, since this prevents extended communities outside the administrative domain from interacting inappropriately with the operator's network. * Implementations should provide policy mechanisms to filter extended communities based on type, and possibly sub-type, to permit filtering the entire class of extended communities. Implementations may also provide the flexibility to match or inverse-match a set of extended communities for building permit/ deny lists. * Implementations that understand the internal format of a defined extended community should provide per-community match capability. Implementations that don't understand the internal format may match against the value field opaquely. * Implementations should provide mechanisms to strip all extended communities at the boundary of administrative domains. Implementations may strip all extended communities by default while providing knobs to modify the default behavior. [EXTERNAL]
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
