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

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

Hi Gert,

Thank you for the excellent feedback. These operational and economic 
aspects are critical for the viability of this attribute.

Please see my responses below on how the proposal addresses both the 
commercial incentives and hardware constraints:

> Hi,
> 
> On Tue, Jun 23, 2026 at 09:19:34AM +0000, Braet, Kamiel wrote:
> > To ensure scalability, the enforcement model prioritizes the ingress 
> > points of the downstream transit providers closest to the protected 
> > destination network. The destination's immediate ISP MUST enforce the 
> > policy, and its directly adjacent upstream peers (such as Tier-1 
> > transit networks) SHOULD enforce the policy at their external 
> > boundaries. This localized upstream enforcement provides massive 
> > aggregate bandwidth capacity to absorb and drop multi-terabit DDoS 
> > attacks before they saturate the target's
> 
> How does the commercial model here look like?  That is, if I'm a Tier 1, 
> and am expected to filter this at my edges for a customer for all the 
> other Tier 1 ISPs, who will pay for the invest in router hardware?
> 

For a Tier-1 or large transit provider, the commercial incentive is driven by 
providing on-demand infrastructure security capabilities and core traffic 
optimization.

1. On-Demand Security Capabilities: Enabling SOURCE_SELECTIVE (SSB) 
allows Tier-1 networks to offer scalable, destination-driven DDoS mitigation 
capabilities to their downstream transit customers. Downstream networks
 often lack the aggregate edge capacity to absorb multi-terabit attacks 
independently. By utilizing SSB, these networks can explicitly signal and 
automate source-selective filtering at the Tier-1's global ingress boundaries,
protecting their infrastructure from saturation through standard, 
recipient-requested security enforcement.

2. Traffic Optimization: Dropping malicious traffic at the Tier-1 peering 
edge prevents that unwanted volume from traversing the Tier-1's internal 
backbone. This frees up internal capacity and reduces core transport 
overhead.

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.

>
> "Massive interface speed" forwarding engines are usually not the ones 
> with "massive ACL capacity", unless you put the very big bucks on the 
> table.
> 
> (And if the assumption is "does not need to propagate beyond my direct 
> chain of upstream ISPs to the first Tier 1", then "buy from upstream 
> ISPs that offer netflow" sounds like an easier avenue than "change all 
> BGP implementations upstack")
>

This is a very fair point, and hardware constraints were a primary driver 
in the design of the SSB attribute.

SSB restricts its filter logic strictly to destination and source IP prefixes 
(enforcing a maximum /64 boundary for IPv6 source evaluations), removing 
Layer 4 complexities like ports and protocols, allowing for a significantly 
more scalable implementation. 

This means that for SSB filtering, a second source prefix lookup along with
the protected prefix identifier is sufficient. Furthermore, this only applies to 
traffic matching an activated protected prefix, whereas regular traffic filter
logic typically needs to be processed for all traffic.
As such, SSB optimizes resource consumption and, consequently, the 
value of these well positioned traffic filter resources for Internet users.

Please note that implementing the attribute remains completely optional. 
Operators can choose to support it only where their hardware budgets, 
capacity, and customer demands permit.

> 
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?