Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018

[Job Snijders <[e-mail]>]

On Wed, Aug 22, 2018 at 10:52:02AM -0400, Christopher Morrow wrote:
> The authors of: draft-ietf-sidrops-validating-bgp-speaker are thinking
> their draft is ready to move forward, there hasn't been significant
> conversation about this document since the last meeting in Montreal...
> so:
> 
> Draft Abstract:
>   "This document defines a new BGP transitive extended community, as
>    well as its usage, to signal prefix origin validation results from an
>    RPKI Origin validating BGP speaker to other BGP peers.  Upon
>    reception of prefix origin validation results, peers can use this
>    information in their local routing decision process."
> 
> Can we read/think/discuss this for the next ~2wks and decide if it's
> in shape for movement forward in the sausage factory which is the
> IETF? :)

I have reviewed the document (and also have reviewed draft-ietf-sidrops-route-server-rpki-light,
and before that draft-ietf-sidr-route-server-rpki-light). I see a number
of issues. In summary I'd rather see IETF focus its energy on promotion
of "invalid == reject" at EBGP boundaries at both IXPs and ISPs rather
than spend time on standardising this method.

1/ I think it is counter productive to propagate RPKI Invalid routes
from one BGP domain to another BGP domain (aka across EBGP boundaries)
under the premise "but we clearly labeled the route hijack with a
transitive extended community!". The approach does nothing to dampen the
negative effects of BGP hijacks or misconfigurations.

2/ Within the context of signaling within a single BGP domain there
already is RFC 8097. I can't really see a justification to standardise
the behavior and code-points described in draft-ietf-sidrops-validating-bgp-speaker.
RFC 8097's design property so that the state communities cannot
propagate outside the BGP domain are considered a characteristic of
robustness and were a conscious decision as far as I understand.

3/ The first sentence of the document is opiniated and doesn't seen
anchored in reality: "RPKI-based prefix origin validation [RFC6480] can
be a significant operational burden for BGP peers to implement and
adopt."

Some anecdata: I have experience enabling RPKI origin validation in
quite some ISPs and IXPs, and either the deployment is easy (thus
draft-ietf-sidrops-validating-bgp-speaker is not needed), or the
deployment is a burden by factors unrelated to what is described in
draft-ietf-sidrops-validating-bgp-speaker. I've not encountered any
situation where draft-ietf-sidrops-validating-bgp-speaker would make
RPKI adoption any easier.

4/ Section 2 "EBGP Prefix Origin Validation Extended Community"
describes new transitive extended communities, but not all BGP
implementations support defining & matching arbitrary new extended
communities. If the argument is that using new extended communities can
help deploy origin validation on BGP speakers that don't have support
for RFC 6810/8210; I don't believe that can be the case. By the time
such implementations have been updated to support
draft-ietf-sidrops-validating-bgp-speaker, chances are the platform will
support actual Origin Validation and this kludge won't add value.

5/ As is well known in the operational community, "Simple Tagging" and
"Prioritizing and Tagging" as described in section 3 do nothing for
Internet's routing security posture. Fiddling with LOCAL_PREF is useless
in the context of more-specific announcements. "Simply Tagging" is
useless because the 'validating bgp speaker' is shifting the
responsiblity of rejecting RPKI Invalid routes to the EBGP peer, who may
or may not be able to act on this information.

6/ No explaination is offered why using locally significant BGP
communities is not adequate. When locally significant communities are
used, at least the operator of the 'validating bgp speaker' that is
proapgating RPKI invalid routes knows the receipient took the effort to
read and try to understand the implications of this insecure approach.
The authors have already confirmed that they use locally significant
communities today at their IXPs, and it appears this works fine.

7/ Section 7 'security considerations' is full of holes. The sentence
"Therefore, a validating BGP speaker could be misused to spread
malicious prefix origin validation results." should be rewritten to

    "Therefore, all BGP speakers can be misused to spread adversarial
    origin validation results. Peers have no method to reliably
    establish whether it was a validating BGP speaker that attached the
    EBGP Prefix Origin Validation Extended Community, or an adversery."

8/ Furthermore in section 7, it is stated: "AS operators SHOULD provide
out-of-band means for peers to ensure that the ROA validation process
has not been compromised or corrupted." but the document provides no
guidance on how such an external ROA validation process can be used.
There is no verifyable untainted end-to-end chain of custody. Amongst
other issues related to CoC, BGP communities are not cryptographically
signed or verifiable, so there is no way anyone, ever, can trust the
validation results from a so called 'validating speaker'.

9/ The "While being under DDoS attacks" paragraph is entirely out of
scope for this document.

10/ Since the document promotes propagating RPKI Invalid routes instead
of rejecting those invalid announcements, (section 3 "A validating BGP
speaker MUST support the Simple Tagging operation mode. Other modes of
operation are OPTIONAL.").

I think this approach is a disservice to the global community. Our
organisation (NTT) is creating RPKI ROAs for its IP resources with the
understanding that the RPKI is a method to globally publish what BGP
Origin ASNs NTT authorised and what prefix lengths can be expected. We
did not publish ROAs with the understanding that RPKI Invalid
announcements (hijacks, misconfigurations) will merely be tagged with a
BGP community and propagated.

Kind regards,

Job