Hi Rob,
On 19/10/2008, at 5:22 AM, Rob Austein wrote:
I'd also question the purpose of TLS (ie, HTTPS vs HTTP) in this
context. All the data are signed, there's no confidentiality or
access control reuirement as far as I know, and the manifest design
was specifically intended to remove the need for channel security.
The draft doesn't contain any real analysis of what threats the
protocol needs to defend against or why TLS is the right solution.
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?
Terry
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
