Thanks Med. Please note that this is a bis document for something widely implemented, deployed, and serving as the base for many ECs used for features outside of Global Internet Routing. These changes resulted from my "nudge" to do "some more" in the form of security and operational considerations.
I request that SIDROPS and GROW weigh what can be covered in this document as Proposed Standard and what may be more suited for a separate Informational/BCP document. Thanks, Ketan On Fri, Jun 5, 2026 at 11:12 AM <[email protected]> wrote: > 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]> 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]
