Hi Michael and colleagues, When reading pages 15 of your proposal (2009-12-22 version):
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf 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 domain. 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 rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
