BGP Flow Specification for Source Address Validation
draft-geng-idr-flowspec-sav-03
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Nan Geng , Dan Li | ||
| Last updated | 2024-03-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-geng-idr-flowspec-sav-03
IDR N. Geng
Internet-Draft Huawei
Intended status: Standards Track D. Li
Expires: 5 September 2024 Tsinghua University
4 March 2024
BGP Flow Specification for Source Address Validation
draft-geng-idr-flowspec-sav-03
Abstract
BGP FlowSpec reuses BGP route to distribute infrastructure and
propagates traffic flow information with filtering actions. This
document specifies a new flow specification called Incoming-
Interface-Set. Incoming-Interface-Set can be used together with the
Source Prefix component to disseminate SAV rules.
Status of This Memo
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 5 September 2024.
Copyright Notice
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.
Geng & Li Expires 5 September 2024 [Page 1]
Internet-Draft BGP FlowSpec for SAV March 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. SAV Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BGP FlowSpec for SAV . . . . . . . . . . . . . . . . . . . . 4
3.1. Flow Specification Encoding for SAV . . . . . . . . . . . 5
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Other Usages . . . . . . . . . . . . . . . . . . . . . . 6
4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Source Address Validation (SAV) is an efficient method for preventing
source address spoofing-based attacks. SAV rules indicate the valid/
invalid incoming interfaces of a specific source IP address or source
IP prefix. The rules can be deployed on edge routers, border
routers, or aggregation routers for checking the validity of intra-
domain and inter-domain packets. For invalid packets, filtering
actions can be taken such as block, rate-limit, redirect, and
sampling [I-D.huang-savnet-sav-table].
There are many mechanisms that can distributedly generate SAV rules
on routers ([RFC2827], [RFC3704], [RFC5210], [RFC8704], and
[manrs-antispoofing]). To facilitate flexible SAV management and
improve validation accuracy, centralized SAV rule dissemination is
also needed [I-D.li-savnet-intra-domain-architecture][I-D.wu-savnet-i
nter-domain-architecture], which can be a complementary to existing
distributed SAV mechanisms.
BGP FlowSpec is a convenient and flexible tool for traffic filtering/
controlling ([RFC8955], [RFC8956]). It propagates traffic flow
information for different traffic control purposes through the BGP
protocol extension. Existing BGP FlowSpec has supported source
prefix matching and various traffic filtering actions but does not
support binding valid/invalid incoming interfaces to source prefixes.
With a minor extension, BGP FlowSpec can be used for SAV rule
dissemination.
Geng & Li Expires 5 September 2024 [Page 2]
Internet-Draft BGP FlowSpec for SAV March 2024
This document specifies a new flow specification component named
Incoming-Interface-Set. SAV rules can be disseminated through BGP
FlowSpec by carrying the new flow specification component together
with Source Prefix component. Traffic filtering actions of existing
BGP FlowSpec can also be carried to specify the actions for the
packets failing source address validation.
The new extension can be used to configure SAV rules on remote
routers. It can also act as a supplement of existing SAV mechanisms
and help improve SAV accuracy.
1.1. Terminology
SAV: Source address validation
SAV Rule: The rule that indicates the valid/invalid incoming
interfaces of a specific source IP address or source IP prefix.
Group Identifier: An ID value that identifies a set of interfaces on
the target routers (e.g., all the interfaces connected to customer
ASes).
1.2. Requirements Language
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.
2. SAV Rules
SAV rules can be used for checking the validity of source addresses
of incoming packets. A rule usually has a format of <source prefix,
interface set, validity indicator>. Source prefix is for matching
specific packets. Interface set represents a set of physical
interfaces from which the packets arrive. Validity indicator
indicates whether the packets matching the source prefix and arrival
interface are valid or invalid. So, validity indicator has a value
of either valid or invalid.
For example, the rule <P1, [intf1, intf2], valid> means the source
prefix P1 must arrive the router at interface Intf1 or Intf2,
otherwise, P1 is invalid. For the packets with invalid source
addresses/prefixes, the filtering actions, such as block, rate-limit,
and redirect, can be taken [I-D.huang-savnet-sav-table].
Geng & Li Expires 5 September 2024 [Page 3]
Internet-Draft BGP FlowSpec for SAV March 2024
In real networks, the interface set in SAV rules usually can be
grouped. For example, the interfaces can be grouped as:
* Subnet interface set that contains the interfaces connecting a
target subnet.
* All customer AS interfaces set or the customer AS interfaces set
of a customer AS.
* All lateral peer AS interfaces set or the lateral peer AS
interfaces set of a lateral peer AS.
* All transit provider AS interfaces set or the transit provider AS
interfaces set of a transit provider AS.
These interface set can be identified by a Group Identifier for easy
management. Group Identifier is a local interface property on the
target routers, and the meaning of it depends on the configurations
of network administrator. Any interface may be associated with one
or more Group Identifiers.
3. BGP FlowSpec for SAV
SAV can be disseminated to Edge/Border/Aggregation routers (i.e.,
target routers) through BGP FlowSpec, as shown in the figure below.
The controller is used to set up BGP connection with the routers in a
SAV-deployed AS or domain. Note that, SAV rules disseminated by BGP
FlowSpec can take effect alone or acts as a management tool of other
SAV mechanisms (e.g., [RFC8704]).
+------------+
| Controller |
+------------+
/ | \
/ FS | FS \ FS
/ | \
+-------------+ +--------------+ +---------+
| Provider or | | SAV-deployed | | |
| Customer or |------# AS/Domain #------| Subnets |
| Peer AS | | | | |
+-------------+ +--------------+ +---------+
Existing BGP FlowSpec has supported source prefix matching and
various traffic filtering actions. To disseminate SAV rules (<source
prefix, interface set, validity indicator>), a new flow specification
component is needed to carry the information of interface set and
validity indicator.
Geng & Li Expires 5 September 2024 [Page 4]
Internet-Draft BGP FlowSpec for SAV March 2024
3.1. Flow Specification Encoding for SAV
The new flow specification component is encoded in the BGP Flowspec
NLRI. It SHOULD appear together with Source Prefix component.
The following new component type is defined:
* Type TBD1: Incoming-Interface-Set
* Encoding: <type (1 octet), [numeric_op, value]+>
The new component contains a set of {numeric_op, value} pairs that
are used to match the Incoming-Interface-Set (i.e., the valid or
invalid interfaces of a specific source prefix).
The numeric operator (numeric_op) is encoded as (see RFC8955 sec.
4.2.1.1):
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+
The value field is encoded as:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|R| Group Identifier (variable, 6, 14, 30, or 62 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the value field can be 1, 2, 4, or 8 octets, which
depends on the len in numeric_op. Particularly, the most two
significant bits in the value field are two flags:
* Flag V (1 bit): The most significant bit in the value field. If
set, the identified interface set is valid for the source prefix.
If unset, it means the interface set is invalid for the source
prefix.
* Flag R (1 bit): The second most significant bit in the value
field. This bit is reserved for future use and MUST be set to
zero.
Group Identifier indicates a specific set of interfaces that are
configured by network administrator. Zero Group Identifier (i.e.,
Group Identifier equaling 0) is a reserved value and does not need to
be configured. A NLRI may carry one zero Group Identifier and
Geng & Li Expires 5 September 2024 [Page 5]
Internet-Draft BGP FlowSpec for SAV March 2024
several non-zero Group Identifiers. The zero Group Identifier means
any other interfaces on the target router except the interfaces
indicated by non-zero Group Identifiers in the same NLRI. If a NLRI
only contains a zero Group Identifier and has no non-zero Group
Identifiers, the zero Group Identifier will represent all interfaces
on the target router. A NLRI MUST not contain more than one zero
Group Identifiers, otherwise, the whole NLRI will be ignored.
The bits lt, gt, and eq can be combined to match a specific Group
Identifier or a range of Group Identifiers (e.g., greater than Group
ID1 and less than Group ID2). For a range of Group Identifiers,
their corresponding flags (i.e., V and R) MUST be the same.
Otherwise, the whole NLRI will be ignored.
If a receiving BGP speaker cannot support this new flow specification
component type, it MUST discard the NLRI value field that contains
such unknown components (section 10 of [RFC8955]). A NLRI value
field MUST only contain a Source Prefix component and an Incoming-
Interface-Set component. If the NLRI value does not satisfy this
principle, the receiving BGP speaker SHOULD discard the NLRI value
field (see Section Section 3.3). Since the NLRI field encoding
(Section 4 of [RFC8955]) is defined in the form of a 2-tuple <length,
NLRI value>, message decoding can skip over the unknown NLRI value
and continue with subsequent remaining NLRIs.
3.2. Examples
Example 1: Configure source prefix P1 as valid at AS1's interfaces
(Group Identifier=ID1) connecting a multi-homed subnet.
Encoding description: NLRI carries a P1 in a Source Prefix component
and a Incoming-Interface-set component with (V=1, R=0, Group
Identifier=ID1).
Example 2: Configure source prefix P2 as invalid at AS2's interfaces
(Group Identifier=ID2) connecting to transit providers and as valid
for any other interfaces.
Encoding description: NLRI carries a P2 in a Source Prefix component
and a Incoming-Interface-set component with (V=0, R=0, Group
Identifier=ID2) and (V=1, R=0, Group Identifier=0).
3.3. Other Usages
The Incoming-Interface-Set component can be used as a general flow
specification instead of SAV-specific component. Other components
can be combined with the new component for matching specific traffic.
Geng & Li Expires 5 September 2024 [Page 6]
Internet-Draft BGP FlowSpec for SAV March 2024
4. Error Handling
TBD
5. IANA Considerations
This document requests a new entry in "Flow Spec component types
registry" with the following values:
+=======+========================+===============+
| Type | IPv4/IPv6 Name | Reference |
+=======+========================+===============+
| TBD1 | Incoming-Interface-set | This document |
+-------+------------------------+---------------+
6. Security Considerations
TBD.
7. Acknowledgements
Many thanks to the comments from Shunwan Zhuang, Susan Hares, Jeffrey
Haas, Mingqing Huang, Mingxing Liu etc.
8. References
8.1. Normative References
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
"Dissemination of Flow Specification Rules for IPv6",
RFC 8956, DOI 10.17487/RFC8956, December 2020,
<https://www.rfc-editor.org/info/rfc8956>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
Geng & Li Expires 5 September 2024 [Page 7]
Internet-Draft BGP FlowSpec for SAV March 2024
[I-D.li-savnet-intra-domain-architecture]
Li, D., Wu, J., Qin, L., Geng, N., Chen, L., Huang, M.,
and F. Gao, "Intra-domain Source Address Validation
(SAVNET) Architecture", Work in Progress, Internet-Draft,
draft-li-savnet-intra-domain-architecture-06, 21 January
2024, <https://datatracker.ietf.org/doc/html/draft-li-
savnet-intra-domain-architecture-06>.
[I-D.wu-savnet-inter-domain-architecture]
Wu, J., Li, D., Huang, M., Chen, L., Geng, N., Liu, L.,
and L. Qin, "Inter-domain Source Address Validation
(SAVNET) Architecture", Work in Progress, Internet-Draft,
draft-wu-savnet-inter-domain-architecture-06, 5 February
2024, <https://datatracker.ietf.org/doc/html/draft-wu-
savnet-inter-domain-architecture-06>.
[I-D.huang-savnet-sav-table]
Huang, M., Cheng, W., Li, D., Geng, N., Liu, Chen, L., and
C. Lin, "General Source Address Validation Capabilities",
Work in Progress, Internet-Draft, draft-huang-savnet-sav-
table-04, 21 February 2024,
<https://datatracker.ietf.org/doc/html/draft-huang-savnet-
sav-table-04>.
[manrs-antispoofing]
"MANRS Implementation Guide", January 2023,
<https://www.manrs.org/netops/guide/antispoofing>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
"A Source Address Validation Architecture (SAVA) Testbed
and Deployment Experience", RFC 5210,
DOI 10.17487/RFC5210, June 2008,
<https://www.rfc-editor.org/info/rfc5210>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
Geng & Li Expires 5 September 2024 [Page 8]
Internet-Draft BGP FlowSpec for SAV March 2024
Authors' Addresses
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Geng & Li Expires 5 September 2024 [Page 9]