Internet DRAFT - draft-xu-erisav
draft-xu-erisav
Network Working Group K. Xu
Internet-Draft J. Wu
Intended status: Informational X. Wang
Expires: 19 March 2023 Tsinghua University
Y. Guo
Zhongguancun Laboratory
G. Dong
China Telecom
15 September 2022
Enhance with RPKI and IPsec for the Source Address Validation
draft-xu-erisav-00
Abstract
Packet forwarding on Internet typically takes no place with
inspection of the source address. Thus malicious attacks or abnormal
behavior have been launched with the spoofed source addresses. This
document describes an inter-domain source address validation with
RPKI (Resource Public Key Infrastructure) and IPsec (IP Security),
including the motivation, tech framework, main interactive process,
and optional extensions.
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 19 March 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xu, et al. Expires 19 March 2023 [Page 1]
Internet-Draft ERISAV September 2022
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3
3. Desgin Objectives . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Interactive Process . . . . . . . . . . . . . . . . . . . . . 5
6. Related Extensions . . . . . . . . . . . . . . . . . . . . . 6
7. Security Consideration . . . . . . . . . . . . . . . . . . . 6
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
IP spoofing has been a long-recognized threat to Internet security
for decades. Inter-domain source address validation (SAV) has long
served as the primary defense mechanism due to its better cost-
effectiveness. However, over years of effort, inter-domain source
address validation deployment is still not optimistic. An important
reason for this is the difficulty of balancing the clear security
benefits of partial deployments with the scalability of large-scale
deployments. uRPF [RFC5635], for example, is a routing-based scheme
to filter spoofed traffic, which may result in a lack of security
benefits due to the dynamic nature of routing or incomplete
information caused by partial deployments.
RPKI architecture [RFC6480] represents the allocation hierarchy of IP
address space and Autonomous System (AS) numbers. IPsec security
architecture is used to secure the IP packet in host-to-host, host-
to-network, and network-to-network modes. This document defines
using present technologies to reinforce the security of source
address in the inter-domain layer.
This document describes an inter-domain source address validation
with RPKI and IPsec, including the motivation, tech framework, main
interactive process, and extensions.
Xu, et al. Expires 19 March 2023 [Page 2]
Internet-Draft ERISAV September 2022
2. Terms and Definitions
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.
Commonly used terms in this document are described below.
AH: IPsec Authentication Header, which is used to provide
connectionless integrity and data origin authentication for IP
datagrams and to provide protection against replays.
ASBR: AS border router, which is at the boundary of an AS.
CA: Certification authority.
EE: End entity.
IKE: Internet Key Exchange, which is used in IPsec to negotiate IKE
SA and IPsec SA.
NIR: National Internet registry, which is a special case for RIR.
RIR: Regional Internet registry, which is a governing body that is
responsible for the administration of Internet addresses in a
specific geographic region.
RPKI: Resource Public Key Infrastructure, which is a special PKI.
Tag: The authentic identification of the source address of a packet
and placed at the AH's ICV field.
3. Desgin Objectives
Source Address Validation (SAV) aims at preventing the source address
from being spoofed. It should work at the network layer and provide
a veritable IP source address.
When a packet is sent to the network, for saving network bandwidth
and computation resources, the router forwards the packet using the
destination address and without any inspection of the source address.
The packet may come from a forger or impostor of the source address
so that the destination end becomes a latent victim.
The design goals of ERISAV includes follows:
Xu, et al. Expires 19 March 2023 [Page 3]
Internet-Draft ERISAV September 2022
1. Extensible current protocols. With the bindings and extensions
of the current protocols, it would extremely reduce the cost of
updating software, firmware, and hardware. And more importantly,
it would be compatible with the current network. In ERISAV, it
chooses the RPKI, IKE, and IPsec AH.
2. Flatten end-to-end mode. Flatten mode, following the end-to-end
design principle, ensures that the undeployed router has no
perception of this mechanism. And it can be processed and
deployed incrementally.
3. Cryptography-based lightweight labels. A cryptographic packet-
by-packet signature could guarantee that the reverse computation
is infeasible and when it is cracked, the label has been changed
to another. And this packet signature could efficiently be
verified and resist to label-based replay attacks.
4. Inter-domain collaboration trustness. Build an inter-domain
trust alliance and complete source address validation via inter-
domain collaboration.
4. Overview
ERISAV is a cryptography-based end-to-end inter-domain source address
validation method that guarantees security benefits at partial
deployment. ERISAV combines three existing mechanisms. It uses the
RPKI trust chain for the ASN-IP Prefix binding relationship, IKE for
tag/key negotiation and delivery, and IPsec AH for carrying the
identification of the source address in data transmission.
A typical workflow of ERISAV is shown in Figure 1.
Xu, et al. Expires 19 March 2023 [Page 4]
Internet-Draft ERISAV September 2022
+--------------+
| IANA |
+--------------+
|--------------------+
V |
+--------------+ |
| RIR | |
+--------------+ |
/ \-----------+- 1. signed CA
V V | certificate
+--------+ +--------+ |
| LIR1 | | LIR2 |--+
+--------+ +--------+
/ \
V V
+--------------+ +--------------+
| | -------------------- | |
| | 2. IKE negotiation | |
| | and SA delivery | |
| AS X ###### -------------------- ###### AS Y |
| Prefix Px #ASBR# #ASBR# Prefix Py |
| Public Key ###### ++++++++++++++++++++ ###### Public Key |
| | 3. data transmission | |
| | using IPsec AH | |
| | ++++++++++++++++++++ | |
+--------------+ +--------------+
Figure 1: RISAV workflow example.
5. Interactive Process
ERISAV mainly contains 3 steps.
1. IANA issues a Certification Authority (CA) certificate to each
Regional Internet Registry (RIR). RIR uses its root CA to issue
a CA certificate for LIR or NIR which will issue a CA certificate
for one AS. The AS issues a new End Entity (EE) certificate to
enable verification of signatures on RPKI signed objects. This
builds the trust chain using RPKI to guarantee the Internet
number resource including AS number and IP prefix are correctly
announced. Moreover, the public key of AS will be seated at the
CA certificate, which will be used for communication with each
other following.
2. IPsec IKE negotiates the tag tagged in the packet. IKE also
negotiates the authentication algorithm, authentication key, and
others specified by SA. These will be stored in the SAD and SPD
described in [RFC4301]. IPsec AH [RFC4302] is the authentication
Xu, et al. Expires 19 March 2023 [Page 5]
Internet-Draft ERISAV September 2022
header of the IPsec Security Architecture. It authenticates the
whole packet for integrity. However, source address validation
does not require such strong authentication. It just needs to
protect the source address from being spoofed. So it needs a new
authentication process. This new authentication process will
only take a few changeless fields as input. And the original tag
will be seen as the authentication key. The result of this
process will produce a new label called the packet signature that
will be filled in the packet properly. And this label or the SA
MUST send to all the ASBR for communication.
3. Data transmission uses the IPsec AH header extension to the
packet. IPsec AH carries the tag in its field. The tag
represents the authenticity of the source address. When the
source ASBR forwards a packet originating from the ASBR's located
AS, the ASBR will check the destination of the packet. If it is
forwarded to the ERISAV protection area, the ASBR will add the
IPsec AH header extension with the related tag filled. If the
destination ASBR receives a packet coming from the ERISAV
protection area, the ASBR will compare the tag with its local
tag. If they are matched, the source address of this packet will
be seemd as not tampered. Otherwise, the packet will be
discarded because the source address is a spoofing address.
6. Related Extensions
As discussed before, there are almost negligible changes to current
protocols. ERISAV just needs one new IPsec SA for the requirements
of source address validation. It just requires requesting a new
attribute for storing and transporting the tag information. The tag
will be used as the key during the authentication process. The
process of AH also needs some changes. It takes a few unchangeable
fields as input to generate a signature replacing the original tag
for security consideration.
7. Security Consideration
TBD.
8. IANA Consideration
TBD.
9. Normative References
Xu, et al. Expires 19 March 2023 [Page 6]
Internet-Draft ERISAV September 2022
[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>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole
Filtering with Unicast Reverse Path Forwarding (uRPF)",
RFC 5635, DOI 10.17487/RFC5635, August 2009,
<https://www.rfc-editor.org/info/rfc5635>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[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>.
Authors' Addresses
Ke Xu
Tsinghua University
Beijing
China
Email: xuke@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Xiaoliang Wang
Tsinghua University
Beijing
China
Email: wangxiaoliang0623@foxmail.com
Xu, et al. Expires 19 March 2023 [Page 7]
Internet-Draft ERISAV September 2022
Yangfei Guo
Zhongguancun Laboratory
Beijing
China
Email: guoyangfei@zgclab.edu.cn
Guozhen Dong
China Telecom
Beijing
China
Email: donggz@chinatelecom.cn
Xu, et al. Expires 19 March 2023 [Page 8]
