Subject: Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Jul 2016 10:54:17 -0400

Randy,

I presume you are referring to the text that describes ROA competition, 
although you didn't cite specific text in your message (too much typing?).

I'll revise that text to note the case of a resource transfer appears to 
be competition, absent any additional info labeling it as such. That's a 
good reason to adopt the TAO record that we proposed long ago, as part 
of a well-documented description of how to effect transfers. There are 5 
places where the word "competition" appears later in the document. I'll 
review these and see if I think any of them need to revised in light of 
your comment.

Steve

---

From: Randy Bush <[email-masked]>
Date: Sat, 02 Jul 2016 07:39:25 +0900

> be competition

it is more than transfer.  it is the very frequent operation of changing
tranist providers.  i own P, but do not use bgp.  my parent T0 announces
it for me (roa P-T0).  i change upstream providers to T1.  during the
move there are two roas, the second being P-T1.

this all was very intentionally designed for make before break.
multiple roas with different ASs for the same prefix are normal.  i
found it shocking and disappointing to have the introduction say
otherwise.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 5 Jul 2016 12:19:42 -0400

Speaking as regular ol’ member:

> found it shocking and disappointing to have the introduction say

As an aside, one of my favorite BGP sites is bgp.he.net, which includes a list of prefixes that are announced by more than one AS (http://bgp.he.net/report/multi-origin-routes).  Many times it is easy to see why - the similarity in the AS names make it quite likely they “belong” to the same organization.   But there are many times when the multiple origin ASs have no relationship.

I don’t see that there’s a requirement that a router have only one certificate, either.  A router that was configured to speak as two different ASs might have one key certified by both ASs and might have two different keys, one for each AS.

—Ssandy

> 
> randy
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Jul 2016 02:45:01 +0900

> I don’t see that there’s a requirement that a router have only one
> certificate, either.  A router that was configured to speak as two
> different ASs might have one key certified by both ASs and might have
> two different keys, one for each AS.

that this is designed in is not an accident.  we had this discussion,
just as we had the multi-roa discussion; but they are ops complexity, so
easly ignored/forgotten.

randy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jul 2016 13:39:03 -0400

Randy,

Thanks for providing additional examples to clarify your concerns.

I'll revise the intro text accordingly.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jul 2016 13:39:57 -0400

Sandy,

> I don’t see that there’s a requirement that a router have only one certificate, either.  A router that was configured to speak as two different ASs might have one key certified by both ASs and migh…
There was no intent to suggest that a router have only one cert. Sorry 
for the sloppy wording.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jul 2016 13:42:11 -0400

Here is the revised text for the relevant part of the intro.

I don't see a need to change the text in the specific attack 
descriptions, given this revised intro text.

    Additionally, when a ROA or router certificate is created that

"competes" with an existing ROA or router certificate (respectively),

the creation of the new ROA or router certificatemay be adverse.

(A newer ROA competes with an older ROA if the newer ROA points to a

different ASN, contains the same or a more specific prefix, and is

issued by a different CA.A newer router certificate competes with

an older router certificate if the newer one contains the same ASN

a different public key, and is issued by a different CA.) Note that

transferring resources, or changing of upstream providers may yield

competing ROAs and/or router certificates, under some circumstances.

Thus not all instances of competition are adverse actions.

Steve

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 6 Jul 2016 18:46:12 +0000

>A newer ROA competes with an older ROA if the newer ROA points to a

   different ASN, contains the same or a more specific prefix, and is
   issued by a different CA.

For DDoS mitigation service, (as an example) a /16 prefix owner may create (well in advance)
two new ROAs for more specific /17s (covered by the /16 prefix).
The new ROAs would have a different ASN – the ASN of the DDoS mitigation service provider.
The CA remains the same.
(The prefix owner already has a /16 ROA with its own ASN for its normal route announcement.)
The idea is that in the event of a DDoS attack, the mitigation service provider will be able to
announce the more specifics immediately and attract the attack traffic away from the victim.

Would you consider these two new ROAs as competing ROAs?  Or, is there a different name for them?
They would be competing (for a good purpose) with the /16 ROA only in emergency scenarios.

Sriram

From: sidr [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Wednesday, July 06, 2016 1:42 PM
To: Randy Bush <[email-masked]>; Sandra Murphy <[email-masked]>
Cc: sidr wg list <[email-masked]>
Subject: Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00

I don't see a need to change the text in the specific attack descriptions, given this revised intro text.

   the creation of the new ROA or router certificate may be adverse.

   issued by a different CA.  A newer router certificate competes with

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jul 2016 15:27:21 -0400

Sriram,

> a different name for them?
because the CA is the same for both ROAs, they are not competing, based 
on the revised definition that you cited above.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 13 Jul 2016 19:33:20 -0400

There’s been a rather energetic conversation about this but not many people involved.

The wglc needs some more reviewers and commenters to gauge consensus.

There’s just a few days left - please consider reviewing the draft and providing comments and publication worthiness to the list.

—Sandy

> On Jun 30, 2016, at 5:11 PM, Sandra Murphy <[email-masked]> wrote:
> 
> The authors of draft-ietf-sidr-adverse-actions-00, "Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)”,  believe that the document is ready for a working group last call.
> 
> This starts a two week wglc which will end on 14 July 2016.
> 
> Please review the draft and send comments and your opinion of whether it is worthy of publication to the list.  Remember that support for publication is needed, and comments can improve quality, so lack of comments is not sufficient.
> 
> You can reach the document at https://tools.ietf.org/html/draft-ietf-sidr-adverse-actions-00 and https://datatracker.ietf.org/doc/draft-ietf-sidr-adverse-actions.
> 
> —Sandy, speaking as one of the wg co-chairs.
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sun, 17 Jul 2016 11:47:39 +0200

Hi,

I have a number of late comments (unfortunately no time to read this in detail earlier)

First of all, I believe that the structure of the document, where analysis is done without going into details of solutions, is useful.

That said I have some substantial comments. I think the order of the analysis of the various objects in section 2 is not logical. This may sound like a trivial thing, but actually I think a re-ordering will help to think about the context and different vectors for each.

Comments on each case:

- CA certificates (section 2.5)

I suggest that section 2 should start with this. CA certificates are issued by parent CAs. So the sections on modification, revocation and injections make more sense to me here - they are all done by the parent of the CA that is affected by these actions.

@A-5.4.1: A shrink may be seen as adverse by the INR holder, but there may be reasons (e.g. transfers, temporary assignments, closure) why an RIR may have to reclaim certain resources. In our case these practices are based on community consensus in our address policy working group. So.. a specific INR holder may not be happy to see resources removed, but in some cases this is a feature, not a bug.

@A-5.4.2: I think this is being addressed by validation-reconsidered

@A-5.4.5: It may be hard to detect this case because of normal key rolls.

- Manifests (section 2.2) and CRLs (section 2.4)

These objects are part of the 'boilerplate' objects that a CA uses. To me they seem related. At least in our RP software we typically find the 'current' MFT and CRL for a validated CA certificate and then we use this to find and validate all other objects issued by this CA. So it would make sense to me to look at these next (as 2.2 and 2.3 after CA certificates)

In any case I don't think that the analysis of modification, revocation and injections are very useful here. For these to work an adverse agent needs to have access to the CA certificate's private key *and* repository. Bets are then just off.

I understand that you don't want to go in solution space here, but.. I believe that with RRDP we can now actually get multiple objects as a single delta. That means that a CA can publish a new MFT and CRL, and all its objects together.

This in turn means that an RP can find a MFT and CRL, check the thisUpdate/nextUpdate time to detect a withhold. And it can find all the objects enumerated on the MFT by hash. So it can detect withhold, replay or modification of other objects.

Ultimately the adverse actions by a repository (deletion, suppression, corruption) cannot be prevented, but they can be *detected*. And I believe this is relevant to the analysis of those adverse actions.

- Ghostbusters

No comment

- ROAs

Similarly to manifests I don't think that the analysis of modification, revocation and injections are very useful here. Bets are off if an adversary has the key and the repo.

I think it would be more useful to analyse what the general problem is w.r.t. outsourcing CA functions - as is done later in the doc. People do it because it's convenient, but obviously this means that you have to *trust* that the organisation you outsource to will do any of those M/R/I type adverse actions.

- Router Certs

Same concerns as ROAs

> On 30 Jun 2016, at 23:11, Sandra Murphy <[email-masked]> wrote:
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Jul 2016 10:00:20 -0400

Tim,

Thanks for taking the time to read and comment on the document.

I will change CA certificate analysis to be section 2.1, and make the 
CRL section b 2.3, as per your request. The Manifest section will remain 
2.2, ROAs will become 2.4, GB will become 2.5, and Router Certificates 
will remain 2.6. This will require a lot of changes to the pointers 
within and between sections, but we aim to please :-).

A-5.4.1: I agree that reducing the set ofresources in a CA certificate 
may be done for legitimate reasons, even if the INR holder does not 
agree with the reduction. Nonetheless, this is an adverse action from 
the perspective of the INR holder. It’s important to note that there are 
cases when this reduction is the result of an attack against or an error 
by the parent CA. Thus I believe it is important to retain this action 
in the list.

A-5.4.2: I’ll delete this action.

A-5.4.5: I agree that this may be hard to distinguish from a legitimate 
key rollover, except that a key rollover would have both old and new CA 
keys present simultaneously. I’ll add a note to this effect.

I disagree with your suggestion that we remove the modification, 
revocation, and injection actions for Manifests, ROAs, and Router 
Certificates. First, remember that adverse actions include errors by 
CAs, and transient attacks against CAs. In the former case the private 
key is clearly available and the CA may also control the repository. In 
the latter case note that an attacker need not need learn the private 
key’s value; he/she needs only the ability to cause an HSM to use the 
key. Also, an attacker need not control the repository to effect these 
actions; an RP might be misdirected to a different set of files via a 
routing system attack (ironic?) or a DNS attack.

Recall that the goal of this document is to document, as best we can, a 
wide range of actions that are adverse, irrespective of whether we can 
prevent or detect such actions. Your message noted that RRDP may make it 
easier for RPs to detect some of these actions; I suggest you add 
references to the relevant sections of this document as further 
motivation for transitioning to RRDP.

Finally, when we revised an earlier version of the document we decided 
to include every action in the same order in each section (except for GB 
records, where it would be trivial), to make it easier for a reader to 
see that we were addressing the same issues for each object.

Steve