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

1.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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Terminology

Commonly used terms in this document are described below.¶

ACS:

AS Contact Server, which is the logical representation of one AS and is responsible for delivering session keys and other information to ASBR.¶

Contact IP:

The IP address of the ACS.¶

ASBR:

AS border router, which is at the boundary of an AS.¶

SAV:

Source Address Validation, which verifies the source address of an IP packet and guarantees the source address is valid.¶

2.1. What RISAV Is and Is Not

RISAV is a cryptographically-based inter-AS source address validation protocol that provides clear security benefits even at partial deployment. It is lightweight and efficient and provides incremental deployment incentives.¶

RISAV adds IP packet header authentication to IPsec. It aims to prove that each IP datagram was sent from inside the AS that owns its source address, defeating spoofing and replay attacks. It supports, but does not require, encryption of the whole IP packet.¶

RISAV does not aim to defend against specific network attacks such as DoS or DDoS, though RISAV could do more help to avert them.¶

2.2. How RISAV Works

A typical workflow of RISAV is shown in Figure 1.¶

                            +-------------+
                            |    IANA     |
                            +-------------+
                                   |-------------------------+
                                   V                         |
                            +-------------+                  |
                            |     RIR     |                  |
                            +-------------+                  |
                           /               \-----------------+-1. Signing CA
                          V                 V                |  Certificate
              +--------------+              +--------------+ |
              |     LIR1     |              |     LIR2     | |
              +--------------+              +--------------+ |
              /                                            \-+
             V                                              V
+--------------+                                          +--------------+
| 3. RISAV     |---------+                         +------| 3. RISAV     |
| Announcement |         |2. Signing EE Certificate|      | Announcement |
|              | +-------+                         +----+ |              |
|     AS A     | |                                      | |     AS B     |
| contact IP a | V                                      V | contact IP b |
|           #######  --------------------------------  #######           |
|           # ACS #   4. SA Negotiation and Delivery   # ACS #           |
|           #######  --------------------------------  #######           |
|              |                                          |              |
|           ######## +++++++++++++++++++++++++++++++++ ########          |
|           # ASBR #      5. Data Transmission         # ASBR #          |
|           ########        with IPsec AH/ESP          ########          |
|              |     +++++++++++++++++++++++++++++++++    |              |
+--------------+                                          +--------------+

3.1. Enabling RISAV

When RISAV is to be enabled, it should:¶

• announce that this AS supports RISAV,¶

• publish contact IPs,¶

• and perform IPsec session initialization (i.e. IKEv2).¶

These functions are achieved in two steps. First, each participating AS publishes a Signed Object [RFC6488] in its RPKI Repository containing a RISAVAnnouncement. The ASN.1 form of RISAVAnnouncement is as follows:¶

RPKI-RISAV-2023
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) smime(16) modules(0) id-mod-rpki-risav-2023(TBD) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  CONTENT-TYPE
  FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;

  IPAddressFamily, IPAddress
  FROM IPAddrAndASCertExtn -- In [RFC3779]
    { iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) } ;

ct-rpkiRISAVAnnouncement CONTENT-TYPE ::=
     { TYPE RISAVAnnouncement
       IDENTIFIED BY id-ct-risav }

id-ct-risav OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) risav(TDB2) }

RISAVAnnouncement ::= SEQUENCE {
  version [0] INTEGER DEFAULT 0,
  asID ASID,
  contactIP SEQUENCE (SIZE(1..2)) OF IPAddressFamily,
  testing BOOLEAN DEFAULT FALSE }

ASID ::= INTEGER
END

• version: The version number of RISAVAnnouncement here MUST be 0.¶

• asID: The asID field contains the AS number of one Autonomous System that is going to support RISAV.¶

• contactIP: Within the IPAddressFamily structure, addressFamily contains the Address Family Identifier (AFI) of an IP address family. Contact IP of RISAV only supports IPv4 and IPv6 but there could be one more IPv4 or IPv6 address. Therefore, addressFamily MUST be either 0001 or 0002 while addresses are a list of IP addresses. The inherit attribute MUST be prohibited in IPAddressChoice as there is no need to look into the list of historical contactIPs.¶

• testing: The "testing" field indicates whether this contact IP is potentially unreliable. When this field is set to true, other ASes MUST fall back to ordinary operation if IKE negotiation fails. Otherwise, the contact IP is presumed to be fully reliable, and other ASes SHOULD drop all non-RISAV traffic from this AS if IKE negotiation fails (see Section 8.1.2). So it has the default value of FALSE.¶

When a participating AS discovers another participating AS (via its general synchronization process of the RPKI database), it initiates an IKEv2 handshake between its own contact IP and the other AS's contact IP. This handshake MUST include an IKE_AUTH exchange that authenticates both ASes with their RPKI ROA certificates.¶

