[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-bagnulo-pshim6-00.txt



marcelo bagnulo braun wrote:

It sounds brittle to rely on one of the P-shims to always have the cached locators in the cases that a host might have retained the CMULA.

For instance, there is plenty of host software (even though it is broken) which retains DNS answers past the expiry of the DNS TTL. Thus some host software might retain the CMULA long after the P-shim's have timed out the DNS information.

FWIW I didn't see a response to the above robustness issue.

but in any case the P-shim will perform the shim6 context establishment and will use the HBA/CGA technique to verify that the ULID to locator binding is ok, so, even if some attacker manages to install the false id to loc mapping in the P-shim, it would still have to be able to crack the HBAA/CGA protection, right?

I forgot about that because the draft didn't explicitly say that it is done and when it is done.


If the HBA/CGA check isn't done until the P-shims do the exchange there is still a source of confusion (hence possible redirect attacks) before then if the P-shim caches things based on the DNS response.

A way to avoid this is to invalidate the locator cache in the p-shim entry when there is a conflict, but even that seems shaky to me. Suppose the lookup for H2.foo.com comes back the shim returns the ULID 1::1 to the host. The shim caches the mapping from 1::1 -> {x, y, z}. If/when a shim6 exchange with 1::1 has verified that using HBA/CGA that mapping can be marked as 'verified'. But if there is some other DNS lookup (for H3.bar.com) via the same shim resulting in the same ULID but different locator set being returned by the DNS, then an unverified mapping should be discarded and a new mapping should not be setup (pointing at a different locator set). In this case the shim MUST do a ULID->locator set lookup (using the DNS as the example mechanism) to avoid a redirection DoS for one of the communications.

> the result would be some form of DoS attack, but i guess that this has
> similar impact (and should be protected with the same tools than) a DNS
> cache poisoning...

This has nothing to do with DNS cache poisoning.
The issue is that if you ask for a RRset for H3.bar.com the DNS server which is authoritative for that zone can return whatever it pleases - and it could be signed by DNSsec - because it is authoritative.

Thus using the fact that H3.bar.com says ULID=1::1 and AAAA set = {a, c} is completely unrelated to which DNS server is authoritative for the lookup of the ULID (in the reverse tree). It is the delegation of the reverse tree that provides the authorization.

   Erik