Re: [Sidrops] Closed -- [WGLC] draft-sidrops-bgpsec-validation-signaling-05

[Keyur Patel <[e-mail]>]

Dear Job,

Thanks for the comments and the detail review of the draft. Couple points to note:

- The working group charter does not require us to have multiple implementations as of now. I do see your email suggesting to improve/modify charter on this topic.

- The chairs closed the WGLC for the draft on December 7th 2020. This WGLC was supposed to be closed on October 7th. The authors of the draft believes your comments were addressed. Your email suggests otherwise.  The chairs had a quick chat and we believe we can re-open the last call with hopes that you and other working group members can have their comments/concerns addressed.

Best Regards,
Keyur

On 12/7/20, 12:54 PM, "Job Snijders" <[e-mail]> wrote:

    Dear Keyur,

    On Mon, Dec 07, 2020 at 06:58:16PM +0000, Keyur Patel wrote:
    > This working group last call is closed. Authors have already
    > incorporated relevant feedback received during the last call and at
    > this point the draft is ready to progress further. Accordingly we will
    > prepare a report and forward it to IESG.

    I really think this is a draft where it will proof to be useful to ask
    for an implementation report from *at least two* implementations,
    demonstrating interopability between the two implementations.
    In this (lengthy, sorry!) email https://mailarchive.ietf.org/arch/msg/sidrops/5-sFl3RCzn7xQ0YFOD31C56Ko4o/
    I tried to outline various problems I perceive with the draft in its
    current form, Oliver replied to all text, but zero changes were made to
    the document as he disagreed on all points of substance.

    Oliver claims to have an open source implementation, (which I am happy
    to believe!), and perhaps there is another implementation written by
    someone else? Has it been tested how they interact with each other in
    various configurations?

    If there is a second implementation, the working group can confirm
    whether the proposed Internet-Draft text, Oliver's implementation, and
    the second different implementation are aligned with each other and
    behave in exactly the way outlined in the document. An implementation
    report can be as simple as listing all IETF normative terms contained
    in draft, the line number, and a short comment whether the
    implementation is compliant (MUST), or an implementation specific choice
    was made (MAY), or anything else of note.

    Specifically in this draft, I really see potential for a repeat of the
    'IOS XE / origin validated extended communities'-problem that many
    operators suffered from when they tried to deploy RPKI Origin Validation
    in the BGP default-free zone, and I do not wish a similar repeat of
    events upon the BGPSec technology stack!

    Here is one of many references to the 'standardized' extended rpki
    origin validation communities causing issues in networks build using
    multiple BGP implementations, here is one mail thread. This was/is a
    multi-year problem because of the slow upgrade cycle of field-deployed
    routers: https://www.mail-archive.com/[e-mail]/msg67710.html

    I think there is some kind of technology stack layering problem when the
    state of a route can be manipulated through multiple channels. In this
    case (1) signaled via BGP community and (2) via signalled via
    RPKI-To-Router protocol, it can lead to problems for resource holders
    who are trying to use BGPSec, because there can be situations where
    their wishes are not expressed in the state of the network because of
    interference of an unauthenticated BGP communitiy. 

    So far I think some of us (perhaps myself included) have been too
    focussed mostly on the security aspect (and of course everyone knowns 
    extended BGP communities are not authenticated), but perhaps the
    *security* aspect of it is not the real problem, the real problem might
    be how an accidental misimplementation of draft-sidrops-bgpsec-validation-signaling-05
    can lead to operators having to turn the feature off in the entire fleet
    of devices, or roll back the software (be forced to keep running some
    unwanted version).

    If you ask anyone in the field about RFC 8097, virtually no operator
    will tell you that RFC 8097 in any way helped them deploy RPKI Origin
    Validation at scale (where scale is 100s of routers, multi-country
    network, multiple vendors). What you *will* hear is that there were
    interopability issues caused by the very existence of the RFC that
    caused many people extra work. It also means that everybody now has to
    test each and every new BGP software version they receive from their
    vendor on what exactly the behavior is of the proposed bgpsec origin
    validation signaling draft communities.

    If this draft is published as RFC, IANA will assign 3 codepoints to be
    used in some fashion in a generally unauthenticated protocol (BGP), and
    from that moment all operators doing QA will need to blackbox test the
    behavior of every BGP implementation they consider, to see if the
    implementation does not accidentally cause deviation from 'local policy'
    in any way under any circumstances.

    Standardizing codepoints to signal cryptographic validation states
    through unauthenticated channels really causes Internet operators down
    the road deployment problems, for multiple reasons.

    Kind regards,

    Job

    ps. I once was young and wet behind the ears and endlessly argued how
    great RFC 7999 was a *great* idea. At the time it really did seem great
    because DDoS attacks were a big problem, also lots of network operators
    with a 32-bit had difficulty picking suitable inter-domain BGP values.

    But in retrospect what I should have advocated for is a 'BLACKHOLE'
    PKIX-RPKI profile, now realizing that the RPKI via RRDP/RSYNC/RRDPv2
    might make for global near real-time public 'routing intention'
    distribution, really rivaling with the speed at which BGP updates
    propagate through the Default-Free zone.