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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
