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

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

Eric,

Thanks for your comments.

> 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
>
A tunnel mode SA can carry multicast traffic between two end points. Just define the SPD to contain multicast addresses.
I agree that we have to point out the issues mentioned in Joe Touch's draft somewhere..

> 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>
>
SPI alone is sufficient looking up the SA for unicast traffic and this is how it is defined in the recent AH/ESP drafts.

> 3) section 8, NAT-T for IKEv1 is actually a RFC and not an I-D, RFC 3948
>
Ok, will fix it.

> 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, ...
>
Perhaps we can add that..

> 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.
>
I don't know whether it is relevant to the current document or not. I will let Pekka answer this.

-mohan

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