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

[Robert Raszuk <[e-mail]>]

Hi Kamiel,

> That is exactly what Source-Selective BGP (SSB) is about.
Source-Selective BGP (SSB)
> is not designed for temporary reactive, granular DDoS mitigation rules.
Instead, it addresses
> the scenarios where an organization wishes to expose a service on the
Internet exclusively
> to a predetermined set of source prefixes in a relatively stable and
static manner.

So tell me if I am an end user who pays for this "service". How can I use
it from a mobile phone when I am in motion and likely also roaming ? How
can I use it from my laptop when I travel ? How useful is this service in
practice ?

And assume this is only for fixed line sites ... but then the src IP
address may change if such sites are connected over NAT or even PA space.

Also note that you are automatically cutting the source of the SSBs from
use of IP tunnels as you usually have no control what source addresses are
entering your tunnel. So if this would surface in real life I can already
see a number of proxies popping up in your network (well in your direct
customer's networks) to allow any src IP address to get in bypassing this
entire SSB game all together.

I fully understand what you are proposing but have a little bit of a hard
time to see how this helps in real life.

Moreover as others already stated the business aspect of this is highly
questionable. Why should I filter anything permanently for your network ?

Note also that you are not allowing to expose a service to controlled
sources. You are only doing the granularity of the address block. No ports,
no protocols ... so you are aiming to control IP reachability not service.

My gut feeling is that this is beyond IDR. Sure defining BGP extensions or
new attributes can be done here but bigger discussion would be needed maybe
in RTG Area WG if this approach is acceptable.

Last this draft is written as a standard track ... I think and only with
significant support from other operators willing to accept and apply such
attributes at most this draft should be of Experimental status.

Cheers,
R.


On Tue, Jul 7, 2026 at 9:53 AM Braet, Kamiel <[e-mail]>
wrote:

> Hi Robert,
>
> > Hi Kamiel,
> >
> > > Now how to limit the blast radius. I would highly recommend to apply
> within the new attribute
> > > (on scope it to the new attribute) the same principles and mechanism
> as described by Tony nearly
> > > 20 years ago:
> > >
> > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-as-pathlimit-03
> > >
> > > Note that such an approach could also be used for FlowSpec based
> interdomain propagation.
> >
> > Thank you for pointing out this very interesting Pathlimit proposal. A
> similar approach for
> > the SOURCE_SELECTIVE attribute should indeed be considered to scope it
> to the AS networks
> > expected to implement the SSB policy. For example the local ASN and
> directly adjacent ASNs
> > only.
> >
> > Well yes if you scope it like this it may be much more feasible then as
> written.
> >
> > To your other comment to Gert ..
> >
> > > Furthermore, SSB provides an alternative for endpoint customers who
> > > want to maintain direct architectural control over their traffic
> flows. By
> > > mitigating attacks via BGP at the infrastructure layer, they avoid the
> > > operational dependency of routing transit through third-party Cloud
> > > WAF providers, preserving end-to-end encryption and native path
> > > control.
> >
> > No one is forcing them to go to a third party cloud for screening. There
> are a number of devices
> > available today to detect attacks and mitigate them locally + propagate
> such mitigation to your
> > upstreams.
> >
> > That is *exactly* why we wrote FlowSpec for.
> >
> > Your model is 180 degrees different. You are not asking to filter attack
> vectors.
> >
> > You are saying I advertise in BGP prefix X say X/16 but I am also
> attaching the SSB attribute to
> > say ... Oh within my X/16 I have X.Z/24 and this can only be reached by
> S1, S2, S3 ... I do not want
> > to hear from anyone else to X.Z/24
> >
>
> [Kamiel Braet]:
>
> That is exactly what Source-Selective BGP (SSB) is about. Source-Selective
> BGP (SSB)
> is not designed for temporary reactive, granular DDoS mitigation rules.
> Instead, it addresses
> the scenarios where an organization wishes to expose a service on the
> Internet exclusively
> to a predetermined set of source prefixes in a relatively stable and
> static manner.
>
> While an organization can enforce this policy locally using a static
> firewall allowlist, doing
> so does not prevent uplink congestion during a DDoS attack. SSB provides a
> control-plane
> and RPKI driven mechanism for organizations to extend this static
> source-validation policy
> upstream into the high-capacity networks of their transit providers that
> can successfully
> absorb DDoS attacks.
>
> Why not simply use BGP FlowSpec (or fsv2-ip-basic) for customer allowlists?
>
> To clarify the architectural scope, Source-Selective BGP (SSB) is designed
> to solve a
> different set of scaling and deployment challenges than a FlowSpec-based
> approach.
> While fsv2-ip-basic focuses on reactive Layer 3 filtering and the broader
> FlowSpec v2
> specification handles fine-grained L4 application policy enforcement, SSB
> focuses on
> preventive, permanent infrastructure-level source validation boundaries.
>
> We see the architectural trade-offs and advantages of SSB for high-scale,
> permanent
> deployments across four key areas:
>
> * Cryptographic Validation Mechanics: FlowSpec's core design excels at
> propagating
> highly dynamic filtering states, where inter-domain validation often
> relies on complex,
> localized inbound BGP route policies. Conversely, because SSB focuses on
> stable,
> long-term source authorization, it cleanly inherits and implicitly aligns
> with the
> existing RPKI framework. This allows prefix holders to cryptographically
> signal
> source-based constraints directly across multiple AS boundaries without
> increasing
> local administrative policy overhead.
>
> * Predictable Resource Allocation and Isolation: FlowSpec updates
> typically translate
> into shared hardware filter tables (such as TCAM), where ensuring
> multi-tenant isolation
> under heavy or overlapping rule sets requires strict prefix limits
> (maximum-prefix). SSB
> mitigates this resource contention by decoupling the policy scale from the
> filter block.
> Because it functions as a native routing constraint, it can leverage
> existing
> multi-tenant hardware constructs already proven at scale in L3VPN/VRF
> architectures,
> providing strict resource isolation per prefix holder.
>
> * Deterministic Forwarding Plane Hierarchies: Evaluating multi-tuple, flat
> policy tables
> can introduce computational and parsing overhead when scaled permanently
> across the
> global internet. SSB integrates seamlessly into existing routing
> structures using a
> two-stage Longest Prefix Match (LPM) model. The initial lookup occurs
> entirely within
> the global routing table tree, and a secondary source lookup is triggered
> strictly when
> an SSB-protected destination prefix is matched.
>
> * Leveraging Proven Fixed-Length Abstractions: To ensure hardware-rate
> processing, an
> SSB implementation can prepend an internal, operator-assigned Policy
> Identifier to the
> incoming Source IP. For example, using a 16-bit identifier scales up to
> 64k isolated customer
> policies; when combined with the SSB specified maximum IPv6 prefix length
> of 64 bits, the
> resulting secondary lookup is strictly capped at a deterministic 80 bits.
> This allows hardware
> to maintain fixed, predictable memory access cycles without requiring
> specialized or new
> forwarding engines.
>
> >
> > So with that let me ask you the question ... what do you do if attackers
> are smart and
> > spoof src address to only allowed by SSB blocks ?
> >
> > You are advertising those blocks so they become public information. In
> fact if I would
> > be attacker I would fish for SSB attribute and attack only those as a
> priority :)
> >
>
> [Kamiel Braet]:
>
> You are entirely right that the SSB attributes and Source Prefix
> Authorization (SPA) objects
> are public information in the control and the management plane
> respectively. However,
> knowing the allowed source blocks does not give an attacker a free pass
> through the data
> plane.
>
> Public visibility of a policy does not equate to data-plane vulnerability
> when combined with
> topology-aware ingress filtering.
>
> At a settlement-free Tier-1 peering boundary, implementing strict source
> validation across
> massive, asymmetric customer cones is an industry-wide challenge. Neither
> ROAs nor ASPA
> fully solves data-plane spoofing at a transit edge today; ultimately,
> operators rely on policy
> boundaries and ingress policing at their perimeters.
>
> Because of this structural reality, SSB is designed for an incremental,
> topologically bounded
> deployment that natively prevents the spoofing vectors you described:
>
> Phase 1: Intra-provider / Customer Cone Scoping
>
> Initially, the scope of an SSB policy is strictly limited to authorized
> source prefixes residing
> within that specific operator's own downstream customer cone (potentially
> utilizing the
> AS_PATHLIMIT concepts discussed earlier). This explicit topological
> boundary allows the
> operator to enforce deterministic data-plane checks at its network edge:
>
> * External Spoofing: If an attacker outside the network attempts to spoof
> an allowed internal
> source prefix, those packets must enter the operator's network via
> external peering or transit
> links. Because the operator's routing table knows these legitimate source
> prefixes reside strictly
> within its own downstream customer cone, any traffic bearing those source
> IPs arriving from an
> external peer fails a feasible-path lookup and is dropped immediately at
> the peering edge.
> * Internal Spoofing: If a spoofed packet originates from within the
> customer cone itself, it hits
> the strict ingress SAV (BCP38) boundaries already enforced at the
> subscriber access edge,
> where it is discarded before ever reaching the core.
>
> Phase 2: Interconnected Islands of Trust
>
> As these deployments mature and SAV-compliant autonomous systems
> interconnect, operators
> can expand their SSB policies to include allowed source prefixes
> originating from those trusted,
> SAV-compliant networks.
>
> Over time, this builds an organic, globally scalable mesh of protected
> source paths. SSB relies on
> a pragmatic operational reality: while an edge router cannot validate the
> source of every arbitrary
> global packet on day one, it can validate that a specific destination
> prefix has a legitimate,
> cryptographically signed RPKI SPA object. This anchors control-plane
> intent precisely where
> downstream data-plane enforcement is operationally feasible today.
>
> Additionally, this architecture helps to address the historical economics
> roadblock of Source
> Address Validation (SAV). Widespread SAV deployment has long suffered from
> an incentive
> misalignment, where the network bearing the operational cost of filtering
> does not receive the
> direct security benefit. By providing an explicit, policy-driven control
> plane, SSB creates a clear
> commercial and operational incentive for transit providers. Operators can
> now offer verifiable,
> high-scale preventive DDoS protection to their enterprise and partner
> customers, directly
> justifying and recovering the costs of rigorous SAV deployment.
>
> From an Internet operations philosophy, security mechanisms should strive
> to be transparent,
> auditable, and structurally secure. Utilizing FlowSpec as a temporary,
> reactive emergency
> mechanism to mitigate active attacks is highly effective and widely
> accepted. However,
> implementing permanent, opaque, and anonymous traffic filters across the
> global Internet for
> preventive defence may be a step too far, as it introduces systemic
> operational risk and
> complicates inter-domain troubleshooting. SSB addresses long-term
> preventive DDoS defence
> in alignment with the Internet's foundational values: by ensuring that the
> source policy remains
> public and verifiable via the RPKI, it allows adjacent and remote networks
> to troubleshoot
> connectivity issues cleanly, while the data plane safely enforces
> topological boundaries.
>
> Regards,
> Kamiel
>
> >
> > Cheers,
> > Robert
>