El 16/03/2007, a las 1:15, Erik Nordmark escribió:
marcelo bagnulo braun wrote:This is described in the draft in this way. The DNS reverse tree is used to retireve locator information associated with an unroutable ULID. In concrete, it is used in the following situation: A shim6 context has been established between aP-shim and a remote shim6 peer (either P-shim6 or a shim6 host). TheP-shim6 that has the shim6 context information fails and the backup shim6 is used to continue with the communication. In order to do that, the context information must be restored. In this case, the backup P-shim6 needs to retrieve the locator information associated to the ULID of the remote peer. It does so, by performing a DNS reverse lookup for the CMULA used a ULID.However, it should be noted that the locator information was already available in the site, in particular, it was available in the primaryP-shim6. So it would be perfectly possible to create an inter-P- shim6 protocol to exchange locator-ULID binding information between the primary and the backup P-shim6 as soon as the the context is created. This would distribute the locator to ULID binding information and there would be no need to retrieve it from the DNSreverse tree (and there would be no need to require the population ofthe reverse DNS tree if such inter-P-shim6 protocol was available.It must be noted that the reverse tree is never used to retrieve ULID locator binding information for initial contact, but is only used to restore information that was once available locally. this is why, itis perfectly possible to design local mechanisms to substitute the usage of the reverse DNS in the P-shim6 approach.So i am perfectly open to define a new protocol for this and forget the reverse DNS completely if people prefer this. This is not central to the P-shim6 approachIt 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.But I think there is also a potential security issue the way you describe the DNS lookups and caching.This is how I understand it. An unmodified host looks up H2.foo.com. The P-shim caches ULID = 1::1 AAAA = x, y, zand returns the ULID to the host. As a result of this the P-shim established a local mapping from 1::1 -> {x, y, z}.Later a possibly different host in the same site looks for H3.bar.com. For some reason the ULID returned from the DNS is also 1::1. But the AAAA set is {a, b}.Which mapping will be P-shim use for ULID 1::1?The P-shim can't tell the packets received from its hosts apart since both the ones destined to H2.foo.com and H3.bar.com have the same ULID in the IPv6 header. Should it let H3.bar.com lauch a succesful redirection attack for the packets that were really destined to H2.foo.com?
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?
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...
makes sense? regards, marcelo
The only way I know of addressing this is to check who is authorized to specify the locators for ULID=1::1. If we are using the DNS that can be done using doing a ULID->locator lookup when caching the mapping in the P-shim. And AFAICT the same type of lookup would be needed if a protocol different than DNS was used for the lookup.Thus I think a ULID->locator lookup mechanism is mandatory to avoid redirection attacks.Or am I missing something?
Erik