Subject: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Apr 2015 20:01:43 +0200

On 28 Jan 2015, at 23:38, Sandra Murphy <[email-masked]> wrote:

> idr folk, your attention and comments would be appreciated as well.

Since you ask...

I'm sending this to both idr and sidr as I think this needs broader input than just sidr. (And it seems I'm no longer on the sidr list.)

I read draft-ietf-sidr-bgpsec-protocol-11 and draft-lepinski-bgpsec-overview-00.txt as well as RFC 6483.

I think what's lacking here is any discussion of what happens when certificates etc expire. Please stay with me for a bit:

RFC 6483 talks about RPKI route validation, which suggests that there are three possible states:

valid
unknown
invalid

where valid is preferred over unknown and unknown over invalid, and:

"It is a matter of local routing policy as to whether routes with an "invalid" validity state are considered to be ineligible for further consideration in a route selection process."

Actually, I think the only reasonable approach is to filter out invalids and prefer valids over unknowns. The important part here is that if there's a ROA for 193.0.0.0/21 and then someone announces a more specific like 193.0.7.0/24, that /24 will be "invalid", so even in partial deployment RPKI users are protected against malicious or accidental more specifics. But if invalids are accepted, even with a very low preference, then they still get to divert traffic.

So far, so good.

But now what if a certificate expires? We know from the web that this is extremely common. If an expired certificate means the prefixes involved are marked invalid, this means that filtering invalids becomes very problematic: not only will prefixes randomly drop off the net as people forget to generate or install certificates or RPKI caches get stale, but if things get really bad the resulting lack of connectivity makes it impossible to correct the problem...

So what we need is for expired certificates to make the affected prefixes revert to unknown rather than invalid. Turns out, that's what happens today:

http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html

However, unless this is specified in one of the related documents other than the three mentioned above, this seems to be an implementation choice.

I think the above issue needs to be discussed in an update of RFC 6483 or in one of the BGPsec documents.

And there's probably a bit more to think about: wouldn't it make sense to be able to filter on the signature algorithm at some point during the transition from one algorithm to the next? Or to be able to filter on "expired" explicitly? A binary valid/invalid isn't enough. Valid/unknown/invalid is workable, but maybe four or five levels is even better.

(And have a look at how this works in practice: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html search for PEX.)

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 28 Apr 2015 18:27:35 +0000

Iljitsu,

It is not an implementation choice, it is by design. If a signed object does not validate (based on whatever reason not just expiration), it is like if did not existed.

I guess your point is covered.

Roque

Sent from my HTC

----- Reply message -----
From: "Iljitsch van Beijnum" <[email-masked]>
To: "Sandra Murphy" <[email-masked]>
Cc: "[email-masked] wg" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11
Date: Tue, Apr 28, 2015 20:02

Since you ask...

valid
unknown
invalid

So far, so good.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Apr 2015 21:21:31 +0200

> It is not an implementation choice, it is by design. If a signed object does not validate (based on whatever reason not just expiration), it is like if did not existed. 

No...

Suppose:

ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430

BGP table 29 april:

193.0.0.0/21   3333 -> valid
193.0.0.0/21   4444 -> invalid
193.0.7.0/24   3333 -> invalid
192.0.0.0/16   5555 -> unknown

But, two days later, after the ROA expires, do we have this:

193.0.0.0/21   3333 -> unknown
193.0.0.0/21   4444 -> unknown
193.0.7.0/24   3333 -> unknown
192.0.0.0/16   5555 -> unknown

or this:

193.0.0.0/21   3333 -> invalid
193.0.0.0/21   4444 -> invalid
193.0.7.0/24   3333 -> invalid
192.0.0.0/16   5555 -> unknown

?

You seem to be saying the second, but that wouldn't work, as a simple mistake would make AS 3333 unreachable. And since you need to connect to the internet in order to get a new certificate/ROA so you can connect to the internet...

The NANOG link I posted says it's the first case, which would be much more workable in practice: in that case, if a certificate expires before a new one is installed, you lose security but not connectivity. As we've successfully run BGP for 25 years without security, that's bad, but preferable to being unreachable.

Note also that the approach suggested in RFC 6483 and Cisco and Juniper documentation, where valid > unknown > invalid is not workable because then can still have traffic flow towards more specific prefixes even though they're invalid and have a very low local preference. The nice thing about RPKI is that you can deploy it TODAY if you filter invalids with the huge upside that you get rid of unauthorized more specifics, incurring only the very small risk that someone creates ROAs that conflict with their advertisements.

But the real issue is that this isn't written down anywhere as far as I can tell, so we're dependent on implementers all independently coming up with the preferred way to handle this. That's never good business for a standards organization.

---

From: David Mandelberg <[email-masked]>
Date: Tue, 28 Apr 2015 18:21:12 -0400

On 2015-04-28 15:21, Iljitsch van Beijnum wrote:
>> It is not an implementation choice, it is by design. If a signed 
>> object does not validate (based on whatever reason not just 
>> expiration), it is like if did not existed.
>
> No...
>
> Suppose:
>

In your example, is this the only ROA with a prefix that covers 
193.0.0.0/21 or is covered by 193.0.0.0/21? Based on the states below, 
I'm assuming it is. Please correct me if I'm wrong.

> 192.0.0.0/16   5555 -> unknown

This part looks right to me.

> 192.0.0.0/16   5555 -> unknown
[snip]
> But the real issue is that this isn't written down anywhere as far as
> I can tell, so we're dependent on implementers all independently
> coming up with the preferred way to handle this. That's never good
> business for a standards organization.

It's the first one (all unknowns). I don't think this is written down 
explicitly, but if implementations follow RFC6483, I don't think there's 
any way they can get the second result.

 From RFC6483, Section 2:

    It is assumed here that a relying party (RP) has access to a local
    cache of the complete set of valid ROAs when performing validation 
of
    a route.  (Valid ROAs are defined as ROAs that are determined to be
    syntactically correct and are signed using a signature that can be
    verified using the RPKI, as described in [RFC6482].)  The RP needs 
to
    match a route to one or more valid candidate ROAs in order to
    determine a validation outcome, which, in turn, can be used to
    determine the appropriate local actions to perform on the route.

This means that only valid (non-expired) ROAs are used for origin 
validation. Like Roque said, "if a signed object does not validate 
(based on whatever reason not just expiration), it is like if did not 
existed."

Then, in the next paragraph:

    However, routes
    for address prefixes that are not fully described by any single ROA
    (i.e., those routes whose address prefixes may be an aggregate of
    address prefixes described in a valid ROA, or have address prefixes
    where there is no intersection with any valid ROA), and are not
    matched by any valid ROA and do not have an address prefix that is a
    more specific address prefix described in any valid ROA, cannot be
    reliably classified as "invalid" in a partial deployment scenario.
    Such routes have a validation outcome of "unknown".

Since the {AS 3333, 193.0.0.0/21-21} ROA expired, there's no *valid* 
ROA that intersects any of {193.0.0.0/21, 193.0.0.0/21, 193.0.7.0/24, 
192.0.0.0/16}. (See my assumption above about no other ROAs for these 
prefixes.) Since none of these four prefixes intersect any prefix in any 
valid ROA, all four routes you gave are unknown.

Based on the two snippets above, I do think it's clear enough for 
implementations to get it right. However, you asked a good question that 
other people will probably ask again. Do you think it would be helpful 
to make this case more explicit somewhere?

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Apr 2015 00:48:43 +0200

On 29 Apr 2015, at 0:21, David Mandelberg <[email-masked]> wrote:

> Based on the two snippets above, I do think it's clear enough for implementations to get it right.

Yes, looks like it's indeed in there if you read closely.

> However, you asked a good question that other people will probably ask again.
> Do you think it would be helpful to make this case more explicit somewhere?

I think making this more explicit in an update of RFC 6483 would be helpful.

But unless I missed something, the BGPsec drafts don't even talk about the unknown state:

