Internet DRAFT - draft-song-savnet-intra-domain-igp-poi

draft-song-savnet-intra-domain-igp-poi







SAVNET Group                                                     X. Song
Internet-Draft                                                    Z. Kou
Intended status: Standards Track                         ZTE Corporation
Expires: 27 July 2024                                              Y. Fu
                                                            China Unicom
                                                                  C. Lin
                                                    New H3C Technologies
                                                         24 January 2024


                      IGP POI for Intra-domain SAV
               draft-song-savnet-intra-domain-igp-poi-01

Abstract

   This document describes an IGP Prefix Originated Indicator (POI)
   method for Source Address Validation (SAV) on routers to mitigate
   source address spoofing attack and improve the accuracy of source
   address validation in intra-domain networks.

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 27 July 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.










Song, et al.              Expires 27 July 2024                  [Page 1]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  IGP POI for Intra-domain SAV  . . . . . . . . . . . . . . . .   3
     3.1.  IGP POI Method  . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  SAV Function  . . . . . . . . . . . . . . . . . . . . . .   5
   4.  IGP Extension with POI  . . . . . . . . . . . . . . . . . . .   7
     4.1.  OSPFv2 Extended Prefix POI sub-TLV  . . . . . . . . . . .   7
     4.2.  OSPFv3 Extended Prefix POI sub-TLV  . . . . . . . . . . .   7
     4.3.  ISIS Extended Prefix POI sub-TLV  . . . . . . . . . . . .   7
   5.  Scalability . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Source Address Validation (SAV) is one important way to mitigate
   source address spoofing attacks in the data plane.  There are some
   existing mechanisms like URPF-related technologies can be used to
   deploy SAV in intra-domain and inter-domain networks.  However, these
   technologies may improperly permit spoofed traffic or block
   legitimate traffic with some limitations.

   As analyzed at [I-D.ietf-savnet-intra-domain-problem-statement],
   strict uRPF (see [RFC3704]) technology is simple to implement and
   provides a very reasonable way to single-homing scenarios for ingress
   filtering.  An ingress packet at a border router is accepted only if
   the Forwarding Information Base (FIB) contains a prefix that
   encompasses the source address and forwarding information for that
   prefix points back to the interface over which the packet was
   received.  But when networks are multi-homed or un-symmetric, routes



Song, et al.              Expires 27 July 2024                  [Page 2]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


   are not symmetrically announced to all transit providers, if the
   incoming interface of received packets is different with the export
   interface for routing of the source address it may bring wrong block
   for logic source address prefixes.

   Loose URPF (see [RFC3704]) takes a looser validation mechanism than
   strict URPF to avoid improper block but may permit improperly spoofed
   source address.  The FP-uRPF (see [RFC3704]) attempts to strike the
   balance of the strict and loose uRPF but still has some shortcoming.
   The EFP-uRPF (see [RFC8704]) provides a more feasible way in
   overcoming the improper block of strict uRPF in asymetric routing
   scenario, but EFP-uRPF has not been implemented in practical networks
   yet.

   This document describes an IGP Prefix Originated Indicator (POI)
   method for Source Address Validation on routers to mitigate source
   address spoofing attack and improve the accuracy of source address
   validation in intra-domain networks.

2.  Conventions

2.1.  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.2.  Terminology

   Refer to [I-D.li-savnet-intra-domain-architecture] for the key terms
   used in this document.

   Prefix Originated Indicator (POI):A tag for IGP/BGP source Prefix
   Origin Identification.

3.  IGP POI for Intra-domain SAV

3.1.  IGP POI Method

   The document provides an IGP Prefix origin Indicator (POI) method for
   identifying the origin of source prefixes to avoid attacks caused by
   source address spoofing.  The POI characteristic for source address
   prefix is propagated by IGP route.  Its corresponding IGP extension
   for source address prefix validation refers to section 4.





