On Fri, Jun 05, 2026 at 05:42:02AM +0000, [email protected] wrote: > 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).
thanks > Please review and send your comments to the mailing list by June 11 2026. > > 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. Perhaps add something to acknowledge that as extended communities can be used in the construction of private networks, the potential exposure of extended communities into public networks poses a security risk. A few paragraphs down there is text that starts with "to prevent infoleak / privacy breach", but that doesn't explicitly tie the risk to the origin of the risk: extcomms are used as described in the paragraph above. > 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. I had to read all the way down to this buried in the last paragraph seond second sentence... to find this super useful reco to strip all extended communities by default! I would recommend to make the last sentence its own bullet point. I.e.: > * 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. Kind regards, Job _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