Once this handshake is complete, each AS MUST activate RISAV on all outgoing packets, and SHOULD drop all non-RISAV traffic from the other AS after a reasonable grace period (e.g. 60 seconds).¶

RISAV participants add one or more RISAVAnnouncements to the repository of RPKI. The RPKI procedures are otherwise the same as in the traditional RPKI. For more information about RPKI, see [RFC6480].¶

3.2. Disabling RISAV

3.3. Green Channel

In the event of a misconfiguration or loss of state, it is possible that a negotiated SA could become nonfunctional before its expiration time. For example, if one AS is forced to reset its ACS and ASBRs, it may lose the private keys for all active RISAV SAs. If RISAV were applied to the IKEv2 traffic used for bootstrapping, the participating ASes would be unable to communicate until these broken SAs expire, likely after multiple hours or days.¶

To ensure that RISAV participants can rapidly recover from this error state, RISAV places control plane traffic in a "green channel" that is exempt from RISAV's protections. This "channel" is defined by two requirements:¶

• RISAV senders MUST NOT add RISAV protection to packets to or from any announced contact IP¶

• RISAV recipients MUST NOT enforce RISAV validation on packets sent to or from any announced contact IP.¶

Although the green channel denies RISAV protection to the ACS, the additional mitigations described in Section 4 ensure that the ACS has limited exposure to address-spoofing and DDoS attacks. In addition, the ACS can use the IKEv2 COOKIE (Section 2.6 of [RFC7296]) and PUZZLE ([RFC8019]) systems to reject attacks based on source address spoofing.¶

4.1. Transport Mode

To avoid conflict with other uses of IPsec (Section 8.3.1), RISAV updates the IPsec Authentication Header (AH) format, converting one RESERVED octet (which is previously required to always be zero) into a new "Scope" field. The updated format is 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    |     Scope     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Security Parameters Index (SPI)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Sequence Number Field                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                Integrity Check Value-ICV (variable)           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The "Scope" field identifies the scope of protection for this authentication header, i.e. the entities that are expected to produce and consume it. Two Scope values are defined:¶

• 0: IP. This is the pre-existing use of the Authentication Header, to authenticate packets from the source IP to the destination IP.¶

• 1: AS. This header authenticates the packet from the source AS to the destination AS.¶

Other Scope values could be defined in the future.¶

The AS-scoped AH headers are only for AS-to-AS communication. Sending ASes MUST NOT add such headers unless the receiving AS has explicitly opted to receive them. Receiving ASes MUST strip off all such headers for packets whose destination is inside the AS, even if the AS is not currently inspecting the ICV values.¶

Transport mode normally imposes a space overhead of 32 octets, no more than general IPsec AH.¶

4.2. Tunnel Mode

As RISAV does not require encryption for packet, so it uses ESP-NULL to authenticate the packet in tunnel mode.¶

Traditionally, the ESP ICV is computed on the entire ESP packet, excluding the Authentication Data field. Here, in RISAV, the ESP ICV SHOULD be calculated including the IP Source Address at first, following by SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header. Destination Address is ignored.¶

In tunnel mode, a RISAV sender ASBR wraps each outgoing packet in an ESP payload ([RFC4303]) and sends it as directed by the corresponding SA. This may require the ASBR to set the Contact IP as the source address, even if it would not otherwise send packets from that address. (See also "Anycast", Section 9.1).¶

Tunnel mode imposes a space overhead of 73 octets in IPv6.¶

5.1. MTU Enforcement

In tunnel mode, RISAV ASBRs MUST treat the tunnel as a single IP hop whose MTU is given by the current (estimated) inner MTU. Oversize packets that reach the ASBR SHALL generate Packet Too Big (PTB) ICMP responses (or be fragmented forward, in IPv4) as usual.¶

In transport mode, RISAV ASBRs SHOULD NOT enforce the estimated inner MTU. Instead, ASBRs SHOULD add RISAV headers and attempt to send packets as normal, regardless of size. (This may cause a PTB ICMP response at the current router or a later hop, which is modified and forwarded as described in Section 4.1.1.)¶

In either mode, the ASBR SHOULD apply TCP MSS clamping [RFC4459], Section 3.2 to outbound packets based on the current estimated inner MTU.¶

5.2. MTU Estimation

This section describes an MTU estimation procedure that is considered acceptable for deployment of RISAV. Other procedures with similar performance may also be acceptable.¶

6.1. Disabling replay protection

In the simplest RISAV configuration, the sending AS requests creation of a single "Child SA" whose Traffic Selector-initiator (TSi) lists all the IP ranges of the sending AS, and the Traffic Selector-responder (TSr) lists all the IP ranges of the receiving AS. This allows a single SA to carry all RISAV traffic from one AS to another. However, this SA is likely to be shared across many ASBRs, and potentially many cores within each ASBR, in both participating ASes.¶