"The validation procedure results in one of two states: 'Valid' and 'Not Valid'."

I don't see any reasonable deployment scenario with only valid and invalid. I think this needs to be addressed in a BGPsec document.

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 28 Apr 2015 18:53:12 -0400

speaking as regular ol' member:

On Apr 28, 2015, at 3:21 PM, Iljitsch van Beijnum <[email-masked]> wrote:

> You seem to be saying the second, but that wouldn't work, as a simple mistake would make AS 3333 unreachable. And since you need to connect to the internet in order to get a new certificate/ROA so you can connect to the internet…

I think Roque was saying that the first outcome would be the case, not the second:

>> If a signed object does not validate (based on whatever reason not just expiration), it is like if did not existed.

If the ROA's EE certificate expires, then the ROA does not validate, it is like if the ROA did not exist.

Which makes the first outcome, not the second.

I'm not sure where you see text that implies that the second outcome would happen.

We have left the idea of how fast expiration takes effect up to implementation.  If the implementation immediately trashes an expired EE cert, then you lose the ROA, and the 3333 route would be "unknown".  If the implementation keeps the EE cert around (until next clock chime?  next sync interval?  until it sees a reissue or a CRL?), then you keep the ROA, and the 3333 route would be "valid".  In neither case does the 3333 route become "invalid".

To get a result of "invalid" for 3333 for the /21 requires that you found a ROA that authorizes some other AS for the /21 and no ROA that authorizes 3333 for the /21.

> 
> The NANOG link I posted says it's the first case, which would be much more workable in practice: in that case, if a certificate expires before a new one is installed, you lose security but not connectivity. 

Since that's what I think happens and what you think should happen, we're good!

> Note also that the approach suggested in RFC 6483 and Cisco and Juniper documentation, where valid > unknown > invalid is not workable because then can still have traffic flow towards more specific…

Some people think depref-ing invalids is a safer alternative than outright dropping them.  There's evidence that people are creating ROAs for their own announcement but forgetting the more specific prefixes they've sub allocated to customers, where the customer are announcing from their own AS but not doing ROAs.  The ROA for the aggregate makes the customer's announcement look invalid.  Or maybe that's what you mean by "get rid of unauthorized more specifics" and you think that's a good outcome.

> As we've successfully run BGP for 25 years without security, that's bad, but preferable to being unreachable.

I'm not sure you'd be unreachable.  In this day and age, if there's an aggregate prefix that includes yours, then you got your prefix from the holder of the aggregate.  And in (most?) cases, you have connectivity to the holder of the aggregate.  So you are reachable through them.  (Since IAmNotAnOperator (IANAO), any remark I make about operations should be checked with someone who is.)  Not reachable through your backup provider, but that's maybe not so bad.  

If you took their/your more specific prefix and walked and no longer have connectivity thru the aggregate holder, well, … just deserts?  Speculation on my part.

> But the real issue is that this isn't written down anywhere as far as I can tell, so we're dependent on implementers all independently coming up with the preferred way to handle this. That's never…

I don't agree that it is not written down anywhere.  I think the certificate checking and the BGP route checking are both clear in the cases you lay out.

--Sandy, speaking as regular ol' member

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 28 Apr 2015 23:03:52 +0000

>I think Roque was saying that the first outcome would be the case, not

You are correct and IMHO we do not need more documents.

The normative text is in RFC 6482 section 4:

-----------------------
4.  ROA Validation

   Before a relying party can use a ROA to validate a routing
   announcement, the relying party MUST first validate the ROA.  To
   validate a ROA, the relying party MUST perform all the validation
   checks specified in [RFC6488] as well as the following additional
   ROA-specific validation step.

   o  The IP address delegation extension [RFC3779] is present in the
      end-entity (EE) certificate (contained within the ROA), and each
      IP address prefix(es) in the ROA is contained within the set of IP
      addresses specified by the EE certificate's IP address delegation
      extension.

‹‹‹‹‹‹‹‹‹‹‹

Informational text is in RFC6907, section 7.2:

7.2.  ROA Expiry or Receipt of a CRL Revoking a ROA

Particularly, section 7.2.5 to 7.2.8 covers different expiration
circumstances.

‹‹‹‹‹‹‹‹‹‹‹

Regards,

Roque

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 Apr 2015 12:07:02 +0900

ca software should warn the user of upcoming expiration of certs, ee
certs, roas, crls, drivers' licenses, ...

but what is the user gonna do?  they're gonna renew.  so maybe renew
automagically and tell the user?

randy

---

From: Geoff Huston <[email-masked]>
Date: Wed, 29 Apr 2015 06:57:57 +0200

Hi Iljitsch,

> But now what if a certificate expires? We know from the web that this is extremely common. If an expired certificate means the prefixes involved are marked invalid, this means that filtering invalids becomes very problematic: not only will prefixes randomly drop off the net as people forget to generate or install certificates or RPKI caches get stale, but if things get really bad the resulting lack of connectivity makes it impossible to correct the problem…
> 

yup, becuase an expired certificate is not used for validation of ROAs, so a route object that is only referred to by a ROA that cannot be validated is “unknown” in this taxonomy. It is not “invalid" by virtue of an expired certificate.

> However, unless this is specified in one of the related documents other than the three mentioned above, this seems to be an implementation choice.

to quote RFC6483: 

  "It is assumed here that a relying party (RP) has access to a local
   cache of the complete set of valid ROAs when performing validation of
   a route.  (Valid ROAs are defined as ROAs that are determined to be
   syntactically correct and are signed using a signature that can be
   verified using the RPKI, as described in [RFC6482].)

i.e. the route validation process that produces this set of valid, invalid and unknown outcomes is based on the set of valid ROAs. ROAs that cannot be validated (i.e. due to expired certificates and other causes) are not considered in the route validation process described in RFC6483.

> I think the above issue needs to be discussed in an update of RFC 6483 or in one of the BGPsec documents.

It’s not clear to me that any further text needs to be added to RFC6483. The underlying process is one based on examination of the route feed and comparing each received route object to a collection of attestations and authorities that have been validated by the relying party as trustable.

> (And have a look at how this works in practice: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html search for PEX.)

regards,

   Geoff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 29 Apr 2015 18:46:18 +0000

Hi Iljitsch,

>I don't see any reasonable deployment scenario with only valid and invalid. I think this needs to be addressed in a BGPsec document.

The validation in the BGPsec draft is only about the AS path signatures in signed updates.
It is talking about the validity of the Secure_Path.   
If all the signatures in a Signature_Block are valid, then the Signature_Block (and hence Secure_Path) is 'Valid';
Else, the Signature_Block is 'Not Valid'.
If there are two Signature_Blocks (e.g. when two different algorithms are in use) in an update, 
then at least one of them must be 'Valid' in order for the Secure_Path to be valid.

Separately, prefix-origin validation has three possible outcomes as you have observed already.
That is the topic of RFC 6483 (Informational) and RFC 6811 (Standards Track).

Sriram

---

From: Randy Bush <[email-masked]>
Date: Thu, 30 Apr 2015 04:13:37 +0900

this is deja vu all over again

path validation has three possible results
  o a signed path validated
  o a signed path could not be validated
  o the path was unsigned

randy

---

From: Jared Mauch <[email-masked]>
Date: Wed, 29 Apr 2015 15:46:46 -0400

> On Apr 29, 2015, at 3:13 PM, Randy Bush <[email-masked]> wrote:
> 

I will add one more thing, the path was was signed/validated when it was checked.  Some prefixes are stable for very long periods of time and therefore the validation may not occur until after the expiration.

I generally dislike systems that self-destruct.

- Jared

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Apr 2015 22:35:37 +0200

> Else, the Signature_Block is 'Not Valid'.

So how does this work when a certificate expires without a new one in place?

Then the signature over a hop in the path and therefore the path and therefore one or more prefixes are now "Not Valid". This presents us with two choices:

