[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Death to AH (was Re: SA identification)
>> so i guess "death to AH" and "ipsec is for VPN only" are
>> related.
>As others have pointed out, this relationship is weak at best.
>In particular, any IPsec implementation should include policy checks
>after ESP decapsulation which not only verify that the IP headers
>haven't been tampered during transit, but also that they were correct
>to begin with..
the verification will be able to cover only IP source/destination
address and protocol number only. am I correct?
>> it is correct that there are certain extension headers that does not
>> need protection, however, there are certain application that needs
>> AH (especially with transport mode). as increasing number of protocol
>> documents are relying upon the existence of ESP and AH (like most of
>> IPv6 routing protocols)
>Could you give pointers? (i don't follow the routing area closely).
here are a (probably incomplete) list of protocols that says "use
IPsec to secure traffic". in IPv4 they provided upper-layer mechanism
to secure the protocol, and now they do not provide upper-layer
mechanism for IPv6 because they rely upon IPsec
though I need to diagnose each of them further, my take is that
for routing protocols we prefer transport mode AH than ESP.
- mobile-ip6
a lot of extension headers need protection, we do not really
want encryption for most of these
- RIPng (RFC2080)
explicitly refers AH and ESP
- OSPFv3 (RFC2740)
explicitly refers AH and ESP
- IPv6 router renumbering (RFC2894)
tries to protect site-local multicast by IPsec!
- IPv6 tunnel broker (RFC3053)
itojun
Follow-Ups:
References: