[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AH Last Call complaint: No source route protection in IPv4!

Hi Dan,

> IPv4 SOURCE ROUTING IS NOT PROTECTED BY AH IN ITS CURRENT REVISION.

Yes, that is correct.  As Ran pointed out in the message you quoted:

> It turns out that the way one might read LSRR's specification is
> not the way it has been implemented in most systems that implement
> it.  It has been implemented so that the addresses recorded are
> NOT the arriving interfaces of the listed intermediate systems
> but instead the next-hop after leaving each listed intermediate system.
> This last isn't predictable in the general case.

A better way to phrase "next-hop after leaving each listed
intermediate system" would be to say the "IP address of the exit
interface of the intermediate system".  In the IPv4 loose (or strict)
source and record route option, the IP addresses in the source route
are "mutable and unpredictable", due to the entry addresses being
replaced with the exit addresses (the "and record route" part of the
options).  The exit address is the address that must be used, in IPv4,
in order to be able to cause the return packets to follow the reversed
source route.  Note that the IP address of the entry interface may not
be routable from the network cloud attached to the exit interface and
vice versa, e.g., think NAT.

    In contrast, in the (IPv6) Routing Extension Header, version 0,
    the addresses listed are "routing domain" or "cluster" addresses,
    not "interface" addresses.  AS the packet traverses the internet,
    the addresses are moved, but not changed -- "mutable but
    predictable".  However, one has in general given up the ability
    to specify "routers", and, when IPSec AH is used, the ability to
    do some forms of address translation.

I believe that the statement:

> This is a big mistake (IMHO), because source routes in IPv4 _can_ be
> predicted with the same reliability that the type 0 routing header in IPv6
> can.

is not correct.  To do so would require the end systems to second
guess how the internet routing system is going to route packets --
something that will be even harder to do when QOS routing becomes more
common.  Thus the statement:

> which had no negative followups

is consistent with the statement that the addresses in a IPv4 source
and record route option are mutable and not predictable.  In general,
IPSec AH cannot be used (for either IPv4 or the version 0 Routing
Extension Header) to authenticate that the route taken by an IP
datagram is the same as the path recorded in the source route.  With
IPSec AH, one is only assured, in the case of the version 0 Routing
Extension Header, that the receiver received what the sender expected
the receiver to receive; for IPv4 source routing, one cannot even
believe the addresses recorded in the source routing option, since the
sender could not, in general, predict them.  How much "trust" is one
willing to put into the intermediate systems and the routers that
interconnect them?

The only way that I see to make sure that a packet reached each of the
intermediate systems listed in a source route is if one has some sort
of shared secret with those systems and they are required to
demonstrate that they know that secret, and even then, one has to
trust the intermediate systems to keep the secret and do the correct
processing.  One way to do that is to use the version 0 Routing
Extension Header with the IPSec "mode" (transport or tunnel) which is
not described in the current IPSec documents; maybe we could call it
"Routing Header mode".  Routing Header mode places the IPSec extension
header(s) [either AH or ESP with authentication] between the IP header
and the Routing Extension Header (yes, I'm still talking about an IPv4
header -- as well as IPv6).  When placed in that position, there would
be a separate SA for each leg of the source route.  Note that Routing
Header mode has many of the properties of "transport mode": no extra
IP header is added, and it is implemented in security gateways.  We
have plenty of work to do in IPSecond.

> I've looked at our code and BSD, and they both do the predictable
> thing in their forwarding path.

NetBSD inserts the exit interface, as did SunOS (TM) and cisco (TM)
routers the last time I tried them.  So I guess you mean that in those
cases where you know the contents of the routing table in the
intermediate systems listed in the IPv4 source and record route
option, and how that system will route your particular packet, you can
predict what will end up in the option at the receiver.  Not a general
solution (or something I would want to burden AH with trying to figure
out :-).

Charlie