On Nov 16, 2009, at 9:07 PM, James Hess wrote:
> On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn <kohn.j...@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
