On Mon, 14 Feb 2011, Shane Amante wrote:
Chris,
Rather than waste a lot of time doing a point-by-point response, let's boil
this down to the most simple question. Once we get a common understanding on
that, we can (hopefully) discuss other points.
First, I understand how the current RPKI is intended to be deployed and operationalized. I also acknowledge the
present "capabilities" in the RPKI that we knew about the time RPSEC wound down and SIDR was formed,
namely that the RPKI only contains ROA's, and associated certificate material, that is intended to allow
3rd-parties to authenticate a given ASN is "allowed" to originate a given prefix (or, set of prefixes,
i.e.: /16 upto /24). However, and here's the key part, in my understanding all RPKI material (namely, ROA's and
associated certificate material) is carried around "out-of-band" amongst a hierarchy of 'commodity'
servers from IANA -> RIR's -> LIR's/ISP's. At present, there's two things SP's may do to get that material
from those servers into their routers, (doing the actual forwarding):
1) "Pull Model": Routers can use draft-ietf-sidr-rpki-rtr-07 to pull RPKI info
from the RPKI servers and absorb it into their configuration; or,
2) "Push Model": Operators can (re-)use their existing tool-chains, if they so
desire, to push information from the RPKI servers into their routers using existing BGP
policy-statements/route-maps applied to eBGP sessions that have existed for several years.
Either of those models will work. However, and again here's the key point, either of the
above are *not* forcing any RPKI information, (in particular ROA's, certs, CRL's, etc.),
in BGP transport sessions. IOW, BGP continues to blindly (and, quickly) pass around
forwarding information and it's up to [very simple] policy on each router to decide
whether to accept or reject that forwarding information as "legitimate". OTOH,
if my understanding of this draft is correct, we're talking about moving away from that
and carrying not just forwarding information, but also certs and possibly other RPKI
material, etc.? Why? Or, more importantly, why is that a MUST? Why can't additional
RPKI material, (e.g.: beyond ROA's), continue to be pulled or pushed into routers as I
outlined above, (in particular Model #2)?
I don't believe that any requirement in this draft forces carrying certs
or other RPKI data around in BGP. The current deployment out-of-band will
continue to work.
Please point to specific language in the requirements document that
dictates changing the current sidr model.
--Sandy
On Feb 11, 2011, at 13:37 MST, Christopher Morrow wrote:
On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante <[email protected]> wrote:
Randy,
On Jan 30, 2011, at 20:40 MST, Randy Bush wrote:
3.3 As cryptographic payloads and loading on routers are likely to
seriously increase, a BGPsec design may require use of new hardware.
It must be possible to build routers that do BGPsec with within
acceptable (to operators) bounds of cost and performance.
This should be left out of any requirements document, and various
proposed system compared based on their costs and deployment
difficulty.
i take your point. the intent was that compatibility with current
hardware abilities is not a requirement that this document imposes on a
solution. it is quite likely that provider routers will need crypto
assist and more ram. though one hope that the stub customer edge will
not.
Whoa there. I couldn't disagree more wrt the above.
First, let's start with the most fundamental question. Why is it that routers
MUST sign, pass
around and verify _in-band_ in the control plane various contents/PDU's
_within_ BGP? Note my
very careful use of the work _in-band_. By that I mean inside the BGP session
itself, not on a
-shane
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
