]> NIST

Gaithersburg, MD 20899 United States of America ksriram@nist.gov

Akamai Technologies

Cambridge, MA 02142 United States of America ilubashe@akamai.com

ops SAVNET Internet-Draft This document specifies a solution, named IntraSAV, for intra-domain source address validation (SAV). This solution addresses the problem stated in the ietf-savnet-intra-domain-problem-statement (RFC-to-be) document. This document updates BCP 38 () and BCP 84 (, ) by providing a more comprehensive solution methodology and accommodating prefixes that are not routed but used for sourcing traffic originating from an AS.

Introduction The scope of intra-domain SAV is stated in as follows: "Intra-domain SAV is applied at external interfaces (on routers) facing entities that are not deployed as neighboring ASes and are therefore not covered by inter-domain SAV. For example, an entity can be a single host, a set of hosts, or a customer network with no AS that manages one or more IP prefixes. The entity may source traffic using prefixes assigned by the AS or its own BYOIP prefixes. From the perspective of other ASes, such traffic is originated by the AS." This document specifies a solution, named IntraSAV, for intra-domain source address validation (SAV). This solution addresses the problem stated in the ietf-savnet-intra-domain-problem-statement (RFC-to-be) document.

Terminology The terminology used in this document follows Section 1.1 in .

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 when, and only when, they appear in all capitals, as shown here.

IntraSAV Solution The focus here is on SAV at router interfaces, where traffic sourced from prefixes used (or originated) at the local AS (i.e., the SAV-performing AS) arrives from either (1) directly connected hosts, or (2) customers with non-BGP interfaces . In these scenarios, the AS may support two types of prefixes for route or traffic origination: (1) its own provider-owned prefixes, and (2) Bring Your Own IP (BYOIP) prefixes. The proposed SAV solution requires BYOIP customers to inform the local AS about the specific prefixes they intend to use on their respective interfaces for routing and/or source addressing. This data becomes part of the configuration information at the local AS (as defined in the Terminology section of . The local AS similarly incorporates the routing and source addressing requirements (on a per-interface basis) for its own (provider-owned) prefixes into this configuration. Finally, possibly using a SAV agent, the local AS uses the consolidated configuration information to construct and deploy an intra-domain SAV table (allowlist) for each relevant interface of its Customer Edge (CE) routers. The prefix owners (whether the BYOIP customers or the local AS) should register ROAs for their prefixes, authorizing the local AS as the origin. For prefixes originating at the local AS (for either routing or sourcing), the local configuration information takes precedence over the ROA information for both route origination and SAV. However, the local AS should still check the ROAs against its configuration and alert customers to any inconsistencies. This verification is important because remote ASes (one or more hops away) rely on these ROAs (along with other information) to compute their own inter-domain SAV tables . The IntraSAV solution method is illustrated below in . The figure also illustrates an internal AS topology. IntraSAV is applied at CE routers 1 and 2 on Interfaces 1 and 2 that support Customers 1 and 2, respectively. The Configuration Manager (CM), including a SAV Agent, plays a key role in facilitating IntraSAV. The role of the CM is to authenticate the customers and collect their configuration information for routing and SAV purposes. Customer 1 registers prefixes {p, q} and specifies that both prefixes are routed (i.e., announced). Note that "can be routed (announced)" implies that the prefix can also be used for sourcing traffic. On the other hand, Customer 2 registers prefixes {r, s} and specifies that r is routed while s is not routed but used for sourcing at this AS. The SAV agent in the CM makes use of this configuration information and programs CE router interfaces 1 and 2 with SAV tables (allowlists) {p, q} and {r, s}, respectively. As long as the configuration information available to the local Configuration Manager is complete, IntraSAV guarantees zero improper blocks and zero improper admits.

Illustration of internal AS topology and the IntraSAV solution method.

** To be Discussed (by authors and the WG): The AS operator may choose to apply IntraSAV on Interface 3 at the ASBR in . This type of ingress SAV may be done in addition to or as an alternative to doing IntraSAV at the CE router interfaces described above. The important consideration is that the operator should be certain, based on knowledge of the local topology and information in the CM, that all the traffic the ASBR interface receives is expected to be sourced from known prefixes and originating from the local AS. It is clear in the topology of that the expected set of traffic-sourcing prefixes at Interface 3 is equal to the superset of the sets of prefixes configured for the CE router interfaces (Interfaces 1 and 2). So, the operator can confidently apply the prefix-superset {p, q, r, s} as the SAV table (allowlist) on Interface 3 at the ASBR (see ). It may be noted that this proposal likely goes beyond the scope stated in except when the ASBR interface in consideration is directly serving a set of hosts or a non-AS customer. Generally, the proposal is useful for cases when the AS operator determines that it is much more feasible to upgrade their ASBR rather than the CE routers for SAV.**

Security Considerations Checking configuration information against ROA information helps in affirming accuracy and avoiding improper blocks and improper permits in IntraSAV and at ASes one or more hops away.

IANA Considerations This document does not have IANA considerations.

Acknowledgements The authors wish to thank Paul Vixie, Doug Montgomery, Jeff Haas, ... for suggestions and discussions.

References Normative References This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. Zhongguancun Laboratory Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei Source address validation (SAV) is an important means to mitigate IP source address spoofing [RFC2827]. This document analyzes the gaps in current operational mechanisms for intra-domain SAV. It also identifies the properties that new intra-domain SAV mechanisms are expected to provide. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory Huawei USA National Institute of Standards and Technology This document analyzes the problem space and provides a gap analysis of existing inter-domain source address validation (SAV) mechanisms. Based on these findings, it outlines the technical requirements for future improvements. USA National Institute of Standards and Technology Akamai Technologies USA National Institute of Standards and Technology Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704.