1. we accept those prefixes in our forwarding tables
2. we don't accept those prefixes in our forwarding tables

Obviously 1. can't be the answer, because then BGPsec is pretty much a NOP.

But 2. is not so great either, because now a mistake or delay in generating and propagating certificates can cause unreachability.

So what we need is a third option, that provides better security than 1. and better reachability than 2.

In other words, "couldn't validate because of certificate lifetime" and "validation failed because of a bad signature or bad certificate chain" are different enough that we need them to have different effects on the forwarding tables.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 29 Apr 2015 21:47:08 +0000

>In other words, "couldn't validate because of certificate lifetime" 
>and "validation failed because of a bad signature or bad certificate chain" 
>are different enough that we need them to have different effects on the forwarding tables.

My thoughts on this:

First:
There should be operational BCP recommendation based on the principle of make-before-break
( in doc like https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05 ):
1. Certificate should be renewed and pre-published in advance of expiry of the current certificate; 
There should be overlapping validity period bridging the two (current and new certs).
(See https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03  and
https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf  ) 
2. The update for the prefix should be re-originated (by origin AS) or re-propagated (by a transit AS).
Basically, whoever got a new certificate should do this refresh within the above overlap period. 

The above two BCP steps, if followed, will help prevent "couldn't validate because of certificate lifetime".

Second:
The operational BCP can also say:
Allow a certain grace period before you act on the update that became 'Not Valid' due to cert expiry.
(Earlier Sandy also mentioned this.)  

Your other scenario "validation failed because of a bad signature or bad certificate chain" is fine. 
In this scenario, the update is labeled 'Not Valid' for good reason.

Sriram

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Apr 2015 00:24:50 +0200

> The above two BCP steps, if followed, will help prevent "couldn't validate because of certificate lifetime".

Of course, most of the time this would happen correctly. People aren't stupid. But experience with HTTPS has shown that expired certificates can't be prevented 100%, and with routing the results are much more severe than with the web, as the user can't decide to go ahead anyway. The user wouldn't even know what happened. And fixing the problem may not be possible because of the unreachability caused by the problem.

> (Earlier Sandy also mentioned this.)  

Ok. So what do you propose?

That a path with signatures based on expired certificates remains "valid" for some additional grace period? Then you simply postpone the problem by that period.

Or should operators have a way to differentiate between paths that are actually invalid and paths that are merely affected by expired certificates? In that case we are saying the same thing.

It might even be useful to have valid / expired-but-otherwise-valid / unknown / invalid rather than valid / unknown / invalid. Or maybe valid-algo1 / valid-algo2 / expired-but-otherwise-valid / unknown / invalid, so I can prefer paths protected with the strongest hashing algorithm over paths protected with a weaker algorithm and those over paths protected with expired certificates and those over paths not protected by BGPsec. (IMO invalid paths should not be allowed at all.)

Iljitsch

---

From: Randy Bush <[email-masked]>
Date: Thu, 30 Apr 2015 08:18:38 +0900

> In this scenario, the update is labeled 'Not Valid' for good reason.

From: Randy Bush <[email-masked]>
Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11
To: Roque Gagliano <[email-masked]>
Cc: idr wg <[email-masked]>, sidr wg <[email-masked]>
Date: Wed, 29 Apr 2015 12:07:02 +0900

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 30 Apr 2015 11:43:01 +0200

Hi,

> On 30 Apr 2015, at 01:18, Randy Bush <[email-masked]> wrote:
> 
>> First:

For the record in the RIPE NCC software we automagically re-issue CA certificates to members 6 months before they expire (and log errors in case of problems, so we have time to respond). Our system currently only supports non-hosted setups where a member runs their own remote CA in our pilot environment, but there too we pro-actively re-issue.. we don't tell the CA because in the provisioning protocol model the child CA can contact us, but we can't contact them. We do tell them about the new certificate when the CA queries, as they do regularly. We believe that this is safe to do. The new certificate is equivalent in every way to the last requested and issued certificate except that the validity time is longer, so we don't see any scenario where the child would not agree to this - i.e. we can be pro-active.

For hosted member CAs we also re-issue ROAs 6 months before the expire, and we re-issue MFTs 16 hours before their 'next update time' and 6 days and 16 hours before their EE certificate expiration.

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

---

From: Matthew Lepinski <[email-masked]>
Date: Thu, 30 Apr 2015 13:48:18 -0400

Iljitsch,

Thank you for the feedback. With regards to bgpsec-protocol and/or
bgpsec-overview, I am not sure what text would be helpful.

For path validation (as opposed to origin validation), the path validation
algorithm returns one of two states. That is, either an update has a valid
signed path or it doesn't. (We discussed previously in SIDR whether there
was a useful third case for path validation, and the working group wasn't
able to come up with one.)

This means that there are six possible states that come from SIDR
validation (assuming you are using both origin validation and path
validation). That is, three possible origin validation states and two
possible path validation states yields six possible joint states. Of
course, one's local policy is free to collapse that state-space if they
wish to treat of some of those states as identical. (Perhaps if origin is
invalid, then it doesn't matter whether path is valid or not ... maybe it
is foolish to care about whether there are signatures on a path if the path
is headed to a bad destination. I don't know ... but it is a matter of
local policy, and it is perfectly fine for different operators to handle
such cases differently.)

In any case, with regards to path validation, I think that in general  one
wants to prefer routes with valid, signed paths over routes that lack
valid, signed paths. However, personally, for path validation, I would not
recommend throwing out all route advertisements where path validation
returns invalid. That is, if the only route you know of to get to a
particular block of address space has a signature that doesn't valid (or
lack signatures because someone in the middle doesn't have BGPsec turned
on), I think it is probably a good idea to use that route despite the lack
of valid signature chain. (But again, this is a matter of local policy, and
I don't want to mandate policy decisions for network operators in the base
protocol specification.)

- Matt Lepinski

On Tue, Apr 28, 2015 at 2:01 PM, Iljitsch van Beijnum <[email-masked]>
wrote:

> I'm sending this to both idr and sidr as I think this needs broader input
> than just sidr. (And it seems I'm no longer on the sidr list.)
>
> I read draft-ietf-sidr-bgpsec-protocol-11 and
> draft-lepinski-bgpsec-overview-00.txt as well as RFC 6483.
>
> I think what's lacking here is any discussion of what happens when
> certificates etc expire. Please stay with me for a bit:
>
> "It is a matter of local routing policy as to whether routes with an
> "invalid" validity state are considered to be ineligible for further
> consideration in a route selection process."
>
> Actually, I think the only reasonable approach is to filter out invalids
> and prefer valids over unknowns. The important part here is that if there's
> a ROA for 193.0.0.0/21 and then someone announces a more specific like
> 193.0.7.0/24, that /24 will be "invalid", so even in partial deployment
> RPKI users are protected against malicious or accidental more specifics.
> But if invalids are accepted, even with a very low preference, then they
> still get to divert traffic.
>
> So far, so good.
>
> But now what if a certificate expires? We know from the web that this is
> extremely common. If an expired certificate means the prefixes involved are
> marked invalid, this means that filtering invalids becomes very
> problematic: not only will prefixes randomly drop off the net as people
> forget to generate or install certificates or RPKI caches get stale, but if
> things get really bad the resulting lack of connectivity makes it
> impossible to correct the problem...
>
> So what we need is for expired certificates to make the affected prefixes
> revert to unknown rather than invalid. Turns out, that's what happens today:
>
> However, unless this is specified in one of the related documents other
> than the three mentioned above, this seems to be an implementation choice.
>
> And there's probably a bit more to think about: wouldn't it make sense to
> be able to filter on the signature algorithm at some point during the
> transition from one algorithm to the next? Or to be able to filter on
> "expired" explicitly? A binary valid/invalid isn't enough.
> Valid/unknown/invalid is workable, but maybe four or five levels is even
> better.
>
> (And have a look at how this works in practice:
> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html
> search for PEX.)
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Apr 2015 22:39:31 +0200

On 30 Apr 2015, at 19:48, Matthew Lepinski <[email-masked]> wrote:

> For path validation (as opposed to origin validation), the path validation algorithm returns one of two states. That is, either an update has a valid signed path or it doesn't. (We discussed previously in SIDR whether there was a useful third case for path validation, and the working group wasn't able to come up with one.)

