On 21/10/2008, at 8:09 AM, Rob Austein wrote:
You appear to be describing a selective DoS attack by an on-path attacker. Unless I'm missing something, adding TLS to the mix here changes details but doesn't change the overall situation much, as: a) The attack was already detectable without TLS (those validation failures you mentioned), and
I think the difference is that the validation failures are much harder to nail down to a cause. ie was the rpki repository itself compromised? was the file modified in transit? was file put to disk erroneously? and many others .. I'm not sure that is a clean outcome.
b) An on-path attacker can DoS the relying party even when TLS is in use, albeit somewhat more crudely.
That sort of attack that really is disruptive to the entire channel and therefore to the fetch entirely. Not just the validation. But yes, still a risk.
So I don't see that TLS buys you much here, and you haven't said
What TLS buys is the acceptance of the 'uber' security-oids who have secret decoder rings that look on this effort to secure the routing path, but don't secure the fetch mechanism from common well known attacks that can be specific in nature, and thus consider the attempt less than ideal.
anything about the risks and costs of adding it: new trust relationships (adding channel trust relationships to what had previously been an end-to-end object security model) and new potential attackers (who did you say issues the TLS certificates?).
No, I didn't, the issue there is who is the trusted party? I'm happy to explore the options, although would it be appropriate for resource repository servers to be issued certificates following the allocation path?
I don't see that using an un-secured channel to collect this information (validate-able or not) as going far enough to satisfy what the RPKI work is trying to achieve as a full end-to-end framework.
While I'm not in love with rsync for this, adding TLS to rsync directly would go a long way. Having said that the last rsync patch I saw for this ('07) failed to work properly - I'm not aware of further work.
Terry _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
