Subject: [Sidrops] draft-ymbk-sidrops-ov-signal-02

From: John Scudder <[email-masked]>
Date: Tue, 23 Jul 2019 20:48:01 +0000

Things I would have said at the mic had time allowed:

1. For what it’s worth, RFC 4271 section 9.1 says you aren’t allowed to have this feature:

   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.  Route selection then consists of the
   individual application of the degree of preference function to each
   feasible route, followed by the choice of the one with the highest
   degree of preference.

As I understand section 5 of the draft (as informed by Randy’s description), it is exactly mandating that we use the path attributes of other routes for the computation of the degree of preference.

2. Assuming we overcome that problem, there appears to be a stability and/or freshness issue:

- RR client C advertises route A to RR
- RR checks A, decides it is invalid 
- RR advertises A, marked invalid, back to C. Call this A’. 
- C obeys section 5 and withdraws A from everyone (including RR)
- Following the normal operation of BGP, RR withdraws A' from everyone (including C)
- Now A’ is not in C’s Adj-RIB-In, but A is. I believe what Keyur said on the mic was that C is supposed to have persistently marked A as invalid in the earlier step, patching the obvious stability problem.
- Now suppose the content of the RPKI changes such that A is now valid.
… how does A ever find this out and un-suppress A? As far as I can tell, the answer is, “it doesn’t”. RR never sees a re-announcement of A, so it can’t re-validate and announce it to be valid. So it’s just wedged.

3. Finally, someone commented at the mic that the work to turn validation on at C is less than the work to debug, implement, and deploy this proposal. I agree.

Given the above, I’m not in favor of adoption (though I’m always willing to be convinced).

Thanks,

—John

---

From: Job Snijders <[email-masked]>
Date: Tue, 23 Jul 2019 20:59:41 +0000

I have questions about this draft as well:

Why not tunnel VRPs inside BGP in a new AFI to populate the origin
validation cache on the edges? I think the BGP protocol has sufficient
hooks to model the RTR protocol fairly closely.

Or perhaps I don't understand the appeal of this mechanism. Why not
use RTR? Or if there is no room on the edge router for the memory a
VRP cache? If there is no room, can it even do Internet BGP?

Kind regards,

Job

On Tue, Jul 23, 2019 at 8:48 PM John Scudder
<jgs=[email-masked]> wrote:
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 24 Jul 2019 05:01:11 +0000

If ROV results in an objectionable validity, then the route is never installed.
If a "Sender" is to outsource the ROV procedure to an "Evaluator", then the
Sender MUST NOT install the route until the Evaluator returns an acceptable
validity.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Job Snijders
Sent: Tuesday, July 23, 2019 2:00 PM
To: John Scudder <jgs=[email-masked]>
Cc: [email-masked]
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 24 Jul 2019 11:28:25 -0400

> 2. Assuming we overcome that problem, there appears to be a stability and/or freshness issue:

[Example elided]

FWIW, I'd observe that the given use case in the draft is a route reflector
or other BGP speaker.

Since a BGP speaker normally would only send a route to a given BGP speaker
based on having performed route selection, the sender of the route to be
proxy validated should expect to not receive the route in many cases since
it's not the selected best path.

John's example shows a case where we might end up in some undesirable cases.

The desire in this draft is to leverage existing BGP plumbing.  It's an
awkward fit as currently discussed. Thus I'm with John in not being in favor
of adoption at this time.

-- Jeff

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 24 Jul 2019 19:36:45 +0000

The NIST srx-server (external evaluator) actually does provide such outsourced RPKI origin validation - as well as BGPsec validation. 
For that we developed a protocol (srx-server-protocol - https://bgpsrx.antd.nist.gov/bgpsrx/documents/srx-server-protocol-1-0.txt.pdf) where the router requests RPKI origin validation (and/or BGPsec path validation) from the srx-server, which not only returns the validation state but in return starts monitoring the particular route and possible changes in validation due to changes in the RPKI. This "external validator" can be shared within an organization and allows centralized RPKI origin validation which assures the same validation state within all connected routers. 

Oliver

On 7/24/19, 1:01 AM, "Sidrops on behalf of Jakob Heitz (jheitz)" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,
    Jakob.
    
    -----Original Message-----
    From: Sidrops <[email-masked]> On Behalf Of Job Snijders
    Sent: Tuesday, July 23, 2019 2:00 PM
    To: John Scudder <jgs=[email-masked]>
    Cc: [email-masked]
    Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02

    
    
    Kind regards,
    
    Job
    
    On Tue, Jul 23, 2019 at 8:48 PM John Scudder
    <jgs=[email-masked]> wrote:
    > https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Coliver.borchert%40nist.gov%7C83d37cd06a20460e5cf008d70ff3fd5d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636995412908927880&amp;sdata=2xEHuE%2Fi6cQVF3xtdQ1diYkB%2B%2BJtMzi1RKC8UJjRLj0%3D&amp;reserved=0
    
    _______________________________________________
    Sidrops mailing list
    [email-masked]
    https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Coliver.borchert%40nist.gov%7C83d37cd06a20460e5cf008d70ff3fd5d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636995412908927880&amp;sdata=2xEHuE%2Fi6cQVF3xtdQ1diYkB%2B%2BJtMzi1RKC8UJjRLj0%3D&amp;reserved=0
    _______________________________________________
    Sidrops mailing list
    [email-masked]
    https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Coliver.borchert%40nist.gov%7C83d37cd06a20460e5cf008d70ff3fd5d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636995412908927880&amp;sdata=2xEHuE%2Fi6cQVF3xtdQ1diYkB%2B%2BJtMzi1RKC8UJjRLj0%3D&amp;reserved=0

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Wed, 24 Jul 2019 20:28:38 +0000

Set the validation state of a just received update to "undefined".  

Leave it to the operator's local policy to decide if they wish to "ignore undefined" (i.e., wait for validation before including in decision process), or not.

dougm
--  
Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST

    
    Regards,
    Jakob.
    
    -----Original Message-----
    From: Sidrops <[email-masked]> On Behalf Of Job Snijders
    Sent: Tuesday, July 23, 2019 2:00 PM
    To: John Scudder <jgs=[email-masked]>
    Cc: [email-masked]
    Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02

    
    
    Kind regards,
    
    Job
    
    On Tue, Jul 23, 2019 at 8:48 PM John Scudder
    <jgs=[email-masked]> wrote:
    > https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7C53566a39a6a04ad3159e08d70ff3fd87%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636995412930920263&amp;sdata=6nCA3ZgvvF0SkldQUR1TVCiE1bYLhQwCLhxsT3A9Tzo%3D&amp;reserved=0
    
    _______________________________________________
    Sidrops mailing list
    [email-masked]
    https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7C53566a39a6a04ad3159e08d70ff3fd87%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636995412930920263&amp;sdata=6nCA3ZgvvF0SkldQUR1TVCiE1bYLhQwCLhxsT3A9Tzo%3D&amp;reserved=0
    _______________________________________________
    Sidrops mailing list
    [email-masked]
    https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7C53566a39a6a04ad3159e08d70ff3fd87%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636995412930920263&amp;sdata=6nCA3ZgvvF0SkldQUR1TVCiE1bYLhQwCLhxsT3A9Tzo%3D&amp;reserved=0