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

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


El 16/03/2007, a las 22:24, Erik Nordmark escribió:


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.



right
In this case, it seems that the host will send a packet with destination address the cmula and the P-shim won't have the locator information associated to the CMULa. In this case, the P-shim6 will perform a reverse lookup for the CMULA and retrieve the locator information from the DNS. (This can be handled in the same way the case where there is a failure in the primary P-shim6 and the backup P-him6 is used)
This would of course result in additional latency for the time required to retrieve the locator information
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. 



yes, need to add that part then
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. 



i agree

the order of preference would be
1- an locator ID mapping verified using HBA/CGA
2- a locator ID mapping verified through reverse DNS
3- a locator ID mapping obtained through direct DNS (ULID RR and AAAA RR for the same FQDN) 

In case of conflict, the one with higher preference wins
If two with the lower preference are obtained, then the P-shim must use a higher preference method to determine which one is the correct one 

makes sense?

i will add this to security considerations section of the draft

thanks
> 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. 



yes you are right
this is not similar to DNS cache poisining since there is no trust chain for publishing ULID RR in the direct tree 

regards, marcelo


   Erik