[Idr] Closed - One week review for Security Section of draft-ietf-idr-rfc4360-bis-07 (06-04-2026 - 06-11-2026)

[Keyur Patel <[e-mail]>]

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 <keyur=[e-mail]>
Date: Thursday, June 4, 2026 at 4:18 PM
To: Nat Kao <[e-mail]>; Ketan Talaulikar <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; idr@ietf. org <[e-mail]>
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]