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

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

Hi Maria, thank you for reviewing and providing your feedback. Please see my responses inline below.

> Howdy!
> 
> On Fri, Jun 19, 2026 at 01:30:50PM +0000, Braet, Kamiel wrote:
> 
> > "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.
> 
> First, not signing the SOURCE_SELECTIVE attribute is going to add an
> opportunity for random weirdos on the path to tamper with that. And if
> you sign it, we are back at the BGPsec problem.
> 

[Kamiel Braet]: I acknowledge that securing BGP path attributes without inheriting the deployment complexities of 
BGPsec (RFC 8205) is a fundamental inter-domain challenge. The architecture explicitly manages this risk by decoupling 
the path-layer signalling from the policy-layer authorization.

Because the SOURCE_SELECTIVE attribute functions purely as a lookup pointer rather than a source of policy truth, 
a malicious actor tampering with or injecting arbitrary SA-ID TLVs on-path cannot forge cryptographically signed 
RPKI payloads. The receiving router MUST validate any referenced policy against its local cache of Validated SPA 
Payloads. If an on-path actor alters a TLV to point to a sub-prefix, that lookup will fail to match a legitimate, 
cryptographically signed Source Prefix Authorization (SPA) object, and no data-plane packet filters will be installed.

The worst-case impact of an on-path actor manipulating or stripping this unsigned attribute is missing packet filter 
activation somewhere along the forwarding path on the source side. This means that unauthorized traffic destined to 
the Protect Prefix is dropped at a later stage in its path.

By relying on the RPKI as our cryptographic anchor to verify the data-plane intent, the protocol suite provides robust 
security at the edge while deliberately avoiding the path-signing and performance constraints that have hindered BGPsec 
deployment.

See also Section 11.5 of draft-braet-idr-source-selective-bgp-framework

> Second, imagine receiving two routes for the same network, one with
> AS_PATH length 3, with SOURCE_SELECTIVE, and another one with AS_PATH
> length 5 with no such attribute. What should a speaker do with that
> situation?
> 

[Kamiel Braet]: The scenario where a BGP route originally carries the SOURCE_SELECTIVE attribute but loses it along the 
propagation path is an expected operational reality. Per the protocol design, the presence or absence of the 
SOURCE_SELECTIVE attribute MUST NOT influence the BGP Decision Process (tie-breaking) or route selection. Instead, the 
attribute is evaluated only after a route has been selected as the best path, serving purely to inform the router of the
associated source-filtering policies. See also Sections 1, 3, and 3.1 of draft-braet-idr-bgp-source-selective-attr-00.

> 
> > > #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.
> 
> This whole idea depends on SAV actually being deployed virtually
> everywhere, probably together with ASPA and ROA. As soon as there is any
> opening, an adversary is motivated to blast your network with
> forged traffic from approved addresses.
>

[Kamiel Braet]: Source-Selective BGP (SSB) does indeed depend heavily on Source Address Validation (SAV). Operators implementing
Source-Selective BGP SHOULD have a solid SAV mechanism in place for the source prefixes included in SSB. 

> 
> > > #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.
> 
> What about publishing and signing FlowSpec objects, or better their
> hashes to actually not disclose their contents publicly, to achieve the
> same result?
>

[Kamiel Braet]: FlowSpec is highly useful for reactive DDoS attack mitigation at a very granular level, 
as opposed to the proactive, lightweight prefix-to-prefix filtering proposed with Source-Selective BGP.
Even if FlowSpec objects were cryptographically signed or integrated with the RPKI as you suggest, using 
FlowSpec to statically advertise Source Prefix Authorization across the Internet would introduce 
significant BGP control-plane burden and hardware TCAM scaling overhead compared to the lightweight, 
prefix lookup model proposed here.

> 
> > > #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.
> 
> You are also killing any traceroute functionality or unreachability
> notifications on the way. Every intermittent failure will result
> in a blackhole impossible to debug.
> 
> There is no structured static infrastructure environment when two sites
> are connected over the Internet. You have no Path MTU static and known
> beforehand.
> 

