Re: [secdir] New Routing Area Security Design Team

[Richard Barnes <[e-mail]>]

On Mon, Apr 16, 2018 at 9:38 AM, Russ White <[e-mail]> wrote:

>
> > - The fact that you can intentionally mis-represent the path an UPDATE
> > traverses either accidentally as part of normal prepending operations or
> > maliciously in an attempt to cause traffic to be misrouted. bgpsec was
> crafted
> > to address this issue in conjunction with the RPKI.
>
> And this is where we get into trouble -- because, IMHO. BGPSEC, beyond
> being undeployable, either fails to provide meaningful security and/or
> makes the problem worse. This isn't just a crypto problem, this is a
> structural problem with the solution itself. The IETF's focus on BGPSEC as
> "the only right solution" has caused many in the community to stop looking
> to the IETF for leadership in solving this problem. At least some folks in
> the community are looking at other solutions to this problem in a way that
> intentionally _avoids_ any sort of "deep" interaction with the IETF because
> of the rut the IETF is in.
>
> Until the IETF starts listening to folks beyond BGPSEC supporters, and
> rethinks what needs to be solved, the IETF will continue to play
> essentially no role in moving any solution for this problem forward. Hint:
> ensuring the "proper operation of BGP" is not a good starting point.
>

I'm fully willing to admit that there has been some intransigence on the
security side of things.  And I'm not trying to argue for BGPSEC in
particular, but for solving the problem.

However, the messages in this thread make me think there's not really a
willingness in the routing community to engage seriously in the problem
either.  Security mechanisms exist to enforce invariants, so if you're not
willing to concede that BGP should adhere to some invariants (which is how
Jeffrey's bullet points read to me), then you're never going to be able to
meaningfully secure the protocol, and we should publish an RFC that says
"here's the security properties you can expect of BGP lolz #YOLO CAVEAT
ROUTOR" -- like RFC 4272, but more honest.



> > What is an open issue is the one that originally brought Stewart to
> > saag: The MPLS protocols are in need of a transport security upgrade.
> > As part of that headache, we want to try to get boilerplate and process
> in
> > place so that the next time someone needs to either invent a new
> protocol or
> > upgrade an existing one, we stop making routing experts who are security
> > n00bs go through a dance they don't know the steps to.
>
> Correct -- this is the problem this design team is attempting to address.
> It is not that routing folk don't think the BGP problem isn't a problem, it
> is that the IETF is not a useful place for discussing this problem. Perhaps
> it will be in the future, but right now there is no hope of having a
> reasoned, reasonable, and productive discussion on this topic.
>
> 😊
>

So maybe this group needs a more focused title :)  Because as this thread
demonstrates, when you say "Routing Area Security", people are going to
think you're going to solve actual problems with the security of routing,
not just better transport security -- which really has nothing to do with
routing, it's just securing the routing protocol as an application.

How about "Better Routing Application Transport Security (BRATS)"?  ;)

--Richard