Hi Ketan, all, Thank you for sharing. Adding GROW as well as some relevant discussion already is happening there as well (not to mention guidance in draft-ietf-grow-ixp-ext-comms).
Cheers, Med De : Ketan Talaulikar <[email protected]> Envoyé : vendredi 5 juin 2026 07:07 À : Keyur Patel <[email protected]> Cc : Nat Kao <[email protected]>; [email protected]; [email protected]; idr@ietf. org <[email protected]>; SIDRops IETF <[email protected]> Objet : [Sidrops] Re: One week review for Security Section of draft-ietf-idr-rfc4360-bis-07 (06-04-2026 - 06-11-2026) + sidrops if they have any feedback/suggestion On Fri, Jun 5, 2026 at 4:44 AM Keyur Patel <[email protected]<mailto:[email protected]>> wrote: 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. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
