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

From: Daniel Kopp <[email-masked]>
Date: Fri, 31 Aug 2018 12:01:40 +0000

Hello again,

I want to follow up and hopefully revive the discussion by reviewing the motivation for the draft.

The idea is to signal the RPKI status from the route server, originally we wanted to have this limited to the domain of an IXP.
From our point of view we see this as a soft start to use RPKI at IXPs and 
the trigger to work on this came from the IXP member side.

Core discussion points on the mailing list are:

1. Route servers should filter out ROA invalid prefixes. That’s what we want as well. 
The draft is just an addition to signal the results and we also have different modes of operation. 
However, I think every IXP should be allowed to decide by themselves how strict they setup their route server filtering. 

2. Some concerns where about that this approach might pollute the DFZ with validation results. 
I don't think that is the case if we want the tagging to be limited to the IXPs network.

3. About the comment that forwarding ROA invalids is useless without BGP ADD-PATH, I think this was mentioned by Nick several times.
The draft foresees the usage of ADD-PATH, *if* that becomes available widely to EBGP. In that sense, the case for dropping
ROA invalids becomes even weaker.

4. It was said that RPKI deployment is easy nowadays so why provide another less secure method. 
The draft is intended for networks that can't (technically) or won't (politically) implement RPKI in their own networks, 
but would use of the singling from the route server at an IXP. 
If people can deploy RPKI themselves this is the best solution and we strongly would encourage such deployments.

Looking forward to have a discussion around this and maybe we can find a way to make this work.

Best regards,
Daniel

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 31 Aug 2018 16:28:07 +0100

Hi Daniel,

Daniel Kopp wrote on 31/08/2018 13:01:
> The draft is intended for networks that can't (technically) or won't 
> (politically) implement RPKI in their own networks,

If an organisation won't implement RPKI for policy reasons, then that is 
a decision that they are responsible for, and it is not really the job 
of the IETF to engineer around their layer 9 problems.

Regarding the "can't technically" position that some networks find 
themselves in, this argument is evaporating quickly, as more bgp stacks 
implement RO validation.  All the major vendors do this already on 
current equipment, so this is beginning to become a question of whether 
people are on current support contracts or not, which brings the issue 
back to a policy decision on their part, rather than strictly a 
technical decision.

> maybe we can find a way to make this work

This is the crux: in the context of ebgp and public exchange of NLRIs,
the draft presents a methodology which is incompatible with good quality 
network engineering and product design.  I don't believe this can be fixed.

Nick

---

From: Randy Bush <[email-masked]>
Date: Fri, 31 Aug 2018 18:43:46 -0700

> I don't think that is the case if we want the tagging to be limited to

considering the massive community mess in the dfz, this does not sound
like major new damage.

otoh, assuming non-propagation turns out (by measurement) to be quite
naîve.

randy