At 2:35 PM -0700 12/15/08, Danny McPherson wrote:
Note that such certs could be issued by IANA even if each RIR is a
"default" TA, and used by RP software as an independent check on
the consistency of the RPKI TA certs issued by RIRs to themselves.
Steve,
Can you expand upon this comment? Would this be a normal
model to operate or is there some offshoot?
This is definitely a special case. In a "normal' RP environment,
there would be no provision to perform this sort of cross check. I
fairness, however, use of the 3779 extension in path validation is
not supported by most RPs anyway, so the RPKI is special. Also, since
we see a need to provide tools to enable an RP to manage TAs to allow
for use of RFC 1918 addresses (locally), it would be simple to add
this cross check into such code.
Somewhat related...
Here's one of my issues with multiple RIRs being TAs. Some
RIRs invest much more heavily in security than others, and NONE
currently have an operational role in routing on the Internet
(this talk of weekends, holidays, et al., illustrates the issue).
If someone were to launch a targeted attack they could first
compromise the least secure RIR (TA), and then they can do what
they wish and affect ANY resource, right?. Whereas, with a single
TA model, the attack surface would only involve a single RIR and
IANA up my validation path, is that correct? What other factors
should be considered here?
I agree with your analysis. Having RIRs be TAs without a cross check
capability does increase the overall system vulnerability, for the
reasons you cited above.
What about security of the repository in a multi-TA model, are
there things that should be considered there?
I don't think the repository system incurs significant additional
risks due to adoption of a multi-TA model, since each RIR seems like
a "natural" host for repository data for its members. Also, we put
in a number of safeguards (based on data being signed by the
cognizant authorities, typically ISPs) to minimize the risks posed by
attacks against repositories But I admit to not having looked into
this issue closely.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
