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

["Borchert, Oliver (Fed)" <[e-mail]>]

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)" <[e-mail] on behalf of [e-mail]> wrote:

    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 <[e-mail]> On Behalf Of Job Snijders
    Sent: Tuesday, July 23, 2019 2:00 PM
    To: John Scudder <jgs=[e-mail]>
    Cc: [e-mail]
    Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02
    
    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=[e-mail]> wrote:
    >
    > 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
    > _______________________________________________
    > Sidrops mailing list
    > [e-mail]
    > 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
    [e-mail]
    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
    [e-mail]
    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