I think expired certificates qualifies. And a case can be made for strong crypto algo vs weak crypto algo is a fourth one.

> This means that there are six possible states that come from SIDR validation (assuming you are using both origin validation and path validation). That is, three possible origin validation states and two possible path validation states yields six possible joint states.

Actually nine, assuming < 100% BGPsec deployment:

1. BGPsec=valid, RPKI=valid
2. BGPsec=valid, RPKI=unknown
3. BGPsec=valid, RPKI=invalid
4. no BGPsec, RPKI=valid
5. no BGPsec, RPKI=unknown
6. no BGPsecd, RPKI=invalid
7. BGPsec=notvalid, RPKI=valid
8. BGPsec=notvalid, RPKI=unknown
9. BGPsec=notvalid, RPKI=invalid

Only with type 1 can we be sure that the prefix is advertised legitimately.

Type 5 indicates no BGPsec or RPKI deployment and may or may not be legitimate. These should have a lower local_pref than type 1. Type 2 is strange, but can probably be treated the same as type 5, or perhaps a loc_pref higher than 5 but lower than 1.

Types 3, 6 and 9 are bad news, as they may be unauthorized more specifics, so it's important to filter these.

Type 4 can happen because BGPsec hasn't been fully deployed yet (remember that the whole path must support it while RPKI can be deployed by just the "end" AS) but once that's no longer common it will be the attack vector of choice because it's easy to fake the origin AS if there's no BGPsec, so at some point, these need to be filtered, too.

That leaves 7 and 8, which SHOULD be filtered if they're legitimate BGPsec validation failures and not incidental mistakes such as expired certificates.

> it is perfectly fine for different operators to handle such cases differently.)

Famous last words. Obviously we don't want to be overly prescriptive, but I don't think there's as much room for creativity as you suggest.

> However, personally, for path validation, I would not recommend throwing out all route advertisements where path validation returns invalid. That is, if the only route you know of to get to a particular block of address space has a signature that doesn't valid (or lack signatures because someone in the middle doesn't have BGPsec turned on), I think it is probably a good idea to use that route despite the lack of valid signature chain.

Actually I don't think that case can happen. Consider the following path:

6 5 4 3 2 1

If AS 4 doesn't support BGPsec but the others do, then AS 3 will convert the BGPsec_Path to an AS_PATH, removing all the signatures. ASes 5 and 6 are not in the position to repair this, so as far as they're concerned, the path is completely unprotected.

However, what you say here is problematic:

> That is, if the only route you know of to get to a particular block of address space has a signature that doesn't valid (or lack signatures because someone in the middle doesn't have BGPsec turned on), I think it is probably a good idea to use that route despite the lack of valid signature chain.

Considering whether a route is "the only route you know" is explicitly forbidden by RFC 4271:

  "The function that calculates the degree of preference for a given
   route SHALL NOT use any of the following as its inputs: the existence
   of other routes, the non-existence of other routes, or the path
   attributes of other routes."

However, you can get the same result by simply giving the invalid path a low local preference.

However 2, the real problem with allowing prefixes that don't RPKI/BGPsec validate is that these invalid prefixes could be more specifics of legitimate prefixes, and no matter how high the local_pref of the valid prefixes and low the local_pref of the invalid more specifics, the packets will be forwarded as per the invalid more specifics.

Therefore, the only workable approach is to completely filter out prefixes that don't validate.

However, the downside of such a strict policy is that if the certificates used for BGPsec signatures expire, the path will become notvalid and the associated prefixes disappear from the internet. That's why we need the ability to treat paths that don't validate because of expired certificates differently from paths that don't validate for other reasons.