Internet-Draft BGP FlowSpec for SAV March 2024
Geng & Li Expires 4 September 2024 [Page]
Workgroup:
IDR
Internet-Draft:
draft-geng-idr-flowspec-sav-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
N. Geng
Huawei
D. Li
Tsinghua University

BGP Flow Specification for Source Address Validation

Abstract

BGP FlowSpec reuses BGP route to distribute infrastructure and propogates 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 4 September 2024.

Table of Contents

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 distributely 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-inter-domain-architecture], which can be a complementary to existing distributed SAV mechanisms.

BGP FlowSpec is a convenient and flexible tool for traffic filtering/controling ([RFC8955], [RFC8956]). It propogates 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.

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 indentifies 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].

In real networks, the interface set in SAV rules usually can be grouped. For example, the interfaces can be grouped as:

These interface set can be indentified by a Group Identifier for easy management. Group Identifier is a local interface property on the target routers, and the meaning of it depneds 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/Aggragation 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 dissenimate 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.

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|U|     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. Partiularly, 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 U (1 bit): The second most significant bit in the value field. If set, it is unknown for the source prefix whether the rest of interfaces (not included in the interface set) on the target router are valid or invalid. If unset, it means the rest of interfaces on the target router are invalid (when V is set) or valid (when V is unset) for the source prefix.

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).

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 a 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 soucre 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 componentand a Incoming-Interface-set component with V=1, U=1, Group Identifier=ID1.

Example 2: Configure soucre 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 componentand a Incoming-Interface-set component with V=0, U=0, Group Identifier=ID2.

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 conbined with the new component for matching specific traffic.

4. 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 |
+-------+------------------------+---------------+

5. Security Considerations

TBD.

6. Acknowledgements

Many thanks to the comments from Shunwan Zhuang, Susan Hares, Jeffrey Haas, Mingqing Huang etc.

7. References

7.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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

[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, , <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, , <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, , <https://datatracker.ietf.org/doc/html/draft-huang-savnet-sav-table-04>.
[manrs-antispoofing]
"MANRS Implementation Guide", , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8704>.

Authors' Addresses

Nan Geng
Huawei
Beijing
China
Dan Li
Tsinghua University
Beijing
China