Some comments on draft-tschofenig-v6ops-secure-tunnels

[Eric Vyncke <evyncke@cisco.com>]

Just had a quick look this morning after the WG meeting on this document.

Some hopefully useful comments:

1) section 2.2, should be augmented because tunnel mode prevents the use of multicast (and more generally routing protocols -- cfr Joe Touch's I-D for IPv4) while transport mode does

2) section 2.2, IPsec will detect indirectly if the outer IPv4 addresses are wrong (spoofing among sites) because the decapsulation will fail since the crypto keys (for ESP and for AH) are based on <remote IPv4 address,SPI>

3) section 8, NAT-T for IKEv1 is actually a RFC and not an I-D, RFC 3948

4) section 11, security considerations, the obvious should perhaps be stated? Like DoS on the IPsec endpoint by flooding it with packets with the right SPI to force CPU intensive IPsec crypto operations. Or packet drop by a party along the tunnel path, ...

5) another use case scenario can be (and actually I've seen it deployed): using this IPsec protected IPv6 tunnel as a back-up link of a 'real native' IPv6 link in order to provide resiliency. This of course requires routing protocols hence the use of the 'transport mode' variant.

If required, I'll be ready to provide some text for the above points if the authors want.

Hope this helps to finalize this useful I-D

-eric