Song, et al.              Expires 27 July 2024                  [Page 3]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


   The IGP POI method can help overcome the improper filtering problem
   with strict URPF in asymmetrical or multi-homing scenarios.  The
   method is based on the principal that if IGP route flooding for
   multiple prefixes with the same prefix origin, the data packets
   received over different incoming interfaces of edge routers should
   also be transmitted legitimately regarding when the Routing
   Information Base (RIB) contains the prefix that encompasses the
   source address the packet was received.

   It's noted that the complete path validation against IGP path
   attribute of a route is out of the scope of the document.  The
   validation for route prefix origin is authorized by the fact prefix
   holder is also out of the scope of the document.

   The document proposes a means by which IGP can make use of the POI
   assignment to each IGP route prefix extracted from the received
   packets in the incoming interfaces of edge routers to achieve proper
   source address validation.  The document only provides considerations
   on Source Address Validation in intra-domain networks in data plane.

   The following figure 1 shows an example for IGP POI method used in
   multi-homing scenario for SAV intra-domain network.



                             +------------+
                          ---|   Transit  |---
                         /   |   Network  |   \
      DestP| NH         /    +------------+    \       DestP | NH
      -----|----   Int3/                        \Int4  ------|----
        P2 |Int3 +-----+                        +-------+ P1 |Int4
        P1 |Int1 | ER1 |                        |  ER2  | P2 |Int2
                 +-----+                        +-------+
                   Int1\                         /Int2
              (P1, POI1)\    +------------+     /
                         \   |   Access   |    /(P2, POI1)
                          \  |  Network   |   /
                           --|  (POI:1)   |---
                             +------------+
                                (P1, P2)



             Figure 1: IGP POI Method for multi-homing Scenario

   The figure 1 shows an example of asymmetrical routes in multi-homing
   scenarios, and here the multi-homing is dual-homing.  The Access
   Network (tagged with POI 1 for indication of the source prefix



Song, et al.              Expires 27 July 2024                  [Page 4]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


   originated location or directionality), announces IGP routes for both
   prefixes (P1, P2) to the edge routers (ER1, ER2).  To achieve traffic
   load-balance the P1 route maybe advertised to ER1 and P2 route
   advertised to ER2.  The FIB table is generated as showed in the
   figure1.  It's obvious that strict uRPF method for source address
   validation does not work well in the asymmetrical route scenario.
   The traffic of prefix P2 incoming from the interface Int1 of ER1 will
   be blocked falsely.  The feasible URPF can work but still have some
   limitations when the propagation of prefixes is not followed.

   The IGP POI method this document proposes can work well for source
   address validation on incoming interface of edge or boundary routers
   in this scenario.  In the example showed in figure 1, the routers in
   Access Network can be considered as SAV Source Entity and identified
   POI 1, while the edge routers ER1 and ER2 be considered as SAV
   Validation Entity.  The incoming packets of multiple prefixes with
   the same POI tag are considered from the same source originated
   location or directionality and be filtered equivalently.

   The IGP POI method is applied as follows:

   1.  Enable the incoming interface of ER1 and ER2 with POI policy
       function for filtering or validating the source prefix from the
       right prefix originated network.
   2.  Enable the IGP neighbor routers with POI functionality for the
       identification of the source prefix originated location or
       directionality.  The POI information of source address prefix can
       be learned by the edge routers via route propagation.
   3.  The edge routers (ER1, ER2) gets the source prefix POI
       information and gets the prefix (P1, P2) from the same prefix
       originated network, generates the full source prefix table (P1,
       P2).

3.2.  SAV Function

   Only the IGP POI method is not enough for source address validation.
   The SAV validation rules SHOULD also be combined to apply to the
   incoming interface of the edge router.  That is, based on the mapping
   policy between the source address prefix and incoming interface
   received data packet, to achieve accurate validation of source data
   packets.  The SAV rule/function involves 2 characters: source address
   prefix and incoming interface.

   The objectives of SAV function include (1) set prefix-to-interface
   mapping of IGP route prefix from IGP neighbor with the incoming
   interface as route policy deployed at the edge routers, (2) match the
   validation mapping policy and (3) decide the validation state for the
   source address.  When the traffic of one specific address prefix



