An RPKI and IPsec-based End-to-End Approach for Source Address Validation

Introduction 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 . 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 , 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.

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 when, and only when, they appear in all capitals, as shown here. Commonly used terms in this document are described below.

ACS:: AS Control Server, which is responsible for delivering tags and other information to ASBR.
ASBR:: AS border router, which is at the boundary of an AS that runs BGP.
Tag:: The bit-string that authenticates identification of source address of a packet.
Signature:: The final bit-string is placed at the AH's field, which is different for each packet.

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

RPKI process. The five Reginal Internet Registry (RIR) would be authorized by IANA. They use their root certificate to sign the Certificate Authority (CA) certificate of the Local Internet Registry (LIR). And after that LIR would use a CA certificate to authorize indirectly the Internet Service Provider (ISP) or directly the Autonomous System (AS). When they obtain their own CA certificate, the AS would sign an End Entity (EE) certificate with a Route Origin Authorisation (ROA) which is a cryptographically signed object that states which AS are authorized to originate a certain prefix. Such the reflection of ASN relationship with IP prefixes would be broadcast to the network.
Sign ASBR EE certificate. This EE certificate is just like the BGPsec Router Certificate defined in . The ASBR would need its own EE certificate for and only for generating and verifying the signature in the AH header directly or indirectly.
IKE process. Before IPsec establishing, the SA must be reached an agreement. There are two ways to negotiate the SA. One is mutual config all the parameters and the other one is using IKE for dynamic negotiating these parameters. Currently used is IKE version 2 (IKEv2, for short using IKE below). Typically, IKE would produce IKE SA in the IKE_SA_INIT exchange and IPsec SA in the IKE_AUTH exchange. This will be done in an ACS.
SA or tag delivery. When all negotiations are done, the IPsec is established. If the ACS is an ASBR actually, it would deliver SA to the other ASBR in this AS. Otherwise, it would deliver the tags generated by the state machine. This delivery will be processed in a secure channel just like using IPsec ESP.
IPsec AH communication. It uses IPsec AH for authentication of the IP source address. IPsec is offten used in tunnel mode as the IPsec VPN. Here, It expands the gateway to the AS border router (ASBR). When two ends x and y in AS X and Y respectively are communicating, the packet from x arriving at its ASBR RA would use the established IPsec channel for adding the representative tag. After the packet arrives at ASBR RB of AS Y, it would be inspected by comparing the consistency of the tag. The tag will be encapsulated in the ICV field in AH.

A typical workflow of RESAVRI is shown in .

ERISAV workflow example.

Control Plane The functions of the control plane of RISAV include ASN-Prefix relationship announcement, Tag management, and ASN-Tag relationship announcement.

ASN-Prefix 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 .

Tag management 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 . 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.

ASN-Tag relationship announcement 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 . 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 . 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 .

Data Plane The functions of the data plane of RISAV include source address checking and tag processing. RISAV redesign the original AH format as shown in .

RISAV AH Format.

Prefix Length:: The prefix length in valid ROA matched the IP source address. It presents the valid length of the IP source address prefix.
SIG Length:: The length of the variable signature. It is the octets in Signature.
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 or SAVI . 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 , 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.

Incremental deployment 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.

Security Consideration

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

Key Guessing and Cracking 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.

IANA Consideration TBD.