Hello Steven,
> The same principles apply here. Given the desire to bootstrap secure
> routing, we concluded that most ISPs would rely on local -- very local
> -- caches. In fact, I suspect that many, especially large ones, would
> want a cache per POP.
The fact that you say "we concluded" is indeed very interesting. I
wonder how much real ISPs and SPs have contributed to this conclusion.
To the extend I was part of those discussions I saw very little to none.
> Given this, and given the reality of available platforms, we had to
> make a decision. The usage model suggests that the risk is low;
> the capabilities of the platforms suggest that we couldn't actually
> get the security we wanted,
Sorry to say this today but I think that you got the deployment model
wrong which directly translates into platforms you are performing the
actual validation on. I recall feedback from operators in the early
stages of the design which suggest that validation could be done in few
places of the domain then security applied p2mp once wrong route is
detected.
Contrary you went and recommended upgrade of each ASBR. This is pure
fantasy. There are IETF drafts by vendors who say black on white that
some of their products will not get any new features in. That means that
as long as this equipment is running basic origin validation will not
get deployed.
When I sit and look from the perspective of both vendor and operator I
do wonder what is the real goal here.
Last you still have not commented on the applicability of the statement
you quoted. What is it actually saying considering no validation for IGP
routes nor IBGP routes if anyone would like to carry it's internal
reachability subnets within ibgp.
Happy Holidays !
R.
Let me clarify what I said (and include context that I should have
put in my earlier note).
Security mechanisms are not designed in a vacuum. One has to consider
the users, the threats, and the usage scenarios. To take an absurd
example, while I can do Caesar ciphers in my head I'm quite incapable
of mental exponentiations of 2048-bit numbers; accordingly, I'm forced
to trust a computer to do those for me. On the other hand, if I'm
trying to protect a secret from a first grader who has just learned
how to read, a Caesar cipher may be all I need.
The same principles apply here. Given the desire to bootstrap secure
routing, we concluded that most ISPs would rely on local -- very local
-- caches. In fact, I suspect that many, especially large ones, would
want a cache per POP.
You're quite correct that this implies no validation of IGP routes.
That's by intent -- the very first sentence of the abstract states
that RPKI is intended to validate BGP routes. (If you have outsiders
sending your internal routes into your IGP via BGP, you have bigger
problems that RPKI can fix...)
Given this, and given the reality of available platforms, we had to
make a decision. The usage model suggests that the risk is low;
the capabilities of the platforms suggest that we couldn't actually
get the security we wanted, just like I can't do mental RSA (at least
until I get that brain chip implanted....).
On Dec 23, 2011, at 5:44 36AM, Robert Raszuk wrote:
Steven,
If the cache is within your domain the below sentence does not apply as you are not validating your IGP routes to bootstrap a router's reachability to a cache.
If the cache would be outside of your domain this sentence would apply as you would require to accept and install some set of essentially "NOT FOUND" routes to reach the cache.
Therefor if authors of draft-ietf-sidr-rpki-rtr-XX are really serious about recommending to keep the cache locally within each domian the below sentence you are quoting should be fixed or removed.
Rgs,
R.
Let me call attention to this sentence, too:
It also SHOULD be
topologically close so that a minimum of validated routing data
are needed to bootstrap a router's access to a cache.
That is, there are other, quite important, reasons to keep the cache
very close to the router(s) it serves.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
--Steve Bellovin, https://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf