Hi Mikael,
At 03:12 11-01-2013, Mikael Abrahamsson wrote:
Some of the failure scenarios I have heard from the dns TLD world:
Zone file was truncated due to lack of disk space. Insufficient
checks was in place to notice the truncated zone file before it was
replicated out to the public-facing DNS infrastructure, thus causing outage.
I heard of that. It's overlooked as it is a detail that's only
important when things go wrong.
DNSSEC failure (don't remember the exact details), ie not everything
was correctly signed, thus causing failure. DNSSEC is an example of
a protocol which is quite brittle operationally. You make one
mistake, and your entire domain is toast.
Yes.
So when implementing RPKI at the RIR level, there should be
operational advice how everything should be done. Preferrably even
at the protocol level, there should be a disaster "off" button which
the publisher can use to just switch off all validation for all
records they handle, and this should be propagated very quickly.
There was a thread on this mailing list about propagation. There is
a level of operational advice which a document does not get into as
it cannot cover everything. You seem to be asking about failures by
entities outside your control and an "off" switch to avoid it from
affecting your organization. draft-ietf-sidr-bgpsec-threats-03
doesn't get into that.
Frankly, I'm scared when I read the documentation for this (=SIDR)
thing. I feel it fails the "KISS" test with all the CA, signing,
propagation infrastructure needed. It's also quite different from
anything else that the normal network engineer is exposed to
historically in their day to day work life. It's my opinion that a
lot of careful though put into how this is actually implemented in
real life, making sure there are operational tools (I still have not
signed my private domain with DNSSEC because the operational tools
are too hard to use) in place to aid deployment.
There's a steep learning curve. Taken as a whole the documentation
fails the "KISS" test. I agree that it is necessary to give a lot of
careful thought about how this is actually implemented.
Is it too early in the protocol development process to start looking
into the operational aspects?
I don't have an opinion about this.
Regards,
-sm
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
