| Internet-Draft | BGP SAV Distribution | July 2024 |
| Haas | Expires 23 January 2025 | [Page] |
Source Address Validation (SAV) is a technique that can be used to mitigate source address spoofing. draft-huang-savnet-sav-table codifies the concept of source address validation on a per-incoming interface basis, the validation mode, and the traffic handling policy as a "SAV Table".¶
This document defines a mechanism for distributing logical SAV Tables in BGP. This mechanism is addresses inter-domain SAV use cases. These SAV Tables may be used to implement appropriate device-specific validation for source addresses.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 January 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Introductory text¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terminology is defined in [I-D.huang-savnet-sav-table]:¶
The following terminology is defined in this document:¶
Source address validation can be modeled on a per-interface basis as a match operation on a list of prefixes. Upon a match, or failure to match, a traffic handling policy is applied to the traffic. An instance of a prefix, its validation mode, and its traffic handling policy is a SAV rule.¶
In the inter-domain SAV use case, this set of prefixes consists of the set of upstream networks that may receive the advertised BGP routes, either directly or transitively, where the forwarding element is a BGP next hop. Determining this set of upstream prefixes is the subject of a number of savnet proposals.¶
A given SAV rule may be applied to a number of forwarding elements on the same device, or across multiple devices.¶
It can be observed that a given SAV rule that might be applied to a given interface by a provisioning mechanism follows several common membership criteria:¶
A "SAV Table" may be modeled as the interface-specific list of memberships for SAV rules that share those membership criteria.¶
These properties have some similarity with Layer 3 VPNs. A SAV entry may be modeled as a BGP route that is a member of some number of SAV-D Tables via one or more SAV-D Targets.¶
A SAV-D Route implements an instance of a SAV rule. As noted above, SAV rules consist of a prefix, a validation mode, and a traffic handling policy.¶
A prefix for a SAV-D Route may have a large number of memberships across a deployment. Since baseline BGP is limited by its PDU size to 4096 bytes, the prefix alone cannot be the "NLRI key". In order to permit a large number of memberships for a given prefix, this document defines a new Route Distinguisher. The prefix is encoded in a BGP NLRI with a new SAFI, defined below. The validation mode and traffic handling policies are encoded in new BGP Extended Communities [RFC4360].¶
Type Field: TBD (2 octets) Value Field: 6 octets 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: TBD | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The Global Administrator field contains the BGP Identifier of the BGP speaker originating these SAV-D routes.¶
The Local Administrator contains a locally chosen value that permits unique combinations of SAV-D Routes to be distributed across the deployment.¶
This document defines two new BGP NLRI types, AFI=1/2, SAFI=TBD, which can be used to distribute SAV Rules in BGP. The NLRI format for this address family consists of a fixed-length 8 octet SAV-D RD-Originator followed by a variable-length IPv4 or IPv6 prefix whose length depends on AFI.¶
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Sub-Type: TBD¶
The first five octets of this Extended Community's Value field MUST be zero.¶
The Value of this extended community can be:¶
When traffic has the "Action" match criteria, the traffic is subject to additional processing when supported by the local forwarding element.¶
The following extended communities are re-used from Section 7 of [RFC8955]:¶
The following extended communities are re-used from Section 7 of [RFC8956]:¶
The following extended communities are re-used from [I-D.ietf-idr-flowspec-redirect-ip]:¶
A BGP speaker might not be able to process some or any of the traffic handling actions. Since SAV tables are intended to be provisioned on a per-device per-interface basis, BGP speakers generating SAV-D routes should have an understanding of what features can be implemented by the receiving device and avoid encoding actions that cannot be implemented by that device.¶
The following error handling behaviors are specified for SAV-D routes containing actions:¶
SAV-D Routes are members of one or more SAV-D Tables. This membership is signaled in SAV-D Routes using one or more SAV-D Target Extended Communities.¶
Some SAV-D Targets are node-specific. In order to clearly encode such node-specific SAV-D Extended Communities and appropriately scope them, routes containing SAV-D node-specific Extended Communities MUST contain a single instance of a Node Target Extended Community, [I-D.ietf-idr-node-target-ext-comm].¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD - non-transitive Sub-Type: TBD¶
This is a SAV-D node-specific Extended Community type and requires a Node Target Extended Community for context.¶
The Global Administrator field is set to the ifIndex [RFC1213] of the interface that the SAV Rule is a member of. The Local Administrator field MUST be set to zero.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Value... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ...Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD - non-transitive Sub-Type: TBD¶
This is a SAV-D node-specific Extended Community type and requires a Node Target Extended Community for context.¶
The 6-octet value is has local significance to the node.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD - non-transitive Sub-Type: TBD¶
The SAV rules are associated with a given neighbor AS of the service provider.¶
The 4-octet Global Administrator field is set to the neighbor AS that the SAV table is attached to. The Local Administrator field MUST be set to zero.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD - non-transitive Sub-Type: TBD¶
The SAV rules are associated with a given originating AS. This membership enables such use cases as including the AS numbers in a customer cone.¶
BGP speakers implementing [RFC8210] and ensuring that all Origin AS state used for SAV rules is present in their RPKI ROA cache MAY obtain the prefixes for their SAV Rules from that mechanism rather than BGP.¶
The 4-octet Global Administrator field is set to the neighbor AS that the SAV table is attached to. The Local Administrator field MUST be set to zero.¶
The method by which a set of SAV Rules is determined for a given interface remains a somewhat contentious discussion. For purposes of this document, it is presumed that a "SAV Controller" exists to calculate the appropriate SAV rules for the deployment and that such a controller implements the extensions defined in this document to provision SAV within the network.¶
Each forwarding element implementing SAV will be provisioned with the per-interface SAV-D memberships for the SAV Rules implemented by that device. This state constitutes a logical SAV Table.¶
The SAV Controller originates BGP SAV-D Routes with appropriate membership Extended Communities to each forwarding element. When the device has matching membership for such SAV-D routes in a SAV Table, it installs that route in that logical SAV Table using the standard BGP Decision Process to choose the best SAV Route when multiple candidate routes exist.¶
[RFC4684] SHOULD be deployed between BGP speakers distributing SAV-D Routes.¶
SAV-D BGP speakers SHOULD originate [RFC4684] routes for SAV-D Neighor-AS and Origin-AS Member Extended Communities. Such routes will attract SAV Rules that may be used in-common across multiple SAV Tables in a deployment.¶
In deployments where it is known that the SAV Controller would be emitting SAV Routes with Origin-AS Member Extended Communities that are identical with the RPKI ROA state carried in RPKI-RTR ([RFC8210]), implementations MAY exclude originating [RFC4684] routes for these Origin-AS Member Extended Communities and instead derive the local SAV Rules for their SAV Tables from the received RPKI-RTR state.¶
Some SAV Routes have membership that is only only node-specific, i.e. contains only node-specific SAV-D Extended Communities. Distribution of these routes to all iBGP speakers within an AS, either via full-mesh iBGP or route reflection, will result in SAV-D BGP speakers receiving SAV Routes they do not care about.¶
SAV-D BGP speakers SHOULD originate [RFC4684] routes for the Node Target Extended Communities. At the same time, such speakers SHOULD NOT originate [RFC4684] routes for SAV-D node-specific Extended Communities. The Node Target Extended Community is sufficient to attract the appropriate SAV-D Routes without needing to expose internal membership details.¶
As an optimization, implementations MAY distribute such node-specific SAV-D Routes using "targeted" BGP sessions. In this case, a dedicated BGP session between a SAV Controller and a SAV-D speaker is used to distribute node-specific BGP routes. Such routes SHOULD be marked with the [RFC1997] NO_ADVERTISE community to prevent further redistribution.¶
Even presuming pervasive and instantaneous deployment of SAV in a network, many documents discuss the problems associated with incomplete SAV information. Such issues can include incorrectly passing traffic that should have been blocked or blocking traffic that should have been passed.¶
Forwarding resources utilized by an implementation to enforce SAV may take time to program. Such programming MUST be in-place with full state and correct prior to enforcement. Failure to do so may result in incorrect enforcement. Implementations SHOULD NOT enable enforcement of SAV until the state is fully programmed.¶
One possible mechanism for controlling the activation of enforcement is careful control of a SAV-D "default" route for the node. In circumstances where SAV Rules are primarily of the form of an allow-list, enforcement of block activity can be modeled as a "default" block action. As long as the default is signaled last and its processing is deferred until other installation of SAV Table state is complete, inappropriate dropping of traffic may be minimized.¶
Note that BGP does not permit careful sequencing of NLRI distribution within the protocol. Routes advertised "last" are only done so between a pair of BGP speakers on a session. Implementations might otherwise re-order advertised NLRI while propagating BGP routes according to their own desires.¶
A huge list to come. In particular, incorrect or incomplete installation of SAV in a network while having attracted traffic to that network by normal BGP means is harmful to the Internet.¶
SAV enforcement of SAV rules in many ways resembles an access control list (ACL), which are often implemented via firewalls. BGP Flowspec [RFC8955] is capable of distributing IP source address filtering to be instantiated in firewalls. However, Flowspec's original design for mitigating distributed denial of service (DDoS) attacks generally has meant that rules distributed via Flowspec are intended to be applied to the interfaces of all Flowspec routers in a network.¶
The [I-D.ietf-idr-flowspec-interfaceset] feature provides scoped application of Flowspec filters. This feature inspires some of the applicability of the SAV-D Device-Specific Group Member Extended Community.¶
Given the overlapping nature of SAV enforcement behavior, and firewalls that may be programmed via Flowspec, should SAV enforcement be encoded there?¶
It is a valid observation that the Group Member Extended Communities defined for SAV-D may have overlapping usefulness for general-purpose BGP Flowspec applications. Future versions of this document may repurpose the Extended Communities for such general use.¶
Discussions with Nan Geng and Susan Hares at IETF-119 were helpful in formulating the requirements for this draft.¶
TBD.¶