IGP POI for Intra-domain SAV
draft-song-savnet-intra-domain-igp-poi-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Xueyan Song , Zenggui Kou , Yu Fu , Changwang Lin | ||
| Last updated | 2024-01-23 | ||
| 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-song-savnet-intra-domain-igp-poi-01
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]