AH is pretty useless and perhaps should be deprecated

Steven Bellovin smb at cs.columbia.edu
Tue Nov 17 02:34:49 UTC 2009

On Nov 16, 2009, at 9:07 PM, James Hess wrote:

> On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn <kohn.jack at gmail.com> wrote:
>> However, i still dont understand why AH would be preferred over
>> ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying
>> the OSPF packets. One could also do these things with AH.
>> Am i missing something?
> Neither protects against replay without additional measures.
> However,  AH  is very close...   consider using  AH-authenticated
> packets with the timestamp option   and  clock synchronization between
> peers.
> Discard packets arriving that are more than 5 minutes old.
> In transport mode for security between LAN peers, ESP NULL  verifies
> the integrity of only the data  payload in the packet.  AH  secures
> the header,  the IP header fields and options.
> Therefore changing the timestamp to replay would  be detected.
> This evil act would not be detected if you are using ESP NULL,  the
> attacker can potentially replay this packet, while the SPI is still
> good, and you'll never know.
> One of AH's  most visible disadvantages (cannot be used with NAT) is a
> side-effect of the increased security coverage it provides.  Many IPv4
> networks  require NAT,  making  AH  impractical.
> However,  matters  could change for  IPv6  networks  with  high
> security requirements,   that need to validate authenticity of more
> than just packet contents...
Except for multicast packets -- the case of interest for OSPFv3, and even there the spec arguably got it wrong -- you can check the source IP address against the SPD.  That is, you can't replay my ESP packets in a unicast connection with a different source address because packets from your source address on my SPI will be rejected.

ESP does have antireplay protection; admittedly, that's disabled if manual keying is used, but generally speaking, manual keying shouldn't be used, per RFC 4107.

The interesting case is multicast.  4552 seems to assume symmetric keys, but that's a bad idea; it lets other members of the authorized group impersonate each other.  What you really want is digitally signed packets, where each source has a key.  I don't think that the IETF's multicast key management protocols are quite up to the job, though; they focus on single source multicast, which isn't what OSPF needs.  (That said, 5374 seems to point in the proper direction, but I haven't been following this work.)  It may be that the proper answer for OSPFv3 is its own strong multicast security.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

More information about the NANOG mailing list