Internet DRAFT - draft-li-sava-intra-domain-use-cases

draft-li-sava-intra-domain-use-cases







Network Working Group                                              D. Li
Internet-Draft                                                     J. Wu
Intended status: Informational                                  Tsinghua
Expires: January 13, 2021                                          Y. Gu
                                                                  Huawei
                                                                  L. Qin
                                                                Tsinghua
                                                                  T. Lin
                                                                     H3C
                                                           July 12, 2020


  Soure Address Validation Architecture (SAVA): Intra-domain Use Cases
                draft-li-sava-intra-domain-use-cases-00

Abstract

   This document identifies scenarios where existing approaches for
   detection and mitigation of source address spoofing don't perform
   perfectly.  Either Ingress ACL filtering [RFC3704], unicast Reverse
   Path Forwarding (uRPF) [RFC3704], feasible path uRPF [RFC 3704], or
   Enhanced Feasible-Path uRPF [RFC8704] has limitations regarding
   eihter automated implemetation objective or detection accuracy
   objective (0% false positive and 0% false negative).  This document
   identifies two such scenarios and provides solution discussions.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 January 13, 2021.



Li, et al.              Expires January 13, 2021                [Page 1]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


Copyright Notice

   Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Source Address Validation . . . . . . . . . . . . . . . .   2
     1.2.  Existing SAV Techniques Overview  . . . . . . . . . . . .   3
     1.3.  SAV Requirements and Challenges . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  SAVA Intra-domain Use Case 1: Intra-AS Multi-homing . . .   7
     3.2.  SAVA Intra-domain Use Case 2: Inter-AS Multihoming  . . .   8
   4.  Solution Consideration  . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

1.1.  Source Address Validation

   The Internet is open to traffic, which means that a sender can
   generate traffic and send to any receiver in the Internet without
   permission of the receiver.  Although this openness design improves
   the scalability of the Internet, it also leaves security risks,
   namely, a sender can forge his/her source address when sending the
   packets, which is also well known as source address spoofing.

   Due to the lack of source address spoofing detection mechanism,
   Denial of Service (DoS) attacks seriously compromise network
   security.  By employing source address spoofing, attackers can well
   hide themselves and pin the blame on the destination networks.
   Administrators often spend a lot of effort identifying attack packets



Li, et al.              Expires January 13, 2021                [Page 2]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   without being able to locate the attacker's true source address.  In
   addition to DOS attacks, source address spoofing is also used in a
   multitude of ways.  The threats of source address spoofing have been
   well documented in [RFC6959].  To briefly summarize, the possible
   attacks by source address spoofing includes single-packet attack,
   flood-based DoS, poisoning attack, spoof-based worm/malware
   propagation, reflective attack, accounting subversion, man-in-the-
   middle attack, third-party recon, etc.

1.2.  Existing SAV Techniques Overview

   Source address validation (SAV) verifies the authenticity of the
   packet's source address to detect and mitigate source address
   spoofing [RFC2827].  Source Address Validation Improvement (SAVI)
   method [RFC7039] implements SAV at a fine granularity of host-level
   IP address validataion.  The unicast Reverse Path Forwarding (uRPF)
   techniques (such as Strict uRPF, Feasible uRPF and Loose uRPF)
   [RFC3704] are particularly designed to perform SAV in the granularity
   of IP network.  The Enhanced Feasible-Path Unicast Reverse Path
   Forwarding (EFP-uRPF) methods [RFC8704] further improve Feasible uRPF
   to reduce false positives in the case of inter-AS routing asymmetry
   and multihoming.

   SAVI, typically performed at the access network, is enforced in
   switches, where the mapping relationship between an IP address and
   other "trust anchor" is maintained.  A "trust anchor" can be link-
   layer information (such as MAC address), physical port of a switch to
   connect a host, etc.  It enforces hosts to use legitimate IP source
   addresses.  However, given numerous access networks managed by
   different operators, it is far away from practice for all the access
   networks to simultaneously deploy SAVI.  Therefore, in order to
   mitigate the security risks raised by source address spoofing, SAV
   performed in network border routers is also necessary.  Although it
   does not provide the same filtering granualarity as SAVI does, it
   still helps the tracing of spoofing to a minimized network range.

   Ingress ACLs [RFC2827], typically performed at the network border
   routers, is performed by manually maintaining a traffic filtering
   access list which contains acceptable source address for each
   interface.  Only packets with a source address encompassed in the
   access list can be accepted.  It strictly specifies the source
   address space of incoming packets.  However, manual configuration
   brings scalability and reliability issues.

   Strict uRPF, typically performed at the network (IGP areas or ASes)
   boarder routers, requires that a data packet can be only accepted
   when the FIB contains a prefix that encompasses the source address
   and the corresponding out-interface matches the data incoming



Li, et al.              Expires January 13, 2021                [Page 3]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   interface.  It has the advantages of simple operation, easy
   deployment, and automatic update.  However, in the case of
   multihoming, when the data imcoming interface is different from the
   out-interface of the packet source IP address, using the longest
   prefix match , also refered to as asymmetric routing of data packets,
   Strict uRPF exibits false positive.

   Loose uRPF, sacrificing the directionality of Strict uRPF, only
   requires that the packet's source IP exists as a FIB entry.
   Intuitively, Loose uRPF cannot prevent the attacker from forging a
   source address that already exists in the FIB.

   Feasible uRPF, typically performed at the network border routers,
   helps mitigate false positive of Strict uRPF in the multihoming
   scenarios.  Instead of installing only the best route into FIB as
   Strict uRPF does, Feasible uRPF installs all alternative paths into
   the FIB.  It helps reduce false positive filtering compared with the
   Strict uRPF, in the case when multiple paths are learnt from
   different interfaces.  However, it should be noted that Feasible uRPF
   only works when multiple paths is learnt.  There are cases when a
   device only learns one path but still has packets coming from other
   valid interfaces.

   EFP-uRPF, specifically performed at the AS border routers, further
   improves Feasible uRPF in the inter-AS scenario.  An AS performing
   EFP-uRPF maintains an individual RPF list on every customer/peer
   interface.  It introduces two algorihtms (i.e., Algorithm A and
   Algorithm B) regarding different application scenarios.  In the case
   that a customer interface fails to learn any route from the directly
   connected customer AS, enabling Algorithm A at this customer
   interface may exibit false postive filtering.  In this case, enabling
   Algorithm B may mitigate the false positive.  However, in case of
   directly connected customer ASes spoofing each other, Algorithm B
   exibits false negative.

1.3.  SAV Requirements and Challenges

   As the above overview indicates, to evaluate the quality of a
   specific SAV technique, one should balance between two general
   requirements: precise filtering and automatic implementation.

   o  Precise filtering: Two important indicators for precise filtering.
      1) 0% false positive.  If legitimate packets may be dropped, it
      can seriously affect the user's internet experience.  2) 0% false
      negative.  If some packets with a forged source address may pass
      through the SAV smoothly, it will pose potential security risks.





Li, et al.              Expires January 13, 2021                [Page 4]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   o  Automatic implementation: In reality, the address space of an
      administrative domain (AD) may grow or update, and the routing
      policy within the address domain may be dynamically adjusted.  One
      solution that relies entirely on manual configuration is neither
      scalable nor easy to deploy.

   Then to consider the whole network SAV soltuion, one should never
   rely on a single point but a systematic SAV technique combination
   depoyled at different network levels.  As shown in Figure 1, packet
   filtering at different levels from the access network to the AS
   boarder are all needed.  In Figure 1, the administrive domain (AD)
   concept is used, which refers to a network domain managed by the same
   operator (OTT, ISP and so on).  One AD is allowed to be divided into
   several sub-ADs and managed by different inner groups.  There may
   exist different levels for sub-ADs.  For example, sub-AD1 is the
   upper level compared to sub-AD2, meaning that sub-AD2 needs to
   connect through sub-AD1 for external reachability (i.e., networks
   outside AD1).  So filtering at sub-AD boarders (between different
   levels and within the same level) is also necessary.  Further,
   different sub-ADs can belong to one single AS or multiple ASes, which
   makes the filtering at the sub-AD boarders either intra-AS filtering
   or inter-AS filetering.  In the rest of this document, we use the
   term SAVA (SAV architecture) to refer to the discussion of the
   systematic SAV solution.



























Li, et al.              Expires January 13, 2021                [Page 5]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   +-------------------------------------+
   |  AD1                                |
   |                                     |
   | +---------------------------------+ |
   | | Sub-AD1   +--------+            | |
   | |           |Router 4|            | |           +-------------+
   | |           +--X---X-+            | |           | AD2         |
   | |            X       X            | |           | +--------+  |
   | |           X          X          | | +-----------+Router 6|  |
   | |         X              X        | | +         | +--------+  |
   | |   +---X----+        +---X+--------+ SAVA-Inter|             |
   | |   |Router 2|        |Router 3|  | | Domain    |             |
   | |   +--- X---+        +--X+-----------+         | +--------+  |
   | +-------- X ---------- X ---------+ | +-----------+Router 5|  |
   |             X         X  SAVA-Intra |           | +--------+  |
   | +-----------+X------ X+--Domain---+ |           +-------------+
   | | sub-AD2    +X-----X-+           | |
   | |            |Router 1|           | |
   | |            ++-----+-+           | |
   | |             |     |             | |
   | |             |     |             | |
   | |             |     |             | |
   | |     +-------++   ++-------+     | |
   | |     |Switch 1|   |Switch 2|     | |
   | |     ++------++   ++-------+     | |
   | |      |      |     |  SAVA-Access| |
   | |      |      |     |  (SAVI)     | |
   | |      |      |     |      |      | |
   | |   +--+-+ +--+-+  ++---+ ++---+  | |
   | |   |Host| |Host|  |Host| |Host|  | |
   | |   +----+ +----+  +----+ +----+  | |
   | +---------------------------------+ |
   |                                     |
   +-------------------------------------+

               Figure 1: SAVA

   Looking back at specific SAV approaches, most limitations are caused
   by multihoming.  Further, it is due to the routing information
   asymmetry at the mutil-homed devices.  This document identifies two
   specific scenarios where existing SAV techniques fail to meet the
   above mentioned requirements.

2.  Terminology

   IGP: Interior Gateway Protocol

   IS-IS: Intermediate System to Intermediate System



Li, et al.              Expires January 13, 2021                [Page 6]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   BGP: Boarder Gateway Protocol

   FIB: Forwarding Information Base

   SAV: Source Address Validation

   SAVA: Source Address Validation Architecture

   AD: Administrative Domain

3.  Problem Statement

   As stated in Section 1.3, existing methods, e.g., Loose/Strict mode
   uRPF, FP-uRPF, EFP-uRPF are not able to achieve 100% accurate
   filtering (i.e., 0% FN and 0% FP) in certain scenarios.  This
   document specifically indicate two typical intra-domain cases that
   conventional approaches fail to cover: 1) all sub-ADs are under the
   same AS; 2) sub-ADs are under different ASes.

