[119375] in North American Network Operators' Group
Re: AH is pretty useless and perhaps should be deprecated
daemon@ATHENA.MIT.EDU (Steven Bellovin)
Mon Nov 16 21:35:24 2009
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <6eb799ab0911161807v152f964cre87fc28943bb07b@mail.gmail.com>
Date: Mon, 16 Nov 2009 21:34:49 -0500
To: James Hess <mysidia@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Nov 16, 2009, at 9:07 PM, James Hess wrote:
> On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn <kohn.jack@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?
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
>=20
> 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.
>=20
> However, matters could change for IPv6 networks with high
> security requirements, that need to validate authenticity of more
> than just packet contents...
>=20
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
