[Idr] Re: I-D Action: draft-braet-idr-bgp-source-selective-attr-00.txt

[Robert Raszuk <[e-mail]>]

Hi,

I understand what you are suggesting, but I am not clear how you envision
deployment of it in the Internet.

Imagine this is a success and every ISP will cut their block in half and
advertise source filtering for some class of their customers who wish to be
filtered.

That means we will see 2 fold grow of IPv4 and IPv6 address space. But
let's put that aside.

That also means that if every ISP just serves 100 willing to be filtered
customers and each customer will be allowed to talk to 20 destinations will
will see say 0.5M * 2,000 = 1,000,000,000  src-dst  ACLs in the internet
(sure for those who want to filter it. What hardware today supports such
number of dynamic ACLs ?

If you want to protect your customers why don't you just filter when the
packets enter your network ? And never leak this new SOURCE_SELECTIVE Path
Attribute to the Internet ? If you scope it as such it may not be perhaps a
bad idea ...

Thx,
Robert


On Fri, Jun 19, 2026 at 3:30 PM Braet, Kamiel <[e-mail]>
wrote:

>
> Hi Robert, thank you for reviewing the draft and providing this feedback.
> Please see my responses inline below.
>
> > Hi Kamiel,
> >
> > Based on what I understand as expressed in the Abstract and Introduction
> sections your intention is to explicitly list blocks of sources which may
> send traffic towards you (as in BGP advertisement).
> >
> > "These objects are created by prefix holders to define sources
> authorized to originate traffic toward their prefixes or subprefixes."
> >
> > +
> >
> > "1. Introduction
> >
> > BGP provides reachability information for IP prefixes, but does not
> express which sources are authorized to send traffic to those prefixes.
> Destination networks must rely on out-of-band mechanisms to express
> source-based intent, particularly for denial-of-service mitigation,
> infrastructure protection, and restricted-access services."
> >
> > With that I have a few questions:
> >
> > #1 - Today everyone is allowed to send traffic towards any reachable
> destination. How are you going to change that ? Do you expect that any BGP
> network node upon receiving the BGP SOURCE_SELECTIVE Attribute to now
> install in the data plane an ACL blocking any other traffic to advertised
> destination except if originated by listed src address ?
> >
>
> [Kamiel Braet]: BGP nodes that support the SOURCE_SELECTIVE attribute MAY
> implement a data plane filtering mechanism blocking traffic destined to the
> protected prefix, if the traffic is not sourced from the prefixes listed in
> the referred RPKI Source Prefix Authorization (SPA) object. Is it not
> mandatory for all BGP nodes to support this attribute, as the proposal
> inherently support incremental deployment.
>
> >
> > #2 - How safe with current BGP security in place would be such an action
> in practice ?
>
> [Kamiel Braet]: Source-Selective BGP (see also
> draft-braet-idr-source-selective-bgp-framework) is intended as part of a
> layered security approach for Internet endpoints. When network operators
> deploy support for the SOURCE_SELECTIVE attribute and combine this with
> Source Address Validation (SAV), the destination networks are expected to
> see a significant reduction in DDoS attacks and unauthorized malicious
> traffic.
>
> >
> > #3 - Have you considered instead defining a new object in FlowSpecv2 to
> accomplish such a data plane permit type of filtering ?
>
> [Kamiel Braet]: BGP SOURCE_SELECTIVE allows holders of IP prefixes to
> leverage the RPKI to define authoritative source-filtering policies for
> incoming traffic. Unlike FlowSpec, which is typically reactive and dynamic,
> using RPKI ensures that networks deploying these policies can
> cryptographically verify that the legitimate holder of the destination
> prefix authorized the policy, preventing unauthorized filtering.
>
> >
> > #4 - What protocols would you expect to get filtered ? All ? Even ICMP
> replies ? If so, how would you know which src addresses would be sending
> you ICMP replies ?
>
> [Kamiel Braet]: Filtering applies globally to the prefix at the network
> layer (Layer 3). Therefore, all protocols—including ICMP/ICMPv6—from
> unlisted sources are explicitly filtered. Allowing blanket exemptions for
> ICMPv6 would re-introduce a data-plane DDoS exploitation vector against the
> protected prefix.
>
> I acknowledge that a strict Layer 3 drop policy causes a known
> architectural conflict with IPv6 Path MTU Discovery (RFC 8201), as incoming
> ICMPv6 Packet Too Big (PTB) messages from unlisted intermediate transit
> routers will be dropped, resulting in a black-hole connection.
>
> Because of this limitation, Source-Selective BGP is strictly intended for
> highly structured, static infrastructure environments where the Path MTU is
> static and known beforehand. Alternatively, communicating endpoints (hosts
> and applications) within these networks must deploy transport-layer
> adaptations, such as Datagram Path MTU Discovery (DPLPMTUD - RFC 8899) or
> explicit TCP MSS clamping, to safely manage packet sizing without relying
> on network-layer ICMPv6 messages.
>
> I will add an explicit "Operational Considerations on IPv6 PMTUD and ICMP
> Handling" section to the next revision of the draft to detail these
> trade-offs and endpoint requirements.
>
> >
> > #5 - How would it work if your customers ( PA or private with src nat)
> are tunneling to any arbitrary VPN destination in the world and you have no
> way to know those destinations ? Is this purposely intended to spoil the
> fun for those guys ?
>
> [Kamiel Braet]: If an endpoint within the protected prefix needs to
> establish tunneling to an arbitrary VPN destination, Source-Selective BGP
> would indeed block unlisted return traffic. This mechanism is not intended
> for general, highly dynamic residential or enterprise outbound web traffic.
> Instead, it is optimized for infrastructure protection and communication
> channels of a relatively static nature. For concrete use cases, please
> refer to draft-braet-idr-source-selective-bgp-framework.
>
> >
> > Thx,
> > Robert
>
>
> ---------- Forwarded message ---------
> From: <mailto:[e-mail]>
> Date: Thu, Jun 18, 2026 at 11:29 AM
> Subject: I-D Action: draft-braet-idr-bgp-source-selective-attr-00.txt
> To: <mailto:[e-mail]>
>
>
> Internet-Draft draft-braet-idr-bgp-source-selective-attr-00.txt is now
> available.
>
>    Title:   BGP Source-Selective Attribute
>    Author:  Kamiel Braet
>    Name:    draft-braet-idr-bgp-source-selective-attr-00.txt
>    Pages:   14
>    Dates:   2026-06-18
>
> Abstract:
>
>    This document specifies a new Border Gateway Protocol (BGP) Path
>    Attribute, the BGP SOURCE_SELECTIVE Attribute.  This attribute allows
>    BGP speakers to reference Resource Public Key Infrastructure (RPKI)
>    Source Authorization (SA) objects, including Source Prefix
>    Authorization (SPA), within BGP UPDATE messages.  These objects are
>    created by prefix holders to define sources authorized to originate
>    traffic toward their prefixes or subprefixes.  Receiving BGP speakers
>    can use this information to enforce security policies.
>
>    The SOURCE_SELECTIVE Path Attribute supports multiple Source
>    Authorization Identifier (SA-ID) fields to preserve authorization
>    semantics during BGP route aggregation and summarization.
>
>    This mechanism applies to BGP AFI 1 / SAFI 1 (IPv4 Unicast) and AFI 2
>    / SAFI 1 (IPv6 Unicast).
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-braet-idr-bgp-source-selective-attr/
>
> There is also an HTMLized version available at:
>
> https://datatracker.ietf.org/doc/html/draft-braet-idr-bgp-source-selective-attr-00
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list -- mailto:[e-mail]
> To unsubscribe send an email to mailto:[e-mail]
>