3.1.  SAVA Intra-domain Use Case 1: Intra-AS Multi-homing

   Figure 2 illustrates an intra-AS multihoming case, where sub-AD1,
   sub-AD2 and sub-AD3 are under the same AS.

   Router 1 is multi-homed to Router 2 and Router 3.  Router 1 doesn't
   announce any of its routes to Router 2 nor Router 3.  Static routes
   are configured on Router 1, Router 2 and Router 3.  Supposely, both
   Router 2 and Router 3 should have static routes P1/P2 with Router 1
   as next hop configured.  However, due to configuration error, or
   traffic control purpose, on Router 3, no P1/P2 static routes are
   configured.  Router 2 and Router 3 are connected with ISIS or OSPF.
   P1/P2 are flooded from Router 2 to Router 3.

   Router 5 is single-homed to Router 3.  Router 5 announces P3 to
   Router 3 using ISIS or OSPF.  Router 3 floods P3 to Router 2 .

   Now suppose two data flow coming from Router 1 to Router 3: Flow 1
   with source IP as P1, and Flow 2 with source IP as P3 (IP spoofing).
   Using existing SAV methods at Router 3, Flow 1 is supposed to be
   passed, while Flow 2 is supposed to be dropped.

   o  Loose uRPF: works for Flow 1, but fails for Flow 2.

   o  Strict uRPF: works for Flow 2, but fails for Flow 1 (the incoming
      interface does not match P1/P2's out-interface).

   o  FP-uRFP: works for Flow 2, but fails for Flow 1 (no feasible path
      for P1/P2 other than the best route exists).



Li, et al.              Expires January 13, 2021                [Page 7]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   o  EFP-uRPF: does not apply at the intra-AS case.

    +----------------------------------------------------------------+
    | AS          +--------------------------------+                 |
    |             |sub-AD1   +--------+            |                 |
    |Static:      |          |Router 4|            | Static: NA      |
    |Prefix: P1   |          +--X---X-+            |                 |
    |NH: Router 1 |           X       X            | IGP:            |
    |Prefix: P2   |          X          X          | Prefix: P1      |
    |NH: Router 1 | +--------+ [P1,P2]  +--------+ | NH: Router 2    |
    |             | |        +---------->        | | Prefix: P2      |
    |IGP:         | |Router 2|          |Router 3| | NH: Router 2    |
    |Prefix: P3   | |        +<---------+        | | Prefix: P3      |
    |NH: Router 3 | +--------+   [P3]   +--------+ | NH: Router 5    |
    |             +-------X---------------X------X-+                 |
    |                      X             X         X                 |
    |            [no prefix adv]  [no prefix adv]    X [P3]          |
    |                        X         X               X             |
    |             +----------+X------ X+----------+  +--X+---------+ |
    |             |sub-AD2    +X-----X-+          |  |sub-AD3      | |
    |             |           |Router 1|          |  |  +---X----- | |
    |             |           ++-----+-+          |  |  |Router 5| | |
    |             |         P1 |     | P2         |  |  +--------- | |
    |             |            |     |            |  |      P3     | |
    |             |    +-------++   ++-------+    |  +-------------+ |
    |             |    |Switch 1|   |Switch 2|    |                  |
    |             |    ++------++   ++------++    |                  |
    |             |     |      |     |      |     |                  |
    |             |  +--+-+ +--+-+  ++---+ ++---+ |                  |
    |             |  |Host| |Host|  |Host| |Host| |                  |
    |             |  +----+ +----+  +----+ +----+ |                  |
    |             +-------------------------------+                  |
    +----------------------------------------------------------------+

         Figure 2: Asymmetric data flow in the Intra-AS scenario

3.2.  SAVA Intra-domain Use Case 2: Inter-AS Multihoming

   Figure 3 illustrates an inter-AS multihoming case, where sub-AD1,
   sub-AD2 and sub-AD3 are under three different ASes.

   Router 1 (AS2) is multi-homed to Router 2 (AS1) and Router 3 (AS1).
   Router 1 announces P1/P2 to Router 2 through BGP.  Router 1 doesn't
   announce any of its routes to Router 3 due to policy control.  P1/P2
   are propagated from Router 2 to Router 3 through BGP.






Li, et al.              Expires January 13, 2021                [Page 8]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   Router 5 (AS3) is single-homed to Router 3 (AS1).  Router 5 announces
   P3 to Router 3 through BGP.  Router 3 propagates P3 to Router 2
   through BGP.

   Now suppose two data flow coming from Router 1 to Router 3: Flow 1
   with source IP as P1, and Flow 2 with source IP as P3 (IP spoofing).
   Using existing SAV methods at Router 3, Flow 1 is supposed to be
   passed, while Flow 2 is supposed to be dropped.

   o  Loose uRPF: works for Flow 1, but fails for Flow 2.

   o  Strict uRPF: works for Flow 2, but fails for Flow 1 (the incoming
      interface does not match P1/P2's out-interface).

   o  FP-uRFP: works for Flow 2, but fails for Flow 1 (no feasible path
      for P1/P2 other than the best route exists).

   o  EFP-uRPF: works for Flow 1, but fails for Flow 2 using Algorithm
      B.  Works for Flow 2, but fails for Flow 1 when using Algorithm A.
































Li, et al.              Expires January 13, 2021                [Page 9]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


    +----------------------------------------------------------------+
    |             +--------------------------------+                 |
    |             |sub-AD1   +--------+            |                 |
    |             |AS1       |Router 4|            |                 |
    | BGP:        |          +--X---X-+            | BGP:            |
    | Prefix: P1  |           X       X            | Prefix: P1      |
    | NH: Router 1|          X          X          | NH: Router 2    |
    | Prefix: P2  | +--------+ [P1,P2]  +--------+ | Prefix: P2      |
    | NH: Router 1| |        +---------->        | | NH: Router 2    |
    |             | |Router 2|          |Router 3| |                 |
    | Prefix: P3  | |        +<---------+        | | Prefix: P3      |
    | NH: Router 3| +--------+   [P3]   +--------+ | NH: Router 5    |
    |             +-------X---------------X------X-+                 |
    |                      X             X         X                 |
    |               [P1/P2] X     [no prefix adv]    X [P3]          |
    |                        X         X               X             |
    |             +----------+X------ X+----------+  +--X+---------+ |
    |             |sub-AD2    +X-----X-+          |  |sub-AD3      | |
    |             |AS2        |Router 1|          |  |AS3  X       | |
    |             |           ++-----+-+          |  |  +---X----- | |
    |             |         P1 |     | P2         |  |  |Router 5| | |
    |             |            |     |            |  |  +--------- | |
    |             |    +-------++   ++-------+    |  |      P3     | |
    |             |    |Switch 1|   |Switch 2|    |  +-------------+ |
    |             |    ++------++   ++------++    |                  |
    |             |     |      |     |      |     |                  |
    |             |  +--+-+ +--+-+  ++---+ ++---+ |                  |
    |             |  |Host| |Host|  |Host| |Host| |                  |
    |             |  +----+ +----+  +----+ +----+ |                  |
    |             +-------------------------------+                  |
    +----------------------------------------------------------------+

          Figure 3: Asymmetric data flow in the Inter-AS scenario

4.  Solution Consideration

   Both EFP-uRPF and FP-uRPF try to achieve a balance between
   flexibility (Loose uRPF) and directionality (Strict uRPF).

   In the inter-AS multi-homing scenario, EFP-uRPF further improves FR-
   uRPF's directionality, thanks to the availability of the route origin
   information.  More specifically, the construction of RPF lists using
   EFP-uRPF Algorithm A or B is augmented with data from Route Origin
   Authorization (ROA) [RFC6482], as well as Internet Routing Registry
   (IRR) data, making EFP-uRPF performing better than FR-uRPF regarding
   directionality.  In fact, the global availability of ROA and IRR
   databeses provides a way for the multiple transit providers of the




Li, et al.              Expires January 13, 2021               [Page 10]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   same multihomed network to share such information without extra way
   of data syncronization.

   In addition, although ERP-uRPF is striving for more accurate RPF list
   construction, there's still currenly no way of constructing an 100%-
   accurate RPF list in the case shown in Figure 3.  In order to to
   conquer such problem, it could help if devices in the upper level
   sub-AD(s) (i.e., Router 2 and Router 3) can share more information
   with each other through certain way.

   What's worse, in case of the intra-AS multi-homing, as indicated in
   Figure2, there's no such prefix to sub-AD mapping (e.g., P3
   originates from sub-AD3) database publiclly available as ROA or IRR
   database, or automatically retrievable as RPKI ROA through RTR
   protocol [RFC8210].  Thus, enhancing such information sharing between
   devices of the upper level sub-AD(s) (i.e., Router 2 and Router 3)
   for the same multi-homed network, by extending certain routing
   protocols, could be a possible way.

5.  Security Considerations

   TBD

6.  Contributors

   TBD

7.  Acknowledgments

   TBD

8.  Normative References

   [I-D.brockners-inband-oam-requirements]
              Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
              Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
              T., Lapukhov, P., and r. remy@barefootnetworks.com,
              "Requirements for In-situ OAM", draft-brockners-inband-
              oam-requirements-03 (work in progress), March 2017.

   [I-D.ietf-grow-bmp-adj-rib-out]
              Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S.
              Zhuang, "Support for Adj-RIB-Out in BGP Monitoring
              Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-07 (work
              in progress), August 2019.






Li, et al.              Expires January 13, 2021               [Page 11]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   [I-D.ietf-grow-bmp-local-rib]
              Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente,
              "Support for Local RIB in BGP Monitoring Protocol (BMP)",
              draft-ietf-grow-bmp-local-rib-07 (work in progress), May
              2020.

   [I-D.ietf-netconf-yang-push]
              Clemm, A. and E. Voit, "Subscription to YANG Datastores",
              draft-ietf-netconf-yang-push-25 (work in progress), May
              2019.

   [I-D.openconfig-rtgwg-gnmi-spec]
              Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
              C., and C. Morrow, "gRPC Network Management Interface
              (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in
              progress), March 2018.

   [I-D.song-ntf]
              Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z.,
              Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a
              Network Telemetry Framework", draft-song-ntf-02 (work in
              progress), July 2018.

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
              "Simple Network Management Protocol (SNMP)", RFC 1157,
              DOI 10.17487/RFC1157, May 1990,
              <https://www.rfc-editor.org/info/rfc1157>.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              DOI 10.17487/RFC1191, November 1990,
              <https://www.rfc-editor.org/info/rfc1191>.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <https://www.rfc-editor.org/info/rfc1195>.

   [RFC1213]  McCloghrie, K. and M. Rose, "Management Information Base
              for Network Management of TCP/IP-based internets: MIB-II",
              STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991,
              <https://www.rfc-editor.org/info/rfc1213>.

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






