Subject: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)

From: Christopher Morrow <[email-masked]>
Date: Tue, 26 Feb 2019 00:45:01 -0500

Howdy WG folks!
At the Bangkok meeting Oliver asked that we push forward:
 https://tools.ietf.org/html/draft-borchert-sidrops-rpki-state-unverified-01

for WG Adoption, the abstract is:

  "In case operators decide not to evaluate BGP route prefixes according
   to RPKI route origin validation (ROV), none of the available states
   as specified in RFC 6811 do properly represent this decision. This
   document introduces "Unverified" as well-defined validation state
   which allows to properly identify route prefixes as not evaluated
   according to RPKI route origin validation."

and some brief 2wk period of discussion and such should now ensue!

Thanks!
-chris
co-chair.

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Feb 2019 08:17:55 -0800

i do not understand this draft from an operational/security perspective.
it seems to want to document why the announcement was not marked valid
or invalid.  from an opsec perspective, i really do not care.

as there are a number of reasons the match might not have been made:
peer not configured for validation, prefix in execption list, AS in
excption list, ... will we next enumerate them all?  e.g. for debugging,
i might like to know which of my policies caused the prefix not to be
evaluated.  i am NOT suggesting we go down this rabbit hole.

bottom line: i care if it is valid.  i care if it is invalid.  i do not
care why it could not be marked one or t'other.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 27 Feb 2019 16:28:27 +0000

> care why it could not be marked one or t'other.

Maybe the authors could describe use cases?  I can't see any situation 
where this flag might be useful, but hey, other people have different 
requirements on their networks.

nit: it would be better to use the term "unchecked" or "unevaluated" 
instead of "unverified".  Verification implies assignment of a value of 
truthfulness, which is not what this draft is about.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 28 Feb 2019 13:03:37 -0500

On Wed, Feb 27, 2019 at 04:28:27PM +0000, Nick Hilliard wrote:
> Maybe the authors could describe use cases?  I can't see any
> situation where this flag might be useful, but hey, other people
> have different requirements on their networks.

I'm not an author.  I had some opinions on the original extended community
that weren't exactly popular among the purists in SIDR.  A terse form of
those opinions follows:

Like all BGP features, OV will be incrementally deployed.
RPKI can tell you the useful bit of tri-state that is in the current RFC:
valid, invalid, unknown.
Carrying that state from a spot in your network that supports OV to parts
that don't may be useful, depending on your policy.
For some fault states (validator down, e.g.) carrying that state into the
network may similarly be useful.
Similarly, carrying state that OV has arrived at one state but you're taking
different action may be interesting.  This one overlaps things like more
specific routes carried between consenting providers that are not in the
global RPKI as valid.  Other mechanisms can address the issue as well.

End of the day, the tri-state is helpful, but provides the bare minimum of
operational coverage for carrying this stuff into your network.

At some point, OV can be pervasivel deployed such that these are less of an
issue.

-- Jeff