[Kamiel Braet]: You are entirely correct that an outbound traceroute initiated from within the specific 
Protected Prefix will indeed fail. This is an operational trade-off of the strict "filter-all" approach. 
To completely eliminate data-plane DDoS injection vectors, the protocol prioritizes deterministic traffic 
isolation over traditional out-of-band network diagnostics. 

However, because the policy can target granular sub-prefixes (such as a single host IPv4 /32 or IPv6 
/64), operators have a practical way to perform path diagnostics. If the Protected Prefix is a sub-prefix
of a larger advertised route, an engineer can successfully execute a traceroute by simply sourcing the 
diagnostic packets from an IP address that falls outside the Protected Prefix range, but within the same 
aggregate block. Since that diagnostic source IP is not restricted by an SSB policy, the incoming ICMP 
replies from intermediate transit routers will pass through the boundary unimpeded, allowing full path 
visibility.

Regarding path dynamics and MTU: hosts do not need to rely on reactive network-layer ICMP/ICMPv6 
signaling. Instead, communicating endpoints can deploy Datagram Path MTU Discovery (DPLPMTUD - RFC 
8899). Because DPLPMTUD statefully probes using authorized application traffic, it automatically 
adapts to mid-session MTU shifts independent of the network core. Alternatively, TCP MSS clamping 
or mandating a conservative MTU floor can be considered. 

Thank you for bringing these important points forward. I will ensure that this traceroute behavior, 
the sub-prefix diagnostic workaround, and the endpoint-driven MTU mitigation strategies are fully 
documented in the "Operational Considerations" section of the next draft revision.


> [...]
> 
> Various notes:
> 
> - I see no reason why to make this a whole new attribute. It can be yet
>   another Extended Community, transitive. That would make it easier to
>   inspect and configure even without support in the routing stack.
> 

[Kamiel Braet]: Using a transitive BGP Extended Community (RFC 4360) is definitely an interesting idea 
for simplifying initial inspection and configuration. During the early design phases, I did consider 
using communities, but ultimately chose a dedicated Path Attribute to handle a few specific BGP 
control-plane behaviors:

First, regarding route aggregation: when a BGP speaker summarizes routes, standard BGP behavior typically
drops the extended communities attached to the contributing paths rather than carrying them over to the
new aggregate advertisement. For Source-Selective BGP, it is important that these filtering signals survive
aggregation. By using a dedicated Path Attribute, we can explicitly define the aggregation rules (as 
described in Section 4.6) so that a router can extract and merge multiple SA-ID TLVs from contributing 
routes into the summary advertisement.

Second, regarding inter-domain propagation: in many real-world deployments, standard and extended 
communities are stripped at external BGP (eBGP) boundaries by default unless manually configured otherwise 
by the operators. Since this security policy benefits from global propagation across the default-free zone 
(DFZ) for visibility and upstream enforcement, an optional transitive Path Attribute provides a more 
automated way to ensure the signal passes through eBGP hops seamlessly.

Third, regarding data capacity and structure: an Extended Community has a fixed 8-byte payload. Because 
the SOURCE_SELECTIVE mechanism needs to carry a list of SA-ID TLVs with variable-length prefix metadata 
(such as an IPv4 /32 address or an IPv6 /64 prefix), a structured Path Attribute accommodates this variable 
length and keeps the policy information neatly bundled together.

Thank you for raising this point, as it helps clarify why a dedicated attribute was chosen for the protocol 
design. I will make sure to add a small "Design Alternatives Considered" note in a future version of the 
draft-braet-idr-source-selective-bgp-framework draft to document this community comparison.

> 
> - Also, there MAY be a way out of this by interpreting this
>   attribute / EC also as a filtering request, i.e. "send this route only
>   to approved networks" → but that doesn't work when you wanna carve out
>   only part of the network as unreachable from the global Internet.
>
> 
> All in all, the whole proposal is quite easy to implement but I'm not
> sure about its feasibility.
> 

[Kamiel Braet]: Thank you for this valuable feedback. The intent of this design is precisely to build on the
established foundations of BGP and RPKI. By limiting the protocol modifications as much as possible, I hope
to ensure that it remains relatively straightforward to implement and fully compatible with existing 
forwarding hardware.

> -- 
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.