It is difficult or impossible for a multi-sender SA to use monotonic sequence numbers, as required for anti-replay defense and Extended Sequence Numbers (ESN) (see [RFC4303], Section 2.2). If the sender cannot ensure correctly ordered sequence numbers, it MUST set the REPLAY-STATUS indication to FALSE in the CREATE_CHILD_SA notification, and MUST delete the SA if the recipient does not confirm that replay detection is disabled.¶

6.2. Enabling replay protection

If the sender wishes to allow replay detection, it can create many Child SAs, one for each of its ASBRs (or each core within an ASBR). The OPTIONAL CPU_QUEUES IKEv2 notification [I-D.ietf-ipsecme-multi-sa-performance] may make this process more efficient. If the sending ASBRs are used for distinct subsets of the sender's IP addresses, the TSi values SHOULD be narrowed accordingly to allow routing optimizations by the receiver.¶

Even if the sender creates many separate SAs, the receiver might not be able to perform replay detection unless each SA is processed by a single receiving ASBR. In Tunnel Mode, the receiver can route each SA to a specific ASBR using IKEv2 Active Session Redirect ([RFC5685], Section 5).¶

In Transport Mode, assignment of SAs to receiving ASBRs may be possible in cases where each ASBR in the receiving AS is responsible for a distinct subset of its IPs. To support this configuration, the receiving AS MAY narrow the initial TSr to just the IP ranges for a single ASBR, returning ADDITIONAL_TS_POSSIBLE. In response, the sending AS MUST reissue the CREATE_CHILD_SA request, with TSr containing the remainder of the IP addresses, allowing the negotiation of separate SAs for each receiving ASBR.¶

Future IKEv2 extensions such as Sequence Number Subspaces [I-D.ponchon-ipsecme-anti-replay-subspaces] or Lightweight SAs [I-D.mrossberg-ipsecme-multiple-sequence-counters] may enable more efficient and easily deployed anti-replay configurations for RISAV.¶

6.3. Changes to AS IP ranges

If the ACS receives a TSi value that includes IP addresses not owned by the counterpart AS, it MUST reject the SA to prevent IP hijacking. However, each AS's copy of the RPKI database can be up to 24 hours out of date. Therefore, when an AS acquires a new IP range, it MUST wait at least 24 hours before including it in a RISAV TSi.¶

If a tunnel mode SA is established, the receiving AS MUST drop any packet from the tunnel whose source address is not within the tunnel's TSi.¶

7.1. Header-only authentication

An IPsec Authentication Header authenticates the whole constant part of a packet, including the entire payload. To improve efficiency, we could define an IKE parameter to negotiate a header-only variant of transport mode that only authenticates the IP source address, IP destination address, etc.¶

This would likely result in a 10-30x decrease in cryptographic cost compared to standard IPsec. However, it would also offer no SAV defense against any attacker who can view legitimate traffic. An attacker who can read a single authenticated packet could simply replace the payload, allowing it to issue an unlimited number of spoofed packets.¶

7.2. Time-based key rotation

Each IKEv2 handshake negotiates a fixed shared secret, known to both parties. In some cases, it might be desirable to rotate the shared secret frequently:¶

• In transport mode, frequent rotation would limit how long a single packet can be replayed by a spoofing attacker.¶

• If the ASBRs are less secure than the ACS, frequent rotation could limit the impact of a compromised ASBR.¶

However, increasing the frequency of IKEv2 handshakes would increase the burden on the ACS. One alternative possibility is to use 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].¶

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].¶

7.3. Static Negotiation

The use of IKEv2 between ASes might be fragile, and creates a number of potential race conditions (e.g. if the RPKI database contents change during the handshake). It is also potentially costly to implement, requiring O(N^2) network activity for N participating ASes. If these challenges prove significant, one alternative would be to perform the handshake statically via the RPKI database. For example, static-static ECDH [RFC6278] would allow ASes to agree on shared secrets simply by syncing the RPKI database.¶

Static negotiation makes endpoints nearly stateless, which simplifies the provisioning of ASBRs. However, it requires inventing a novel IPsec negotiation system, so it seems best to try a design using IKEv2 first.¶

8.1. Threat models

In general, RISAV seeks to provide a strong defense against arbitrary active attackers who are external to the source and destination ASes. However, different RISAV modes and configurations offer different security properties.¶

8.2. Incremental benefit from partial deployment

RISAV provides significant security benefits even if it is only deployed by a fraction of all ASes. This is particularly clear in the context of reflection attacks. If two networks implement RISAV, no one in any other network can trigger a reflection attack between these two networks. Thus, if X% of ASes (selected at random) implement RISAV, participating ASes should see an X% reduction in reflection attack traffic volume.¶

8.3. Compatibility

