At Mon, 20 Oct 2008 15:51:47 +1000, Terry Manderson wrote: > > Here is a hypothetical scenario that I think is technically viable. > > Consider two initial parties, Party A and B. Party A is the well > mannered ISP who regularly fetches and validates the RPKI repository. > Party B who is multi-homed is intent on doing an attack of some form > on party A's customers. The entity that allocated the IP address space > to party B for some reason retracts the allocation (expired > membership, Law enforcement action etc) and issues a BOA. > > Party B somehow sees this happen and puts into play a mechanism close > to the repository which identifies the collection of the updated > manifest, 3779 certificate, and associated BOA - They then in transit > modify one bit of data such that any of the following occurs for > relying parties: > manifest fails to validate > the object's hash doesn't match those of the manifest and the objects > fail to validate > > This means that depending on the policy of the relying parties, the > bgp announcement from party B will remain in place for as long as the > MiTM attack is happening on the repository elements related to party > B, and party B's attack on customers of party A (or others) can remain > in place. > > Using TLS would make this MiTM attack substantially more difficult to > do with the intent of successfully downloading valid data from the > repository for RPKI validation. > > .. Am I mistaken, is this not a valid attack on the RPKI infrastructure?
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 b) An on-path attacker can DoS the relying party even when TLS is in use, albeit somewhat more crudely. So I don't see that TLS buys you much here, and you haven't said 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?). _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
