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?
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