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

Re: IPv6 Destination options extension header position.

Dan,

Thanks for your feedback on the issue of placement of the Destination
Options header.  The position before the Routing Header was omitted, I
feel to reduce distractions.  However, it has instead pointed out the
need for an explanation of the rationale that resulted in the
original diagram.

The requirements stated in RFC 1883 Section "4.1  Extension Header Order",
i.e.,

  "IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header which is restricted to
   appear immediately after an IPv6 header only.  Nonetheless, it is
   strongly advised that sources of IPv6 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation."

Thus the recommendation that the Destination Options header appear in
only two places (before the Routing Header and before the upper-layer
header) is to be used until a subsequent specifications revises that
recommendation.  That is what the AH/ESP drafts were trying to reflect.

The extension headers are processed in the order that they appear.
Extension headers are generally orthogonal, except, potentially, in
the case of the Destination Options (and Hop-by-Hop Options)
header(s).

As an example not related to IPSec, a destination option is being
defined that will divorce the IP addresses in the IP header from the
tokens used to perform demultiplexing at the transport layer.  This
has utility, e.g., to preserve a long duration connection when a
system's addresses are dynamically changed.  It may also be used to
support migratory processes, etc.

A similar argument may be made for the IPSec headers, as they, too,
have bound (user/application) security to IP addresses.  Consider a
destination option that has the semantics of "change the source and
destination IP addresses, for all subsequent processing, to SRC and
DST.  Use this option before an AH/ESP header would effectively change
the SA that is referenced by the SPI, since an SA is identified by the
triple <destination IP address, SPI, Security Protocol (AH, ESP, ...)>.

The placement of the Destination Options header carrying this option
cannot be after the AH/ESP header (as that would lead to use of the
wrong SA and (if the secrets are any good) the discard of the packet).
One wouldn't want it before the Routing Header, as there is no need
for it to be processed at each hop in the source route (in addition to
potentially causing mis-delivery of the packet).

This functionality may be useful in the context of multihomed hosts
(that do not forward packets), migratory processes, redundant servers,
evolution of the routing system, or, as was mentioned on one of the
mailing lists recently, for use with NAT boxes that change between IP
header versions 4 and 6, and IP addresses.

I feel we should remind folks that things keep evolving, and some of
the directions that that evolution might be taken, so that they don't
unnecessarily constrain their implementations (short cuts) in ways
that might prove to be a burden to the whole system later on.  The
bottom line for implementors is to be aware that not everything has
been invented yet.  It should have little real impact on systems that
do not implement such an option. So how much space should we devote in
the specs for it?  Do you think it should be mentioned at all?

We should certainly consider the security implications of such an
option, but given that changing the option presents the same level of
difficulty of attack to an adversary as, e.g., changing the IP
destination address itself (or any bit that is protected by an
integrity mechanism), I suspect that it would not introduce
disproportional vulnerabilities.

Consequently, I think that the "right diagram" would be something like:

+------------+-------------------+---------------------+------+-----+------+
| Orig IP v4 | hop-by-hop, dest, | some combination of | dest |     |      |
| or v6 hdr  |   routing, frag.  | dest opt*, AH, ESP  | opt* | TCP | Data |
+------------+-------------------+---------------------+------+-----+------+
|<------------- authenticated by AH except for mutable fields ------------>|

                * = if present, could be before AH, after AH, or both

To borrow your text, the above replacement text better illustrates
(IMHO) AH placement in an IP datagram than does the current text.

Charlie