Li, et al.              Expires January 13, 2021               [Page 12]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


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

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

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

   [RFC3719]  Parker, J., Ed., "Recommendations for Interoperable
              Networks using Intermediate System to Intermediate System
              (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004,
              <https://www.rfc-editor.org/info/rfc3719>.

   [RFC3988]  Black, B. and K. Kompella, "Maximum Transmission Unit
              Signalling Extensions for the Label Distribution
              Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005,
              <https://www.rfc-editor.org/info/rfc3988>.

   [RFC6232]  Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
              Originator Identification TLV for IS-IS", RFC 6232,
              DOI 10.17487/RFC6232, May 2011,
              <https://www.rfc-editor.org/info/rfc6232>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6959]  McPherson, D., Baker, F., and J. Halpern, "Source Address
              Validation Improvement (SAVI) Threat Scope", RFC 6959,
              DOI 10.17487/RFC6959, May 2013,
              <https://www.rfc-editor.org/info/rfc6959>.

   [RFC7039]  Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
              "Source Address Validation Improvement (SAVI) Framework",
              RFC 7039, DOI 10.17487/RFC7039, October 2013,
              <https://www.rfc-editor.org/info/rfc7039>.








Li, et al.              Expires January 13, 2021               [Page 13]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              Traffic Engineering (TE) Information Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016,
              <https://www.rfc-editor.org/info/rfc7752>.

   [RFC7854]  Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
              Monitoring Protocol (BMP)", RFC 7854,
              DOI 10.17487/RFC7854, June 2016,
              <https://www.rfc-editor.org/info/rfc7854>.

   [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol, Version 1",
              RFC 8210, DOI 10.17487/RFC8210, September 2017,
              <https://www.rfc-editor.org/info/rfc8210>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

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

Authors' Addresses

   Dan Li
   Tsinghua
   Beijing
   China

   Email: tolidan@tsinghua.edu.cn


   Jianping Wu
   Tsinghua
   Beijing
   China

   Email: jianping@cernet.edu.cn








Li, et al.              Expires January 13, 2021               [Page 14]

Internet-Draft         SAVA Intra-domain Use Cases             July 2020


   Yunan Gu
   Huawei
   Beijing
   China

   Email: guyunan@huawei.com


   Lancheng Qin
   Tsinghua
   Beijing
   China

   Email: qlc19@mails.tsinghua.edu.cn


   Tao Lin
   H3C
   Beijing
   China

   Email: lintao@h3c.com





























Li, et al.              Expires January 13, 2021               [Page 15]