[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification,etc.]
Here's my take on IPv6 options and extension headers vs. AH computation.
First, let's consider IPv6 options, i.e., those TLV things that are carried
in either the Hop-by-Hop Options header or the Destination Options header.
IPv6 options are designed to allow AH processing without understanding
the semantics of the option. For example, a new option may be defined
in the future, and an upper-layer protocol or application may request
(via the IPv6 API) transmission of a packet containing that new option
without requiring any change to the IPv6 (including AH) module in the
source node. The Type code of the option indicates to the AH implementation
whether or not the option data is mutable en-route. If it is mutable,
the data is treated as zeros for AH purposes, else the data is treated
verbatim.
An option whose data is mutable en-route but whose final value is
predictable must still be treated as zeros for AH purposes, because
even though the final value may be predictable by the entity that
requests transmission of the option (an upper-layer protocol or
application in the source node), it would not be predictable to
the (unmodified) AH implementation in the source node.
To allow special handling of the "mutable but predictable" case would
require a more elaborate IPv6 API in which both the original value and
the predicted final value of an option could be supplied by an application
or upper-layer protocol to the IPv6 (including AH) module. I don't think
the added flexibility would be worth the extra complexity in the API
and the extra documentation needed to explain this feature.
Therefore, I am in favor of leaving the current definition of the IPv6
option Type encoding as is.
Now let's consider IPv6 extension headers.
In order for an AH implementation to compute an authenticating value to
place in an AH header of a packet, the IPv6 module of which the AH
implementation is a part must understand the semantics of all headers
*preceding* the AH header. That is necessary in order to *find* the AH
header in the first place (or to decide where to put it, in the case of a
black-box AH-inserter). If, while parsing the headers preceding an
AH header, an IPv6 module encounters a Next Header value that it does
not understand:
(a) It cannot tell whether the identified next header is an
IPv6 extension header or something else. (E.g., it might
be an unrecognized transport protocol header or anything else
that can be identified by the IPv4/IPv6 Protocol/Next Header
numbering space.
(b) Even if it could tell that the next header were an IPv6
extension header, it could not necessarily tell how long that
header is or what the type of the subsequent header is. (It is
not required that all extension headers even have an explicit
length field, let alone a length field in the same location
and of the same granularity as in other extension headers,
nor is it required that every extension header have its Next
Header field at the same relative offset.)
(c) Even if it could tell the length and subsequent header type
of an unrecognized extension header, it could not necessarily
continue parsing after the header. (E.g., imagine an IPv6
module that could recognize the length and next-header field
of a Fragment header, but did not understand its semantics.
For any packet carrying a non-initial fragment, the stuff that
followed the Fragment header cannot be parsed as another
header.)
An AH implementation is not required to parse or recognize any headers
*following* the AH header in a packet -- everything following the AH header
must be treated as "payload" to be included in the AH computation as-is.
This implies that everything following an AH header is considered immutable,
which in turn implies that AH is incompatible with intermediate devices that
modify, say, transport-layer headers (like NAT boxes and TCP "helpers").
That's a feature, not a bug.
Since an IPv6 implementation processing an AH header must understand the
semantics of all headers that precede the AH header, any new extension
header designed to precede an AH header can include in its specification
whatever AH handling is desired. For example, the specification could
specify that certain parts of the header are:
- immutable and included as-is in the AH computation,
- mutable and treated as zero-valued for the AH computation, or
- mutable but with a predictable final value that is to be included
in the AH computation.
Determining whether or not a destination understands a new extension
header (whether it precedes or follows an AH header) is the originator's
problem, just like determining whether or not a destination understands
a new transport-layer header. A receiver that, in normal IPv6 processing,
encounters an unrecognized header sends an ICMP Unrecognized Header Type
message back to the source, which at least will explain to a source why
it is failing.
A device that inserts an AH header into a packet (as opposed to
encapsulating the packet as payload following an AH header) without the
knowledge and assistance of the source IPv6 module will presumably insert
the AH header immediately following all headers that it recognizes as not
being end-to-end (those being: a Hop-by-Hop Options header, any Routing
headers, and any Destination Options headers that precede any Routing
header). It would have no choice but to treat any unrecognized header as
end-to-end -- it might well be an unrecognized transport-layer header, for
example -- and would have to insert the AH header before the unrecognized
header, and therefore treat the entire unrecognized header and everything
following it as payload to be included in the AH computation. If such
devices become common, it will make it difficult to introduce new extension
headers that are not both end-to-end and immutable in transit. Though I
think such devices are ill-advised (tunnel mode AH ought to be used
instead), I don't think losing the ability to define new non-end-to-end
or mutable extension headers would be all that horrible. All of the desired
functionality ought to be achievable by the use of options rather than
new extension headers, with the exception of getting AH coverage of a
predictable final value of a mutable option.
In any case, and to conclude after that long-winded explanation, the part of
draft-ietf-ipsec-auth-header-05.txt that says:
>>> If the IPsec implementation encounters an
>>> extension header that it does not recognize, it MUST zero the whole
>>> header except for the Next Header and Hdr Ext Len fields.
does not make sense. At the source or destination of a packet, the presence
of an unrecognized extension header before an AH header will prevent the AH
processing from ever being invoked. In a black-box AH-inserter, any
unrecognized header would necessarily follow the inserted AH header, and
thus be treated as payload data and not zeroed.
Steve
Follow-Ups: