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

From: Russ Housley <[email-masked]>
Date: Wed, 27 Feb 2019 14:27:46 -0500

This seems to be a proposal for documenting why the marking is something other that valid or invalid.  I can see why a researcher might care about those differences, but I cannot see how an operator would make use of it.  I do not think we should add complexity.

Russ

> 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 <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: Jeffrey Haas <[email-masked]>
Date: Wed, 27 Feb 2019 16:51:42 -0500

> This seems to be a proposal for documenting why the marking is something other that valid or invalid.  I can see why a researcher might care about those differences, but I cannot see how an operato…

I likely should write more text, but very simply some operators want easy
ways to mark that a system that should be expected to do validation has not
done so.  The existing tri-state (valid, invalid, not-found) doesn't cover
this.

-- Jeff

---

From: Russ Housley <[email-masked]>
Date: Wed, 27 Feb 2019 17:09:14 -0500

> done so.  The existing tri-state (valid, invalid, not-found) doesn't cover

Please write a little bit more.  What action would be taken in the unverified state that is different from the action taken in the not-found state?

Russ

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Wed, 27 Feb 2019 22:18:24 +0000

Examine the iBGP peer that you thought you configured to do origin validation and determine why it is unable to.

We envisioned this being useful in scenarios such as: you have enabled BGP Origin Validation on a router that has lost all connections to its validating caches.  At the moment we can't tell administratively disabled from enabled, but failed in some manner.   We see some value in being able to diagnose that.

Keep in mind, most of the FUD in this space comes from the fear that operators will not be able to diagnose why routes are/are not being filtered.  This theme came up a lot in the meeting before NANOG.

Not the subject of this draft, but the concept of being able to tell if your iBGP peer actually performed validation will be even more useful in BGPSec, but that is for another draft.

dougm
-- 
DougM at NIST

On 2/27/19, 5:09 PM, "Sidrops on behalf of Russ Housley" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Russ
    
    _______________________________________________
    Sidrops mailing list
    [email-masked]
    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7C35a3d14483b74f42ff7e08d69d0043b5%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636869021800990545&amp;sdata=Z4CMhzA%2BReO21gFYhXZqMQwL4nxdjzTR9VpYcAcmrPg%3D&amp;reserved=0

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 27 Feb 2019 17:28:26 -0500

> Please write a little bit more.  What action would be taken in the unverified state that is different from the action taken in the not-found state?

Among other things, not draconically drop things if that's your policy.

not-found says the prefix isn't in the db.
unverified means that the db might be outright down.

How you feel about such things will wildly vary depending on your network
and how much you wear a security hat for your day job.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Feb 2019 15:48:26 -0800

> Examine the iBGP peer that you thought you configured to do origin
> validation and determine why it is unable to.

the path of debugging hooks runs far deeper into the mud.  to repeat;
you are stepping off a cliff here.

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

> We envisioned this being useful in scenarios such as: you have enabled
> BGP Origin Validation on a router that has lost all connections to its
> validating caches.

% show bgp rpki servers

> At the moment we can't tell administratively disabled from enabled,
> but failed in some manner.  We see some value in being able to
> diagnose that.

that is why we have cli-based (and yang etc) debugging tools.  you want
to know where in all your complex policy some decision was made, you
need to go through the policy, don't try to encode the cross-product of
all the posibilities in a result.

> Keep in mind, most of the FUD in this space comes from the fear that
> operators will not be able to diagnose why routes are/are not being
> filtered.  This theme came up a lot in the meeting before NANOG.

the game is over.  at&t has deployed and the multitude are hurrying to
join him.  and the flag-wavers are rushing to get in front and curry
publicity.

> Not the subject of this draft, but the concept of being able to tell
> if your iBGP peer actually performed validation will be even more
> useful in BGPSec, but that is for another draft.

and another century

randy

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Thu, 28 Feb 2019 00:09:18 +0000

Which of your N hundred routers will you login to, to do the "show bgp rpki servers"?

We thought the one sending you "unverified" state would be a good clue.

No one was asking for the cross product of any other info ... so I don't really buy the slippery slope logic.

I hope you are right about everyone rushing to join the parade.  

I still see as many folks express concerns about debugging as wave flags.

dougm
-- 
DougM at NIST

    

    
    % show bgp rpki servers

    

    
    and another century
    
    randy

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 28 Feb 2019 01:42:58 +0100

The main problem of this discussion is the past: Sidr(ops) has history 
on discussing this topic (sorry that I'm too lazy to give reference to 
the mailing list pointers).

Personally, I have the impression that we run in circles. I don't see a 
clear and crisp reflection on what has been discussed that gives 
striking conclusion on continuing this topic.

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Feb 2019 19:51:01 -0800

> We thought the one sending you "unverified" state would be a good clue.

except routers do not send each other the ROV markings.  and the n
hundred routers probably differ in policy, caches, ...

[ i objected to rfc 8097 in the wg and in ietf lc ]

randy

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Thu, 28 Feb 2019 16:15:04 +0000

Are you saying no one uses the RFC8097 extended community in iBGP?

Certainly it is noteworthy when an author objects to his own spec in LC ... although it can be a confusing signal.

dougm
-- 
DougM at NIST

    

    randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Feb 2019 08:55:42 -0800

> Are you saying no one uses the RFC8097 extended community in iBGP?

not to my knowledge.  see rfc 8481

i am proposing to use that extended community, or something analogous in
draft-ymbk-sidrops-ov-signal-02.txt.  but finer granularity of NotFound
is not desired there either.

> Certainly it is noteworthy when an author objects to his own spec in
> LC ... although it can be a confusing signal.

i have done it twice.  friends begged me to sign it; so i did.  did not
mean i liked it.

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 28 Feb 2019 12:55:31 -0500

> not to my knowledge.  see rfc 8481

As I commented during the cloudflare RPKI event before NANOG: I tend to
notice something is getting attention and use because bugs are filed.

So, I have at least some contrary data points to your knowledge.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Fri, 1 Mar 2019 03:08:46 +0900

On Fri, Mar 1, 2019 at 1:55 Randy Bush <[email-masked]> wrote:

> not to my knowledge.

I don’t use 8097 in traditional IBGP context, but I use 8097 quite a bit.
For instance to carry information to a looking glass web frontend, or to a
traffic analyzer (like pmacct), or to mark routes to aid debugging [1]

Could’ve used locally defined communities, but by using something defined
by IETF I have one less thing to document.

Just my two cents.

Kind regards,

Job

[1] For instance, BIRD allows the operator to (sort of) modify Adj-RIB-In
and add/remove communities on routes which didn’t make it to the Loc-RIB.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 28 Feb 2019 21:19:46 +0000

All of them:

> % salt -G roles:rpkirouters net.cli 'show bgp rpki server summary' | grep -B 1 NONE
Nick