Re: [RRG] Re: Six/One Router revised 2008-07-12 - IPsec

[Robin Whittle <rw@firstpr.com.au>]

Short version:   Like my Ivip6 proposal, I think that Six/One Router
                 requires the redefinition of the current Flow Label
                 bits to be used for another purpose.

                 Hosts would need to ignore the current "Flow Label"
                 bits when scrutinising the original packet in
                 ICMPv6 Error Messages, including Packet Too Big
                 messages, since the Translation Routers may
                 change at least one bit there.  (This applies
                 to my Ivip6 proposal too - maybe some minor
                 tweaks to host stacks would be required.)

                 I can't see how Six/One Router's Unilateral mode
                 could support IPsec authentication of the IPv6
                 header.


Hi Christian,

Thanks for this:

> Wow!  Thanks a lot, Robin, for this thorough review of Six/One Router!

I was looking for problems, but it goes without saying that I think
that the prospect of doing translation - or anything else - which
doesn't involve encapsulation has so many benefits that we should
pursue these options with vigour.

> This is by far the most careful review I have ever gotten on a paper
> -- longer than the paper itself. ;-)   Please give me some time to
> respond to your questions.  Will do so ASAP.

I am sure it is not longer, and it only took a fraction of the time
and effort you put into writing your paper and devising this second
version of Six/One Router.


One thing your current proposal requires is the use of a bit in the
IPv6 header:


http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf

Page 6:  This paper suggests reserving a bit in the IP header,
         henceforth called the Bilateral/Unilateral bit, to
         distinguish the mode in this case. (3)

         (3) An alternative to reserving a bit in the IP header is

             to specify an extension header that identifies the mode
             in which packets are exchanged.

An extension header would remove probably the greatest attraction of
Six/One Router - no extra packet length.  So I think you really need
a bit from the header.  The only place I think that could come from
is the Flow Label.

So in order for Six/One Router to be deployed (without extension
headers) I think you would need to have the Flow Label bits
redefined to provide a place for your Bilateral/Unilateral bit.
Hosts would need to not rely on the current Flow Label bits being
unaltered in the network.

The core routers (other than the translation routers) would not need
to be changed.

In order for PMTUD to work in the translated part of the path, and
for all the other ICMPv6 Error Messages (RFC 1885) to work in that
part of the path, the sending host would need to ignore the state of
your Bilateral/Unilateral bit in the copy of the offending packet
which is enclosed in the ICMPv6 Error Message.

Hosts should be very fussy about accepting ICMPv6 Error Messages, to
protect against an off-path attacker guessing the values of packets
recently sent and thereby successfully launching a DoS by sending
spoofed ICMPv6 Error Message packets to the sending host.

There are no specific details in RFC 1885 or in the PMTUD RFC 1981
about how fussy hosts should be before accepting an ICMPv6 Error
Message.

I think this is probably quite feasible.  In the longish timeframe
we have for deploying a scalable routing solution for IPv6, I think
there would be time to tweak host stacks to make them ignore the
current "Flow Label" bits when checking ICMP Error Messages.


My new "Label Forwarding" proposal (Ivip6) was prompted by looking
into the IPv6 header for a place for your bit - and finding the Flow
Label the only likely place to grab a bit from.

My proposal uses the entire 20 bit Flow Label for another purpose.
So like your proposal, I need to argue why we don't need the Flow
Label in the future, and why it is worth putting these bits to a
better purpose.  The ITRs and ETRs of my proposal - and the
translation routers of yours - obviously need to do new things with
the old "Flow Label" bits.  With your proposal, the existing core
routers should be fine - since they currently pass on and otherwise
ignore the Flow Label bits.

However, for my proposal to work, most of the core routers need to
be upgraded to have new forwarding behaviour, based on the state of
these 20 bits.  So your proposal has a bunch of hurdles, and mine
has one extra large hurdle in this regard.

Still, being able to do a scalable routing system for IPv6 without
encapsulation would be an enormous advantage over map-encap
approaches - so I think there are strong reasons for convincing
everyone these hurdles should be jumped.

