[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit
At 09:34 19/06/00 , Paul Koning wrote:
>I believe you missed the point of the proposal.
>
>The discussion on AH has been around transport mode.
There seem to be several discussions. Note that, like many,
I'm not on the IPsec list, but am on the OSPF and IS-IS lists.
>I haven't seen
>any argument at all that touches on AH in tunnel mode. After all, the
>arguments (IP options, authenticating IP header content) don't apply
>to communication between security gateways.
The whole "tunnel-mode" vs "transport-mode" distinction is partly
artificial, at least in IPng Land and arguably in IPv4-land as well.
If one applies "transport-mode" to an IP packet containing
IP-in-IP or Ethernet-in-IP, the result is approximately the same
as "tunnel-mode". The primary difference is in the {esp,ah}_input()
code where at tunnel decapsulation time, the inner IP header values
need to be validated against the configured tunnel properties.
This security check should apply to *any* IP-in-IP tunnel, not just
a tunnel with ESP or AH.
>So the point is this: currently there are some cases where people feel
>they want to use AH in transport mode, the reason for AH being that
>there supposedly are headers or options that require strong integrity.
>
>Clearly, you get the same integrity -- or rather, more of it and more
>easily -- by wrapping the to-be-protected packet in an IPsec tunnel.
Actually this is not the case. The point is that the integrity
is needed for the options and headers that are *actually used* along
the forwarding path (e.g. Source Routing headers/options). Any
option or header inside a tunnel is NOT (by definition) used
along the forwarding path, so ESP can never protect the IP-layer
headers/options.
>Since the fields requiring protection are at that point in the INNER
>header, not the outer header, they are indeed protected if ESP is
>used.
One goal of AH (and difference from ESP) is to protect the fields
at the IP-layer (headers or options) that are *actually used* while
the packet is transiting the network. ESP cannot protect these
headers in any case whatsoever.
Again, the primary current users of AH are NOT building VPNs of
any sort. They are using AH to provide integrity protection
for routing protocols or similar information that does not need
confidentiality, but does need strong authentication/integrity.
The other primary current AH users are IPv6 users relying on end-to-end
(i.e. host to host, no security gateway whatsoever) integrity.
All IPv6 hosts have ESP and AH implemented (most using danmcd's
BSD Sockets API extensions or similar), so the IPv6 world is
substantially different from IPv4 (where few host currently ship
with ESP or AH or even a proprietary security schema).
Regards,
Ran
rja@inet.org
References: