Subject: [rrg] GLI-Split Locator Gleaning explanation

From: Robin Whittle <[email-masked]>
Date: Thu, 11 Feb 2010 23:17:14 +1100

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

---

From: Robin Whittle <[email-masked]>
Date: Fri, 12 Feb 2010 14:06:19 +1100

Here are two other questions about things I can't yet understand in
the proposal (2009-12-22 version):

According to section 2.3.2, a host application running on a GLI-host
(all applications are the same with GLI-split - the same as before,
with no new functions, API, IP address or DNS behavior etc.) can look
up a FQDN in the DNS, and will always receive an IP address with a GL
locator and the GAP bit set.

The application opens up a TCP socket with this address.

Now consider the top left of Figure 4.  This is the transport layer
(the TCP layer) in the sending host.  The source and destination
addresses are shown as being in "Identifier" format: without any GL
or LL and without the GAP bit set.

I am trying to write up my own understanding of how GLI-split works,
from a GLI-updated host in one GLI-domain to a host in another
GLI-domain, when that recipient host is either GLI-updated or an
ordinary IPv6 host.

One set of explanations, around pages 6, 7 and 8, refers to the hosts
(nodes) as if they were black-boxes.  Another explanation in section
3.2.x refers to what happens inside the host stack, in a general way
- but not in reference to all the various modes of operation of the
GLI-Split system.

I am unable to reconcile the application using an address with a GL
and GAP bit set with the Figure 4 and 3.2.x explanation.

Hosts today can have multiple IP addresses, so they can behave, to
the outside world, like multiple hosts (since in today's IP naming
model, the identity of a remote host IS its IP address).

How does GLI-Split work when a host has multiple Identifiers - which
would be the equivalent of a host having multiple IP addresses today.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Fri, 12 Feb 2010 15:35:08 +1100

Short version:  I think GLI-gateways need to watch for PTB messages
                leaving the network and modify those which were
                generated by packets with the AB extension header.

Here are another question about (2009-12-22 version):

regarding Path MTU Discovery.

I will write in a separate message why I think GLI-Split is a
Core-Edge Elimination architecture.

Address-rewriting architectures such as GLI-Split and Six/One Router
have a significant advantage over those Core-Edge Separation
architectures which use encapsulation, which they all do except for
Ivip with upgrades to all DFZ routers.  Encapsulation leads to some
difficult Path MTU Discovery problems - which can in general be
solved at the expense of more complexity in the ITRs and ETRs, and in
the use of extra packets between them and to the Sending Host (SH) to
manage the difficulties.

On page 21:

   ... GLI-Split does not suffer from potential problems due to
   increased packet sizes after encapsulation ...

However, the GLI-gateways and the GLI-stacks sometimes add or remove
an "Address Buffer" (AB) extension header.  It is not clear how long
this would be, but I guess 4 bytes for flags and 16 for the address
it contains = 20 bytes.

Figure 5 shows GLI-gateway N adding an AB to the right-moving packet
and removing one from the left-moving packet.

For the right-moving packet, if the packet runs into an MTU limit
between the N GLI-gateway and the Destination Host (DH) with Identity
3, then the PTB (Packet Too Big) message will go back to the Sending
Host (SH), which is an ordinary IPv6 host.  The SH will not recognise
this PTB, since it contains the initial 500 or more bytes of the
left-going packet after the extension header was added.

As far as I know, the only solution for this would be for the one or
more GLI-gateways in the GLI-domain to look out for all PTBs leaving
the network and modify them, firstly to remove the AB extension
header and secondly to alter the MTU value accordingly so the SH gets
a value it can use, to create a packet which once extended by 20
bytes or so, will fit through the MTU limiting router.

Monitoring and potentially modifying outgoing PTBs would be a
considerable extra burden on GLI-gateways.

For the left-moving packet, if a PTB was generated within the
GLI-domain, then it would go straight back to the SH (on the right)
and the GLI-updated stack there would recognise it and calculate an
appropriately shorter MTU value to send to the rest of the stack, to
account for the extra AB extension header it will add to outgoing
packets addressed to the same IP address.

If the left-moving packet hits an MTU problem somewhere outside the
GLI-domain, the PTB should go back through the GLI-gateway, and again
the GLI-modified stack can interpret it correctly.

  - Robin