I will write some more another time about why I think the Flow Label
is of very limited value indeed.


In my critique, I questioned whether it was OK to simply adjust 16
bits of the address you are rewriting to keep the checksums the
same.  This is discussed on the right of page 7 of your paper.

    This technique is applicable to all packets, even if their
    payloads are integrity-protected or encrypted. It is
    also efficient because the checksum does not have to be
    localized within a packet. Mapping edge and transit
    addresses such that the checksum does not change during
    address rewriting is practical where the routing prefixes
    of IPv6 edge and transit addresses are at most 48 bits long:
    The remaining 16 or more bits in the standard 64-bit subnet
    prefix of an IPv6 address can then be used to compensate for
    the checksum difference that rewriting of the routing prefixes
    alone would create.


I am not used to the "0 = MSB" way of talking about bit numbers.
Using ordinary 127 = MSB terminology, I wrote that you would need to
alter bits 64 to 79 (63 to 48 in network byte order) to do what you
propose, according to how you changed bits 80 to 127 (0 to 47) in
the rewriting operation.  Here is a diagram which avoids bit
numbers.  It is in hex with MSB on the left.

    MSB                                 LSB

    xxxx xxxx xxxx yyyy zzzz zzzz zzzz zzzz

z bits are unaffected by address translation.

My understanding is that you want to rewrite all of x and y bits,
but you think that in order to keep the checksum the same.  So the
best approach is to rewrite the most important (most significant)
bits the way you want, and not try to be specific about the yyyy 16
bits, because you are going to have to set them to some value based
on the other changes (difference between the 16 bit sum of the
original xxxx xxxx xxxx bits and the 16 bit sum of their translated
values) to keep the 16 bit checksum from changing.

This therefore would limit the use of your system to prefixes of /48
or shorter - which is not much of a problem, I think.

This all sounds very messy.  I could imagine it working, but I think
there might be some nasty gotchas in there somewhere.


The IPv6 header itself has no checksum, but the UDP and TCP headers
have 16 bit checksums, which include the header.  So far, so good -
adjusting those 16 yyyy bits should do the trick.  I assume these
checksums are important to each core router in the translated part
of the path, because the routers will drop a packet with a bad checksum.

However, I can't see how Six/One Router could work in certain
scenarios and still support IPsec header authentication.

In Figure 2 (Bilateral), there is no problem, because the
destination host gets a packet which is identical to that sent by
the sending host.

However, in:

  Figure 4: (Unilateral) Backwards compatibility for packet
            exchanges between upgraded and legacy edge networks

and

  Figure 5: Packet exchange in Unilateral mode between
            upgraded edge networks

the received packet has different addresses from those in the packet
which was sent.

My understanding of the RFC 4302 3.3.3.1.2 is that the source and
destination addresses are included in what is checked by IPsec.
(The Flow Label, thankfully, is not.)

This is a new critique:  as far as I know, the way IPsec processes
these items in the header is not a simple 16 bit checksum.  I
understand there are multiple possible "integrity check" methods
which can be used.  These advanced hash algorithms do not simply
work would with 16 bit checksums on their input material.

  http://en.wikipedia.org/wiki/Ipsec

    Transport mode

       In transport mode, only the payload (the data you transfer)
       of the IP packet is encrypted and/or authenticated. The
       routing is intact, since the IP header is neither modified
       nor encrypted; however, when the authentication header is
       used, the IP addresses cannot be translated, as this will
                 ---------------------------------

       invalidate the hash value. The transport and application
       layers are always secured by hash, so they cannot be modified
       in any way (for example by translating the port numbers).
       Transport mode is used for host-to-host communications.

The way to get around this for ordinary NAT is to encapsulate the
whole packet in IP and UDP headers:

  http://en.wikipedia.org/wiki/NAT-T
  http://tools.ietf.org/html/rfc3948

but doing that would cancel the primary attraction (I think) of
Six/One Router over map-encap: the fact that the packet does not get
any longer.

I haven't looked at all this in detail, but my impression is that
Six/One Router, except in the Figure 2: mode (Bilateral - between
two upgraded networks) would be incompatible with IPsec.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg