[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Deprecation of AH header from the IPSEC tool kit]

-- BEGIN included message

I only have experience with RIPV2, but have to argue with a point or
two. In particular, I don't see why AH would be preferred over ESP(AH).
I *do* however see why IPSEC would be preferred over RIPV2's
authentication.

"Waters, Stephen" wrote:

> >From reading the various, associated methods of securing ISIS, OSPF and
> RIPV2 messages, it seems to me that AH is perfect for the protection of
> these protocols.
> 
> The current HMAC-MD5 options have the following exposures that are solved
> with AH:
> 
> 1) no source address authentication (IP header authentication in general)

IPSEC+ESP(AH) would protect the UDP header of RIPV2, so the UDP checksum
would provide some limited protection of the source address.

> 2) poor/no replay protection

Agreed, but ESP(AH) would handle this too.

> 3) manual keys - which restricts key length and complexity to
> human-manageable keys, and makes for difficult key change procedures.

Agreed, but ditto for ESP(AH). (On the other hand, trying to use IPSEC
phase 1 and 2 before the routers can communicate could lead to a
chicken-egg situation. I think that this might have been a motivation
for the original built-in authentication scheme.)

> IPSEC+AH would seem to be a good choice for all control traffic exchange
> between routers. If this exchange is confidential, the ESP could be used as
> well.

RIPV2 is multicast, and AFAIK IPSEC hasn't addressed keying of multicast
sessions.

-- END included message

Follow-Ups: