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

From: Christopher Morrow <[email-masked]>
Date: Wed, 22 Aug 2018 10:52:02 -0400

Howdy WG folk!
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? :)

thanks!
-chris
co-chair

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 22 Aug 2018 16:30:08 +0100

the issues brought up last feb have not been addressed:

> https://mailarchive.ietf.org/arch/msg/sidrops/YV1WfoxQNiwfOjtKIY1d6YJjRxM

Unfortunately, most of the issues discussed in this email are intrinsic 
to the core ideas of the draft, i.e. unclear whether it's possible to 
fix them :-(

Nick

---

From: Job Snijders <[email-masked]>
Date: Wed, 22 Aug 2018 18:15:49 +0200

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:
> 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

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Aug 2018 19:20:36 -0700

> 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.

while i agree that deployment of origin validation is good and important
work, imiho it is quite orthogonal to this draft.  i.e. red herring
alert.

otoh, i have to agree with nick that there are serious problems
with it, and appreciate his pointing them out.

randy

---

From: Daniel Kopp <[email-masked]>
Date: Fri, 24 Aug 2018 14:33:02 +0000

I would like to give some feedback from the draft side.

The draft was initialised from a meeting of a group of network operators at an IXP around three years ago.
As I remember, they told us that their routers are not capable of performing RPKI validation, 
a mechanism to tag routes from the route server would help them using RPKI. 
From this, a group people from AMS-IX, DE-CIX and France-IX joined to build this draft to find a unified way to do this at IXPs.
I feel like this idea got lost on its way.

By no means the draft is there to weaken or make people to replace stronger security mechanisms. 
It's should be there for those who can't perform RPKI origin validation at an IXP by themselves.

To give an answer to the latest arguments that Job brought up:

1/ & 2/ 
The idea was to use this mechanism in a "trusted” environment at an IXP from a route server. 
We don't want the validation results to propagate beyond the IXP domain. 
From the technical discussions we had to generalize the draft to fit the EBGP world. 
There was a discussion with RFC 8097 to incorporate our needs, but the decision was made to build an separate draft. 

3/ 
Around 20 network operators met at DE-CIX on 12/2015. 
They asked for what we are trying to accomplish here with this draft.

Here are some of the comments from the operators when the idea was born:

   - The AS does not have to be in the BGP community
   - Well-known community should be defined
   - Extended community should be used in combination with a non-transitive flag
   - It is expressed that DE-CIX is getting involved in standardisation

4/ 
Having new transitive communities was implemented from the discussion on the mailing list. 
But it's true, if routes don't support it, it doesn't help anybody in addition to RFC 6810/8210. 
So if this is the case, we should change this again.

5/ 
We describe different modes of operation to provide more opportunities for the implementation at different IXPs (companies).
Most important for the draft was, that we have a common mechanism on the signaling. 
With the modes, the idea was that different IXPs can decide on how strict they wan't the "filtering" to be. 
This might help in the adoption for IXP networks.

6/ 
Yes, we don't have an explanation why we don't use locally significant BGP communities, thats true. 
In technical aspects we already discussed and then included some of the ideas, 
but if other technical implementations are a better fit, we are open to change them. 
So you would propose local communities?

7/ 
The idea of the draft was to signal RPKI at an IXP from the route server, not to be implemented globally on "all" routers. 
We should discuss any tangible consideration and add them or rework the security consideration section.

8/
"AS operators SHOULD provide
out-of-band means for peers to ensure that the ROA validation process
has not been compromised or corrupted."

It's not the aim of the draft to provide cryptographic soundness over BGP. 
The message of that section should be that IXP operators have to ensure that the validation process on their side is not compromised, 
and provide an out-of-band indicator to the peers that the validation process is not corrupted at the IXP side.  

9/ 
Network operators often announce /32 prefixes when they use blackholing for DDoS mitigation... this is just something to consider when using RPKI and blackholing at IXPs. 

10/ 
As said before, we wanted to have different modes of operation at different IXPs. 
Dropping invalids by default at the route server is an option, 
if IXP operators and their networks a ready for it they are more then welcome to do it.

The initial idea for the draft came from network operators at IXPs.
The idea of the draft is to help with the adoption of RPKI in the domain of IXPs.
The idea draft is not a replacement for RPKI validation or a global distribution of RPKI validation results.
The draft is there to help at IXPs till we all drop invalids by default :)

Best regards,
Daniel

> On 22. Aug 2018, at 18:15, Job Snijders <[email-masked]> wrote:
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops