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

[Erik Nordmark <erik.nordmark@sun.com>]

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