| Internet-Draft | RISAV | September 2022 |
| Xu, et al. | Expires 19 March 2023 | [Page] |
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes no place with inspection of the source address. Therefore, malicious attacks or behaviors have been launched with spoofed source addresses. This document defines using RPKI (Resource Public Key Infrastructure) and IPsec (IP Security) to reinforce the security of source addresses in the inter-domain layer.¶
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 (c) 2022 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.¶
IP spoofing has been a long-recognized threat to Internet security for decades. Source Address Validation (SAV) provides the integrity of the source address to IP packet. Source Address Validation Architecture (SAVA) has been proposed at [RFC5210]. Inter-domain source address validation 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 implementations with the scalability of large-scale deployments. uRPF [RFC5635], for example, routing-based schemes 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.¶
This document provides an RPKI and IPsec-based inter-domain end-to-end approach to source address validation (RISAV). RISAV is a cryptography-based SAV to guarantee consistent security benefits, which combines RPKI (Resource Public Key Infrastructure), IKE (Internet Key Exchange), and IPsec AH (IPsec Authentication Header). RPKI provides the reflection relationship between AS numbers (ASN) and IP prefixes. IKE negotiates between two ASes with the Security Association (SA) which contains the algorithm, secret key generating material, and IPsec packet type, and so forth. IPsec AH is the authentication header that is used to provide authenticity of the whole packet, including the source address, in IPsec.¶
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.¶
AS Control Server, which is responsible for delivering tags and other information to ASBR.¶
AS border router, which is at the boundary of an AS that runs BGP.¶
The bit-string that authenticates identification of source address of a packet.¶
The final bit-string is placed at the AH's field, which is different for each packet.¶
RISAV is a cryptography-based end-to-end inter-domain source address validation method that guarantees security benefits at partial deployment. RISAV uses RPKI to obtain the binding relationship between AS numbers and IP prefixes. After that, it uses IKE to negotiate the IKE SA and IPsec SA for generating the tag presenting the integrity of the IP source address. And the IPsec Authentication Header (AH) would be used to carry the tag in communication.¶
A typical workflow of RESAVRI is shown in Figure 1.¶
+--------------+
| IANA |
+--------------+
|--------------------------+
V |
+--------------+ |
| RIR | |
+--------------+ |
/ \-----------------+-1. signed CA
V V | certificate
+--------------+ +--------------+ |
| LIR1 | | LIR2 | |
+--------------+ +--------------+ |
/ \-+
V +------ 2. signed EE ceritficate -------+ V
+--------------+ | | +--------------+
| | | -------------------------------- | | |
| | | 3. IKE negotiation | | |
| AS A | | -------------------------------- | | AS B |
| | V V | |
| ######## -------------------------------- ######## |
| # ASBR # 4. SA Deliver # ASBR # |
| ######## -------------------------------- ######## |
| | | Prefix Y |
| Prefix X | +++++++++++++++++++++++++++++++++ | Public Key B |
| Public Key A | 5. data transmission | |
| | using IPsec AH | |
| | +++++++++++++++++++++++++++++++++ | |
+--------------+ +--------------+
The functions of the control plane of RISAV include ASN-Prefix relationship announcement, Tag management, and ASN-Tag relationship announcement.¶
RISAV uses RPKI to manage the relationship between ASN and IP prefixes. So when one AS wants to deploy RISAV, it should implement RPKI first. When RPKI is deployed, the validated ROA cache SHOULD be sent to the ASBR for routing and forwarding packets.¶
The ROA whose status is valid can be used with IPsec to prevent source address spoofing. That means only the prefix contained in valid ROA would valuably and correctly be protected.¶
For more information about RPKI, one can refer to [RFC6480].¶
Before introducing the ASN-Tag relationship announcement, it shall be described what is a tag and how it is generated.¶
A tag is a variable bit-string that is generated at an entity in AS. This entity is AS Control Server (ACS). The tag is used with the authentication algorithm to generate the signature. That means the tag is the key to the authentication. When communicating, the tag would not be directly tagged to the IPsec AH of the packet, replacing it with a signature instead, which will be different with different packets. One AS SHOULD have at most two tags in effect in the same bound simultaneously for Key-Rover.¶
It has two ways for an ACS to generate tags. One is using a state machine. The state machine runs and triggers the state transition when time is up. The tag is generated in the process of state transition as the side product. The two ACS in peer AS respectively before data transmission will maintain one state machine pair for each bound. The state machine runs simultaneously after the initial state, state transition algorithm, and state transition interval are negotiated, thus they generate the same tag at the same time. Time triggers state transition which means the ACS MUST synchronize the time to the same time base using like NTP defined in [RFC5905].¶
The other way to generate a tag is by applying the original SA. The IPsec channel is established when the IKE_AUTH process is finished. SA includes the specified AH, the authentication algorithm, the key used for authentication, etc. So two IKE entities have negotiated SA. All ASBR in one AS SHOULD use the same SA.¶
When it chooses to use a logical ACS, one AS will elect one distinguished ASBR as the ACS. The distinguished ASBR acting as an ACS will represent the whole AS to communicate with peer AS's ACS. This election takes place prior to the IKE negotiation. An ASBR MUST be a BGP speaker before it is elected as the distinguished ASBR. This is an OPTIONAL operation to use this logical ACS.¶
Corresponding to the tag generating, it also has two ways to announce the ASN-Tag binding relationship. The first is to deliver the generated tags and the second is to deliver the original SA.¶
Thus, there must be a header format definition to transfer these tags and SA. In RISAV, it uses the header and payload formats defined in [RFC5996]. Meanwhile, there are some almost negligible changes to the formats. For the tag generation method, it MUST be to specify the initial state and initial state length of the state machine, the identifier of a state machine, state transition interval, length of generated Tag, and Tag. For the SA, they will transfer all these payloads in a secure channel between ACS and ASBRs, for instance, in ESP [RFC4303]. It is RECOMMENDED to transfer the tags rather than the SA for security and efficiency considerations. The initial state and its length can be specified at the Key Exchange Payload with nothing to be changed. The state machine identifier is the SPI value as the SPI value is uniquely in RISAV. The state transition interval and length of generated Tag should be negotiated by the pair ACS, which will need to allocate one SA attribute. The generated Tag will be sent from ACS to ASBR in a secure channel which MAY be, for example, ESP [RFC4303].¶
The functions of the data plane of RISAV include source address checking and tag processing.¶
RISAV redesign the original AH format as shown in Figure 2.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | SIG Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature - SIG (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The prefix length in valid ROA matched the IP source address. It presents the valid length of the IP source address prefix.¶
The length of the variable signature. It is the octets in Signature.¶
The result of the authentication algorithm with the key.¶
All the ASBRs of the AS are REQUIRED to enable RISAV. And RISAV can OPTIONAL cooperate with intra-domain SAV and access-layer SAV, such as [RFC8704] or SAVI [RFC7039]. Only when intra-domain or access-layer SAV, if deployed, check passed can the packet process and forward correctly. It uses SPI for destination ASBR to locate the SA uniquely when processing the AH header in RISAV.¶
As defined in [RFC4301], the Security Association Database (SAD) stores all the SAs. One data item in SAD includes an Authentication algorithm and corresponding key when AH is supported. The authentication algorithm could be HMAC-MD5, HMAC-SHA-1, or others. As authenticating the whole packet causes a heavy burden in the computation, RISAV defines that it only authenticates the IP source address, IP destination address, and the IP prefix length in ROA, SPI, and Sequence Number Field. The eventual signature is the hash of the 5-tuple before with the key/tag.¶
When a packet arrives at the source ASBR, it will be checked with the destination address by this ASBR first. If the destination address is in the protection range of RISAV, the packet will be checked by the source address next. If the source address belongs to the AS in which the ASBR locates, the packet needs to be filled in the AH header.¶
When a packet arrives at the destination ASBR, it will be checked the destination address and the source address orderly. If the destination belongs to the AS that the destination ASBR locates in and the source address seats in the RISAV protection area, the packet needs to be inspected with the AH header.¶
So far, IPsec is often used as a VPN which is a technology for private network access through public networks. In the final analysis, IPsec is a highly cost-effective ratio mechanism. Original IPsec AH needs to authenticate the whole constant part of a packet so that it needs to spend amounts of time finding and processing unchangeable fields in the packet. However, RISAV only needs to find a few changeless fields to authenticate the packet decreasing the cost dramatically.¶
When using RISAV, it WOULD be used at last when all other IPsec SA does not match. Such that, RISAV is comparable with the current IPsec Security Architecture. It SHOULD be guaranteed that the preference of RISAV is lower than other IPsec. So it may require the special SPI filled.¶
For resisting label-based reply attacks, the eventual signature used in a packet is generated by the ASBR by hashing a few fields including the IP source address, IP destination address, and the IP prefix length in ROA, SPI, and Sequence Number Field. The attacker could guess the signature and crack that key using brute force. Nevertheless, it depends on the irreversibility of a hash function to prevent backstepping the key from the signature. Furthermore, to decrease such probability, the key used in generating the signature will be updated periodically.¶
TBD.¶