Song, et al.              Expires 27 July 2024                  [Page 5]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


   received at one interface of the edge routers, the validation policy
   should be deployed and filtered the source address.  And based-on the
   validation state the source address should be validated correctly.

   The validation state is considered to include:

   *  Valid: The address prefix of received traffic matches the incoming
      interface.
   *  Invalid: The address prefix of received traffic does not match the
      incoming interface.
   *  NotFound: The address prefix of received traffic is not found.

   When the source address received of traffic which prefix derived from
   the IGP route is not matched with the incoming interface, i.e., the
   POI information of source address prefix is not matched with the POI
   policy applied to the incoming interface, the SAV validation state is
   considered as "Invalid".  Only the prefix matched with the incoming
   interface the validation state is set as "valid".  Similarly, if no
   valid route be found its corresponding address packets should be
   discarded and its validation state should be set as "NotFound".

   In the above example showed in section 3.1, the SAV rules applied to
   the incoming interface of ER1 are showed as the following table 1.

           +=======================+=====+====================+
           | Source Address Prefix | POI | Incoming Interface |
           +=======================+=====+====================+
           | P1                    | 1   | Int1, Int3         |
           +-----------------------+-----+--------------------+
           | P2                    | 1   | Int1, Int3         |
           +-----------------------+-----+--------------------+

            Table 1: Prefix-to-Interface Mapping Table at ER1

   The SAV rules applied to the incoming interface of ER2 are showed as
   the following table 2.

           +=======================+=====+====================+
           | Source Address Prefix | POI | Incoming Interface |
           +=======================+=====+====================+
           | P1                    | 1   | Int2, Int4         |
           +-----------------------+-----+--------------------+
           | P2                    | 1   | Int2, Int4         |
           +-----------------------+-----+--------------------+

            Table 2: Prefix-to-Interface Mapping Table at ER2





Song, et al.              Expires 27 July 2024                  [Page 6]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


   The SAV rules are applied to the incoming interfaces of edge routers
   over which the data packets of Source Address Prefix with the same
   POI in this example are received.  The ingress packets at edge
   routers are validated by SAV ruleds and be accepted and transmitted
   legitimately when the POI information of the source address prefix
   matched with the POI policy of the incoming interface.  With the POI
   method and SAV rules constructed at the edge routers, the limitation
   of strict URPF is overcome and the IGP SAV method works.

4.  IGP Extension with POI

4.1.  OSPFv2 Extended Prefix POI sub-TLV

   The OSPFv2 POI TLV is a new optional sub-TLV of OSPFv2 (see
   [RFC7684]) Extended Prefix TLV which is used to advertise prefix
   information.  The POI sub-TLV is carried to identify the prefix
   originated source information.

   The format for the OSPFv2 POI sub-TLV is shown as below:



        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               |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            POI ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



          Figure 2: OSPFv2 Extended Prefix POI sub-TLV Format

4.2.  OSPFv3 Extended Prefix POI sub-TLV

   The OSPFv3 POI TLV is a sub-TLV of OSPFv3 (see [RFC8362]) Intra-Area-
   Prefix TLV, Inter-Area-Prefix TLV or External-Prefix TLV which are
   used for advertising OSPFv3 prefix information.  The OSPFv3 POI sub-
   TLV is carried to identify the prefix originated source information.

   The format for the OSPFv3 Extended Prefix POI sub-TLV is the same as
   OSPFv2.

4.3.  ISIS Extended Prefix POI sub-TLV

   The ISIS POI TLV is a sub-TLV of the following ISIS TLVs:




Song, et al.              Expires 27 July 2024                  [Page 7]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


   TLV-135 (Extended IPv4 reachability) (see [RFC5305]).

   TLV-235 (Multi-topology IPv4 Reachability) (see [RFC5120]).

   TLV-236 (IPv6 IP Reachability) (see [RFC5308]).

   TLV-237 (Multi-topology IPv6 IP Reachability) (see [RFC5120]).

   The TLVs are used for advertising ISIS prefix information.  The ISIS
   POI sub-TLV is carried to identify the prefix originated source
   information.

   The format for the ISIS POI sub-TLV is shown as below:



        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      |     Length    |            Reserved           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            POI ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



           Figure 3: ISIS Extended Prefix POI sub-TLV Format

5.  Scalability

   The instantiation of SAV POI requires POI-related configurations of
   the SAV validation entities.  The management and optimization of SAV
   POIs requires monitoring of the status of SAV validation in the
   underlying intra-domain networks and reporting relevant information
   to the upper-layer network controller for processing.

   SAV POI needs to be advertised and processed by the SAV Validation
   entity, which means that some fields in the data packet should be
   used to identify POI indicating the directionality or location of the
   source prefix originated.  In order to satisfy scalability
   requirements of source address validation, POI can be deployed at
   different granularity, such as Area Prefix Originated Indicator (Area
   POI), Router level Prefix Originated Indicator (Router POI), and
   Prefix POI, etc.







Song, et al.              Expires 27 July 2024                  [Page 8]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


   The Area POI is an optimal approach provided in this document, which
   introduces an optional sub-TLV of OSPF Extended Prefix TLV and sub-
   TLV of ISIS Extended Prefix TLV, its extension format refers to
   section 4.  The POI information is carried and advertised to indicate
   the source prefix originated OSPF or ISIS area.

   The Router POI is one practical way to reuse some of the existing
   fields to indicate the directionality or location of the source
   packets belong to.  It's suggested to use router-id as POI to
   identify source router, the prefix source OSPF router-id is carried
   at prefix source OSPF router-id Sub-TLV and advertised by the
   originating node, its format follows [RFC9084].  Similarly, the
   router-id of ISIS instance is carried at IPV4/IPV6 Source Router ID
   sub-TLV and advertised by the originated source router, see
   [RFC7794].

   The Prefix POI is the most granular source address validation policy.
   Based on different deployment considerations Service Operators can
   select different granularity of source address validation.

6.  Security Considerations

   Security considerations for IGP SAV are covered in the SAVNET Intra-
   domain Architecture (see [I-D.li-savnet-intra-domain-architecture]).
   The OSPFv2 security considerations are covered in [RFC7684].  The
   OSPFv3 security considerations are covered in [RFC8362].  The ISIS
   security considerations are covered in [RFC5305], [RFC5120],
   [RFC5308].  These security considerations also apply to this
   document.

7.  IANA Considerations

   This document creates 3 new registries:

   1.  OSPFv2 Extended Prefix POI Sub-TLVs.
   2.  OSPFv3 Extended Prefix POI Sub-TLVs.
   3.  ISIS Extended Prefix POI Sub-TLVs.

   The detailed registry information is TBD.

8.  Acknowledgements

   The authors would like to acknowledge Aijun Wang for his valuable
   comments on this document.

9.  References

9.1.  Normative References



Song, et al.              Expires 27 July 2024                  [Page 9]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


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

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
              DOI 10.17487/RFC5308, October 2008,
              <https://www.rfc-editor.org/info/rfc5308>.

   [RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
              2015, <https://www.rfc-editor.org/info/rfc7684>.

   [RFC7794]  Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
              U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
              and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
              March 2016, <https://www.rfc-editor.org/info/rfc7794>.

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

   [RFC8362]  Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
              F. Baker, "OSPFv3 Link State Advertisement (LSA)
              Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
              2018, <https://www.rfc-editor.org/info/rfc8362>.

   [RFC9084]  Wang, A., Lindem, A., Dong, J., Psenak, P., and K.
              Talaulikar, Ed., "OSPF Prefix Originator Extensions",
              RFC 9084, DOI 10.17487/RFC9084, August 2021,
              <https://www.rfc-editor.org/info/rfc9084>.

9.2.  Informative References

   [I-D.ietf-savnet-intra-domain-problem-statement]
              Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source
              Address Validation in Intra-domain Networks Gap Analysis,



Song, et al.              Expires 27 July 2024                 [Page 10]

Internet-Draft        IGP POI for Intra-domain SAV          January 2024


              Problem Statement, and Requirements", Work in Progress,
              Internet-Draft, draft-ietf-savnet-intra-domain-problem-
              statement-02, 17 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              intra-domain-problem-statement-02>.

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

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

   [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

   Xueyan Song
   ZTE Corporation
   China
   Email: song.xueyan2@zte.com.cn


   Zenggui Kou
   ZTE Corporation
   China
   Email: kou.zenggui@zte.com.cn


   Yu Fu
   China Unicom
   China
   Email: fuy186@chinaunicom.cn


   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com




Song, et al.              Expires 27 July 2024                 [Page 11]