Hi Michael and colleagues,

When reading pages 15 of your proposal (2009-12-22 version):


I think the text regarding locator gleaning is out of sync with
Figure 6.  Here is what I think would be a correct version:

   The attacker behind GLI-gateway X pretends to be node 3.
   It sends a packet with ID 3 in the source address to
   node 1. GLI-gateway F receives the global GLI-address X.3
   or X(g).31 and updates its local cache for the global MS
   with the mapping entry 3->X ("locator gleaning").  When
   node 1 contacts node 3 later, GLI-gateway F uses the wrong
   locator from the local cache and the packets destined to
   node 3 will be delivered to the spoofing node behind X
   instead of the correct node behind N.

Can you confirm that this is correct?

I think the diagram should also show the initial packet (from the
attacker) going to node 1 on the right - and so with a third box to
the right of the two already shown for this initial packet.  I think
it would help to show the full destination in those two boxes too:
"F 1".  In the third box, which I suggest be added, I understand the
contents would be:

  Dst:  ID 1
  Src:  ID 3

This would mean that 1 will consider it has received a packet from
the genuine node 3, as far as I can tell.

If so, then the only solution I can think of is for the GLI-gateway F
to hold the packet and not forward it, in its translated form, until
it has received a mapping reply for Identifier 3 which confirms that
GL X is one of the one or more GLs for Identifier 3.

Also, the ID hijacking would still work (unless the countermeasure of
 doing the lookup was used) if the attacker sent a packet to some
other Identifier address, such as another node other than 1 in
GLI-domain F, or to an Identifier which did not match a host in that

The countermeasure you mention, of GLI-gateway F doing a global
lookup on Identifier 3 and not caching the 3->X mapping until it
receives the map reply, confirming that X is one of 3's Locator
(which it is not in this example) means that it would have to buffer
the return packet (second line of boxes, going right to left).  But
this delay would occur anyway for the return packet, since the
GLI-gateway F would need to do a lookup for that return packet.

The following sentence (page 16) seems incorrect to me:

   Classic IPv6 nodes including those of a GLI-domain are
   not affected by wrong mapping information since they are
   unaware of locators, identifiers, and mappings.

Imagine if node 1 was not a GLI-Split upgraded node, but an ordinary
IPv6 node.  With the current example, where the GLI-gateway F simply
passes on the attackers packet with:

  Dst:  ID 1
  Src:  ID 3

this "classic-IPv6" node 1 will behave as if it received a packet
from the genuine node 3, and will send a reply accordingly, but
to the attacker's node.  I think the only solution is to have the
GLI-gateway F hold the packet, and not forward it, until it has
received the mapping results for 3 and confirmed that the Locator in
the just-arrived packet "X" is one of the one or more Locators for
Identifier 3.  Only then should it rewrite the packet and forward it
to its local network.

I am still trying to understand all this, and will write more soon.

  - Robin

rrg mailing list

Reply via email to