[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AH/ESP & Replay Protection
First, a question to the list manager. Has somebody modified the list to
include "Reply-To: ipsec@ans.net" in the header? It seems to have appeared
recently, and is arguably broken.
>One of the problems is figuring out what the effective protections were
>on the data, passing that information to the policy engine, and informing
>the application of what protections it got. Also, there is kernel bloat
>and increased per-packet processing cost as compared with a more integrated
>solution.
I've not completely built the mechanisms to do this in my own code,
but I have started. Basically, the internal representation of each
incoming packet carries three "out-of-band" tags: a pointer to the
interface it came in on, a binary flag indicating whether the packet
was received as a link-level broadcast (to stop broadcast storms), and
the 32-bit SPI of any security transform providing authentication. All
this information is available to upper-level policy mechanisms,
including transport protocols (like TCP, which may wish to ignore
physical layer broadcasts), the IP routing code (e.g., which may wish
to route only authenticated packets from certain interfaces, but route
all packets from another), and to applications (which may use AH in
lieu of their own authentication mechanisms).
When the packet first comes in, of course, the out-of-band SPI field
is null. If the packet contains AH, normal transport protocol demuxing
passes it to the AH module which strips it off and adjusts the length
and protocol fields in the IP header. If the authentication fails, the
packet is tossed. If the authentication passes, the AH module sets the
SPI tag and puts the reconstructed packet, now minus its
authentication header, back into the "hopper" where it is processed
again by the transport demux code to handle the next transport
header. This time, the out-of-band SPI field is available to drive
routing, transport and application policy decisions as desired.
Since there is only room for one SPI tag per packet, wrapping one AH
header inside another is not too meaningful. In that case I think I
overwrite the SPI tag set from the outer AH with the SPI from the
inner AH header. Both AH headers have to pass, but the packet carries
only the privileges from the inner AH. I don't see this as much of a
problem since it's hard to conceive of a real use for nested AH-AH to
the same destination, as opposed to two AHs to different destinations
(e.g., one to a firewall and another to an end system.) In this latter
case, there's an IP header between the two AHs.
>If you're concerned about complexity, I'd suggest removing the support
>for confidentiality without strong integrity (once better transforms
>appear) since that is known to be vulnerable to active attacks described
>in past IPsec meetings. Talk of "SHA" or "shortened MD5" or other
Well, since we've made that mandatory (32-bit IV single key DES) we'd
have to change that. Actually, this is the mode I use most often since
I'm concerned mainly about passive, NSA-style vacuum-cleaner
monitoring. But you're right, I'd be better off including some real
authentication, especially when I can afford the bandwidth.
Phil
References: