Subject: [sidr] address space transfers, some thoughts

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Aug 2013 14:11:05 -0400

Folks,

Geoff raised some operational concerns about resource transfers and 
elected to address these concerns by suggesting changes to RFC 3779. I 
suggest we address the concerns by developing a protocol that allows 
such transfers to be largely automated, and to add more asynchronous 
capabilities to the processes. This is consistent with the advice 
provided by Chris Morrow after Geoff's presentation.

Also, I believe Sandy made an appeal to the RIRs to bring documentation 
to SIDR describing plans for inter-RIR transfers, over a year ago. 
George Michaelson provided a briefing
on why APNIC was plannign to rearrange it's RPKI TALs, in support of 
inter-RIR transfers, at the SIDR meeting in Orlando in March. This was a 
good start, but not a substitute for
a document (consistent with Geoff's comments on my LTAM presentation in 
Berlin). So, absent
a document describing inter-RIR transfers, the mechanism I describe 
below may not be
compatible in that context, but I believe it would work within an RIR, 
and probably will
work across RIR boundaries.

I present some thoughts on how to support transfers of in-use and unused 
resources, below. I suggest that we augment the up/down protocol with 
(at least) two new message types: transfer_request and 
transfer_response, and that we add a new RPKI signed object, to 
facilitate the process. These messages should follow the common message 
format described in Section 3.2 of RFC 6492.

To enable CAs to perform the process with minimal or no operator 
intervention, we need several capabilities added to the up/down 
protocol, via the new message types:

1.an INR holder needs to be able to signal that it relinquishing a 
resource as part of a transfer. For a transfer of unused resources, this 
could be done early in the process. For a live transfer, relinquishment 
would occur later. That suggests that we should signal whether the 
transfer is for live vs. unused resources.

2.The recipient of the resource needs to be able to demonstrate that the 
INR holder is transferring the resource to him/her, when requesting the 
resource be added to his/her CA certificate.

3.CAs above each party need to be able to determine that the transfer is 
taking place, consistent with the wishes of both parties.

4.The swing point for the transfer (the lowest CA in the tree on the 
certificate path between both parties) needs to be able to identify 
itself as the swing point, and thus behave differently from the CAs 
below it.

The procedure should protect against unauthorized attempts to transfer 
resources and attempts to divert a transfer to a different target INR 
holder. The up/down protocol makes use of a signing time attribute in 
the CMS envelope, and this should allow a CA to detect and reject replay 
attacks of these messages.

As noted a above I suggest that we add a pair of new up/down message 
types, modeled on the certificate request/response messages, called a 
transfer request/response. The transfer request message signals that the 
requester is asking to have a CA certificate re-issued with ether fewer 
or additional resources, as part of a transfer. The response returns a 
revised certificate, if needed, or indicates an response code. The 
request specifies the certificate to be modified (using the class name 
convention specified in [RFC6492]), the 3779 resources that the 
requester wants added or removed, a flag to indicate whether the 
transfer is of live or unused resources, and a URL pointing to a new 
RPKI object that supports the request.

I defer to Geoff and Rob for format details for the request and response 
messages, but we should maintain continuity with the payload design from 
[RFC6492]. The message payload needs to specify a resource set (v4, v6, 
and ASNs, as appropriate) and a URL needs to be signaled. The response 
will look a lot like the certificate response, since it will usually 
return a certificate, or an error indication. We can work out the 
details for that format later.

The TAO object will be signed by the INR holder who is transferring the 
resources. It will follow the format specified in RFC 6488, so it will 
have an embedded EE certificate. The payload will contain a 
specification of the resources being transferred, the SKI of the target 
INR holder (to whom the resources are being transferred), and the SKI of 
the INR holder relinquishing the prefixes. (This does require the target 
of the transfer to be a holder of some resources, and thus have an RPKI 
CA certificate.)

I call this this a transfer authorization object (TAO). The EE 
certificate for a TAO will contain a 3779 extension with the inherit bit 
set, and thus its validity will not be affected by the transfer. Since 
an SKI is used to identify each party, it is important that neither 
re-key during the process. For scheduled re-keys, this ought to be an 
easy constraint to impose.

Using a TAO to authorize the transfer enables CAs above the source and 
the target of the transfer, a well as the target itself, to "cite" the 
TAO as justification for their actions. This eliminates any notion of 
transitive trust for the transactions. It also create a record, 
accessible to third parties, showing that the source authorized the 
transfer, what resources are being transferred, and the target of the 
transfer. This may be helpful for entities that want to externally 
monitor RPKI activities to detect errors vs. authorized transfers.

The following steps describe how the process could work. I've used the 
entity labels fromyour slides to illustrate the transfer.

1. The source of the transfer (C) creates a TAO and places it in his/her 
publication point. C can send a message to the target of the transfer 
(E) with the URL. This enables E to begin his/her request in parallel 
with C's transfer request. (Alternatively, E can acquire the TAO at C's 
pub point as a side effect of normal repository scanning.) If this is a 
transfer of unused resources, C may revoke and delete any ROAs or router 
certificates that make use of these resources at this time. If the 
transfer is for live address space, any ROAs for that space remain 
unchanged for now.

2.a C sends a transfer request message to B, specifying the resources to 
be transferred, the type of transfer, and containing the URL for the 
TAO. If this is a transfer of unused resources, this request will result 
in a new certificate being issued to C, minus the resources being 
transferred. If it is a transfer of live resources, C's CA certificate 
is not yet modified, so no certificate will be returned.

The parent of the transfer source (B) uses the URL from the message to 
fetch the TAO from C's pub point and validates the signature on the TAO. 
B checks that the SKI of the issuer of the EE certificate for the TAO 
matches the SKI in the TAO. It verifies that the resources to be 
transferred to E are held by C, according to B's database.

If this a transfer of unused resources, B issues a new CA certificate to 
C, minus the resources being transferred, in the transfer_response 
message. B revokes the old certificate for C (after a suitable delay). 
If this is a transfer of live resources, B does not reissue C's 
certificate. It replies with a transfer_response message indicating that 
the transfer request is being processed.

In either case, B uses the SKI in the TAO to determine whether B is the 
swing point for the transfer. (It can perform this check this because it 
can locate E, the target, and determine if E is a child of B, directly 
or transitively. In performing this check, B also verifies that there is 
only one CA certificate with the indicated SKI.) In this example, B is 
not the swing point, so it generates a transfer_request message and 
sends it to A. This message includes the TAO URL from C.

If the request is for unused resources, this transfer_request will ask 
that B's CA certificate be reissued, minus the resources being 
transferred. If the request is for live resources, the message will not 
result in certificate reissuance for B.

2.b The transfer target, E, sends a transfer_request message to its 
parent, D, requesting a new CA certificate with the resources being 
transferred, and including the URL for the TAO issued by the transfer 
source (C). (Adding these resources to E's certificate is the desired 
outcome for both unused and live resources transfers.) D fetches the TAO 
from C's pub point and validates it's signature. It verifies that E is 
the target of the TAO, based on the SKI. If not, the request is rejected 
with an error code.

If E is the target of the request, D checks its database to see if it 
(D) holds the resources being requested. If so, it is the swing point 
and acts as A does in step 3, below. In this example, D is not the swing 
point, so it generates a transfer request for the resources to be added 
to its CA certificate, includes the TAO URL it received, and sends the 
request to its parent, A. D replies to the transfer request from E with 
a code indicating that the request is pending, awaiting receipt of the 
resources from its parent. This is analogous to the code used in a 
certificate request to indicate offline activity is needed to complete 
the request.

Note that steps 2.a and 2.b can occur in parallel.

3. When A receives the transfer_request message it fetches the TAO, 
verifies the signature, and matches the SKI of the CA that issued the 
TAO EE certificate against the SKI value in the TAO. C is not a child of 
A, so A cannot check its database to see if C held (holds) the resources 
being transferred. Instead, A checks its database to verify that B, the 
CA that sent the request holds the resources being transferred. (The 
general form of the check described in step 2 is to verify that the 
requester seeking to transfer resources holds them, according the 
database of the recipient of the request.)

If this is a transfer of unused resources, A will reissue C's CA 
certificate, minus the resources being transferred, and return the 
result in a transfer_response. It will later revoke B's old CA 
certificate. If this is a transfer of live resources, C's certificate 
will not be reissued; the transfer_response message will contain a 
status code. That code will indicate whether A is passing the request to 
its parent, or if it the swing point for the transfer (based on the test 
described below).

If the check described above succeeds, A uses the SKI for the target (E) 
to determine if it (A) is the swing point. In this example it is, so A 
will not generate another transfer_request message. Instead, A will note 
in its database that one of its children, D, is authorized to request 
the resources being transferred. (It can determine which of its children 
is on the path to E, so it knows that D should be requesting the 
resources.) If A already has a request for these resources pending from 
D, it will now satisfy that request by reissuing D's CA certificate with 
the new resources, and sending a transfer_response message to D. It will 
revoke and delete D's old CA certificate (after a suitable delay). If A 
does not have a pending request from D, it will await such a request.

Once D has receives a transfer_response from its parent (A), it can 
reply to a new or pending request from E, reissuing E's CA certificate 
with the transferred resources.

If the transfer was of unused space, the process is complete at this 
stage (once the intermediate CA certificates have been revoked and 
deleted). If the transfer was for live resources, both C and E (and 
their parents) will be recognized as authorized INR holders for these 
resources, until C relinquishes them. Relinquishing the resources is an 
action initiated by C, the transfer source. This probably requires 
another message pair type, to cause the ancestors of C to remove the 
transferred resources from their CA certificates, up to the swing point, 
in the way that a transfer of unused resources would have proceeded.

This process should avoid the serialization concerns Geoff cited. Both 
the source and target, C and E, can pursue the transfer asynchronously, 
after C posts it's TAO. The swing point becomes the gating entity in the 
process, as it should be. Use of a deferred-reply model, up the chain 
from the transfer target, allows these requests to rendezvous at the 
swing point, where the request can be satisfied once it has moved up the 
chain from the transfer source.

The TAO has a validity time interval, indicated in its EE certificate. 
Further thought is needed to decide whether this info might be useful 
after a transfer has been effected. For example, the notAfter date 
indicate when the transfer initiator will relinquish the resources for a 
transfer of live address space. We also need to contemplate what 
guidance we should give to a transfer source with respect to choosing a 
validity interval for a TAO, for both unused and live transfers.

The checks described at each stage are designed to ensure three security 
goals are met:

-the TAO is authentic and issued by the indicated transfer source

-the transfer target is authorized to receive the resources by the 
transfer source

-the requesting CA at each stage either holds the

resources being transferred, or it is on the path to the transfer target

Up/down protocol messages contain a time-based anti-reply feature, so 
replays of those (signed messages) can be detected. If a request message 
is redirected, a CA receiving it will detect and reject this because the 
request will not be from one of its children. A redirected response 
message also will be detected because (how does the up/down protocol 
ensure this?).