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

["Braet, Kamiel" <[e-mail]>]

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