IGP POI for Intra-domain SAV
draft-song-savnet-intra-domain-igp-poi-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Xueyan Song , Zenggui Kou | ||
| Last updated | 2023-10-19 | ||
| RFC stream | (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-00
SAVNET Group X. Song
Internet-Draft Z. Kou
Intended status: Standards Track ZTE Corporation
Expires: 21 April 2024 19 October 2023
IGP POI for Intra-domain SAV
draft-song-savnet-intra-domain-igp-poi-00
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 21 April 2024.
Copyright Notice
Copyright (c) 2023 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 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.
Song & Kou Expires 21 April 2024 [Page 1]
Internet-Draft IGP POI for Intra-domain SAV October 2023
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. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
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
Song & Kou Expires 21 April 2024 [Page 2]
Internet-Draft IGP POI for Intra-domain SAV October 2023
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):The tag for IGP 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.
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.
Song & Kou Expires 21 April 2024 [Page 3]
Internet-Draft IGP POI for Intra-domain SAV October 2023
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
| ER1 | | ER2 |
+-----+ +-------+
Int1\ +------------+ /Int2
(P1, POI1)\ | Access | /(P2, POI1)
\ | Network | /
---| (POI:1) |---
+------------+
Figure 1: IGP POI Method for Multi-homing Scenario
As an example, in the multi-homing scenario, if the access network
tagged with POI 1 for indication of the source prefix originated
location or directionality, announces IGP routes for both prefixes
(P1, P2) to both edge routers (ER1, ER2). In this scenario, the
strict uRPF method does not work well, while the feasible URPF works
with some limitations when the propagation of prefixes is not
followed.
The IGP POI method is applied and works well for source address
validation on incoming interface (facing Prefix Originated Network
directionality) of edge or boundary routers. The Prefix Originated
Indicator (POI) is used for the identification of the source prefix
originated location or directionality.
Song & Kou Expires 21 April 2024 [Page 4]
Internet-Draft IGP POI for Intra-domain SAV October 2023
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
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.
Song & Kou Expires 21 April 2024 [Page 5]
Internet-Draft IGP POI for Intra-domain SAV October 2023
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 rule applied to
the incoming interface of ER1 are showed as the following table 1.
+=======================+=====+====================+
| Source Address Prefix | POI | Incoming Interface |
+=======================+=====+====================+
| P1 | 1 | Int1 |
+-----------------------+-----+--------------------+
| P2 | 1 | Int1 |
+-----------------------+-----+--------------------+
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 |
+-----------------------+-----+--------------------+
| P2 | 1 | Int2 |
+-----------------------+-----+--------------------+
Table 2: Prefix-to-Interface Mapping Table at ER2
The SAV rules are applied to the incoming interfaces (Int1, Int2) of
edge routers (ER1, ER2) over which the data packets of Source Address
Prefix (P1, P2) 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.
Song & Kou Expires 21 April 2024 [Page 6]
Internet-Draft IGP POI for Intra-domain SAV October 2023
4. IGP Extension with POI
4.1. OSPFv2 Extended Prefix POI sub-TLV
The OSPFv2 POI TLV is a sub-TLV of OSPFv2 (see [RFC7684]) Extended
Prefix TLV which is used to advertise prefix information. When the
route type of OSPFv2 Extended Prefix TLV is Intra-Area (1) or Inter-
Area (3) 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 and OSPFv3 Inter-Area 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:
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]).
Song & Kou Expires 21 April 2024 [Page 7]
Internet-Draft IGP POI for Intra-domain SAV October 2023
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POI ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ISIS Extended Prefix POI sub-TLV Format
5. 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.
6. 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.
7. Acknowledgements
TBD.
8. References
8.1. Normative References
Song & Kou Expires 21 April 2024 [Page 8]
Internet-Draft IGP POI for Intra-domain SAV October 2023
[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>.
[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>.
8.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,
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., Huang, M., Chen, L., Geng, N., Qin, L.,
and F. Gao, "Intra-domain Source Address Validation
(SAVNET) Architecture", Work in Progress, Internet-Draft,
Song & Kou Expires 21 April 2024 [Page 9]
Internet-Draft IGP POI for Intra-domain SAV October 2023
draft-li-savnet-intra-domain-architecture-03, 25 July
2023, <https://datatracker.ietf.org/doc/html/draft-li-
savnet-intra-domain-architecture-03>.
[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
Song & Kou Expires 21 April 2024 [Page 10]