Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

[Nick Hilliard <[e-mail]>]

On 22/11/2013 09:47, Geoff Huston wrote:
> so we get back to RPSL.

I wouldn't look to RPSL as being the solution to a whole lot.

> But I am still wondering:...
> 
> Why are we using GROW to host this discussion?

because the WG has got a nice operator-friendly feel to the name and there
is no other document in the accumulated tomes of ietf lore which explicitly
states that prefix origin validation in its current form is operationally
limited in scope and that if there are organisations out there who feel
that they'll get a kwik-fix sticky plaster solution for their routing
security concerns by turning on rpki, they need to think again.  It's
probably not a bad idea to have a document like this although I'm not much
interested in the politics of whether it belongs in grow or even the ietf.

> And if we are ready to reopen this consideration of requirements for
> securing the operation of BGP, just how much of this are we willing to
> re-consider? Is it all the way back to RPSL and RPSS?

draft-ietf-sidr-bgpsec-reqs is a good start.  Re: your comparison with
dnssec, the latter has the interesting property that it is fully
hierarchical with a single root and therefore the object relationship model
is relatively easy to handle - particularly when attempting to retrofit it
with a hierarchical trust model.  With bgp we have a highly fluid peer to
peer relationship mechanism which rpsl attempted to document, and here we
are trying to determine whether a top-down hierarchical pki could form part
of a trust mechanism to determine the validity of prefixes and paths so
that we dumb operators can reach the holy grail of being able to believe
what we see when we type "show bgp blah".  RPKI can work for prefix origin
validation because prefixes are assigned hierarchically.  AS paths -
transit and peering relationships - are not assigned hierarchically, so
there seems little reason to think that a hierarchical trust model would be
the most appropriate mechanism to use for securing this.  Or am I being
naive here?

Nick