Re: [Sidrops] [routing-wg] misconceptions about ROV

[Tim Bruijnzeels <[e-mail]>]

Job,

Thank you for your reply.

I understand your concern about getting the 'basics' deployed first.
I am also willing to implement basic support in krill after 0.10.

I interpreted your use of capitals to mean that you wanted me to stop
the discussion beyond the current set of standards. I feel that you
interpreted my desire to discuss these things as unwillingness to
implement - but I don't see how these things conflict.

With regards to "looking for help".. not the most respectful way
of phrasing it.. but let's move on.. I asked questions about the
downgrade specifically. I don't think that I am the only one who was
unclear on this specific issue - and I felt that clarity would help me
and others.

With regards to "inconsistent positions".. This is not a bug, but a
feature of discussions involving listening and learning.

The source of this communication style is that I was trying to have
an open face-to-face-like exchange over email.

Since you and I are both going to the IETF meeting - how about having
a chat there and clearing things up?

Tim



> On 24 Feb 2022, at 11:54, Job Snijders <[e-mail]> wrote:
> 
> On Thu, Feb 24, 2022 at 10:16:39AM +0100, Tim Bruijnzeels wrote:
> > > It seems you overlook some deployment aspects, for example: within a
> > > given Autonomous System (during the incremental deployment of BGPsec -
> > > which may take years) there will be ASBRs that support BGPsec and ASBRs
> > > that are unable to negotiate support for BGPsec. For example, it is
> > > entirely possible that at a given moment in time only half the
> > > adjacencies for 206238_15562$ are BGPsec capable, and half are not (yet).
> > 
> > Not at all - any adjacencies that are not BGPSec capable would not issue
> > any statement that they are capable. So stripping the signatures there
> > would be entirely expected.
> > 
> > I am talking about something else: signalling deployment beyond direct
> > sessions in order to enable detection of downgrade attacks. If router
> > can detect that the *entire* path is not only capable but also
> > committed to do BGPSec then removal of signatures can be flagged as an
> > attack.
> 
> At the risk of repeating myself: signalling at AS-level granularity
> seems too coarse for deployment reality. An AS might be able to do
> BGPsec in one part of their network, but not in other parts of their
> network. Another consideration: not all Autonomous Systems operate with
> a coherent backbone, some AS are "islands".
> 
> Imagine AS 65000, 65001, and 65002, who all have half their ASBR
> footprint BGPsec enabled; neither of those 3 AS can 'commit' to BGPsec;
> other than through per-BGP-session negotation. BGPsec islands connect to
> each other by virtue of unbroken valid signature chains.
> 
> 
> > > See this posting for a similar story on RPKI ROV invalids:
> > > https://mailman.nanog.org/pipermail/nanog/2021-April/213346.html
> > > 
> > > Frankly speaking, wouldn't it make far more sense to implement the
> > > specifications AS SPECIFIED AND PEER-REVIEWED BY MANY PEOPLE,
> > > *before* advocating new object profiles?
> > > 
> > > Especially since the CA side of BGPsec is so straight-forward and
> > > simple to implement ... ?
> > 
> > There is no need to shout Job..
> > 
> > I was trying to have a discussion about a possible way to help
> > operational future deployment.
> 
> I appreciate all the help you are willing to provide, but I question the
> soundness of initiating discussion about 'future deployment' while the
> first steps have yet to be set on the path towards deployment. How can
> anyone meaningfully comment on future operational deployment challenges
> without any operational experience with BGPsec "as is"?
> 
> > This is in no way preventing the development and deployment of current
> > standards. And should the idea be useful and accepted then of course
> > it would be handled as a WG document, be peer-reviewed etc.
> > 
> > I know - it's naive to think that that would be what the IETF
> > is for. Fine. I will stop here. Discussion once again seems
> > entirely pointless.
> 
> At times it seems you look to this WG for help, other times you purport
> opinion on what the future direction of RPKI / Secure Routing should be,
> and then other times you appear to engage in research/brainstorm
> activities. It is hard to tell which is which at times.
> 
> The current discussion might appear challenging because your positions
> appear inconsistent: first you expressed heavy skepticism to the point
> that it might even discourage others to consider BGPsec ("it doesnt
> scale"), then you pivot to suggesting new object profiles, all the while
> writing messages which contain imprecise terminology.
> 
> Here you ask for pointers: https://mailarchive.ietf.org/arch/msg/sidrops/shD2HMkgDrXSf7dLI6GAkOuaoKg/
> Here you reply you could find the documents yourself: https://mailarchive.ietf.org/arch/msg/sidrops/DcbDU25miO0Rcc9Hbd85kaDvDx0/
> 
> Here you ask whether there is 'operator demand': https://mailarchive.ietf.org/arch/msg/sidrops/XOHyvcRKH6VOG310jAUppzRXliA/
> But already back in October 2021, you yourself noted: "Wrt BGPSec.. I am actually very happy to see that so many people are in favor of supporting it.":
> https://www.ripe.net/ripe/mail/archives/routing-wg/2021-October/004454.html
> 
> It seems to me that one could extrapolate appetite for BGPsec in managed
> CA environments to mean that people also would like BGPsec support in
> all other CA implementations.
> 
> Let's make BGPsec a reality! It all starts by actually making BGPsec
> available to operators.
> 
> Regards,
> 
> Job