[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:


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 a
   P-shim and a remote shim6 peer (either P-shim6 or a shim6 host).  The
   P-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 primary
   P-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 DNS
   reverse tree (and there would be no need to require the population of
   the 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, it
   is 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 approach
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.
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, z
and 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?
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