9.1. Reliability

The ACS, represented by a contact IP, must be a high-availability, high-performance service to avoid outages. There are various strategies to achieve this, including:¶

• Election. This might be achieved by electing 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. In this arrangement, an ASBR MUST be a BGP speaker before it is elected as the distinguished ASBR, and a new election MUST replace the ACS if it fails.¶

• Anycast. The ACS could be implemented as an anycast service operated by all the ASBRs. Route flapping can be mitigated using IKEv2 redirection ([RFC5685], Section 4). Negotiated SAs must be written into a database that is replicated across all ASBRs.¶

9.2. Synchronizing Multiple ASBRs

To ensure coherent behavior across the AS, the ACS MUST deliver each SA to all relevant ASBRs in the AS immediately after it is negotiated. RISAV does not standardize a mechanism for this update broadcast.¶

During the SA broadcast, ASBRs will briefly be out of sync. RISAV recommends a grace period to prevent outages during the update process.¶

9.3. Performance

RISAV requires participating ASes to perform symmetric cryptography on every RISAV-protected packet that they originate or terminate. This will require significant additional compute capacity that may not be present on existing networks. However, until most ASes actually implement RISAV, the implementation cost for the few that do is greatly reduced. For example, if 5% of networks implement RISAV, then participating networks will only need to apply RISAV to 5% of their traffic.¶

Thanks to broad interest in optimization of IPsec, very high performance implementations are already available. For example, as of 2021 an IPsec throughput of 1 Terabit per second was achievable using optimized software on a single server [INTEL].¶

9.4. NAT scenario

As all the outer IP header should be the unicast IP address, NAT-traversal mode is not necessary in inter-AS SAV.¶

10.1. IPv6

RISAV modifies the handling of IPv6 packets as they traverse the network, resulting in novel networking behaviors. This section describes why those behaviors should not be viewed as violating the requirements of [RFC8200].¶

10.2. RPKI Usage

[RFC9255] describes limits on the use of RPKI certificates for new purposes, including the following excerpts:¶

• The RPKI was designed and specified to sign certificates for use within the RPKI itself and to generate Route Origin Authorizations (ROAs) [RFC6480] for use in routing. Its design intentionally precluded use for attesting to real-world identity...¶

• RPKI-based credentials of INRs MUST NOT be used to authenticate real-world documents or transactions.¶

• When a document is signed with the private key associated with an RPKI certificate, the signer is speaking for the INRs (the IP address space and AS numbers) in the certificate. ... If the signature is valid, the message content comes from a party that is authorized to speak for that subset of INRs.¶

RISAV's usage of RPKI key material falls squarely within these limits. The RPKI signature used in the IKEv2 handshake serves only to confirm that this party is authorized to originate and terminate IP packets using the corresponding IP ranges. The "identity" of this party is not relevant to RISAV.¶

11.1. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)

Please add the id-mod-rpki-risav-2023 to the SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry (https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#security-smime-0) as follows:¶

Decimal    Description                   Specification
---------------------------------------------------------------------
TBD        id-mod-rpki-risav-2023        [RFC-to-be]

11.2. SMI Security for S/MIME CMS Content Type registry

Please add the RISAVAnnouncement to the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry (https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#security-smime-1) as follows:¶

Decimal     Description                    Specification
---------------------------------------------------------------------
TBD         id-ct-risav                    [RFC-to-be]

11.3. RPKI Signed Object registry

Please add RISAVAnnouncement to the RPKI Signed Object registry (https://www.iana.org/assignments/rpki/rpki.xhtml#signed-objects) as follows:¶

Name          OID                          Specification
---------------------------------------------------------------------
RISAV
Announcement  1.2.840.113549.1.9.16.1.TBD  [RFC-to-be]

11.4. RPKI Repository Name Scheme Registry

Please add an item for the RISAV Announcement file extension to the "RPKI Repository Name Scheme" registry created by [RFC6481] as follows:¶

Filename
Extension  RPKI Object                      Reference
---------------------------------------------------------------------
.ra        RISAVAnnouncement                [RFC-to-be]

A.1. Direct Attack

The packet with a spoofed address will go to the victim directly. These attacks include DoS, DDoS, flooding-based attacks, etc. In this case, it is hard to say whether this action is launched by the user's misconfiguration or a malicious attacker's intent even if SAV is deployed. But SAV could help to locate where the abnormal traffic originates and to stop it as soon as possible.¶

A.2. Reflection Attack

Attackers would not send packets to victims directly, but they would send packets to a server that runs amplification services, such as DNS, NTP, SNMP, SSDP, and other UDP/TCP-based services. The packet sent to the public server would be multiplicatively amplified and replied to the victim, which would be more destructive than a direct attack. In this case, if SAV is deployed, attackers can almost not launch such attacks.¶