RE: IKEv2 transport concerns

[Black_David@emc.com]

Michael,

> Black> The goal here is that any use of IKEv2 to negotiate a tunnel-mode
SA
> Black> (or UDP-encapsulated tunnel-mode SA for NAT traversal) carry an
implied
> Black> promise that ECN will be supported and handled correctly for that
> Black> tunnel.  This avoids any need for IKEv2 to negotiate/report/etc.
> Black> ECN handling, in contrast to IKEv1 where a negotiable SA attribute
> 
>   David, while I understand what you are trying to do, you are assuming
that
> IKEv2 can only be deployed with an entirely new system. IKEv2 is a trivial
> upgrade of system software (perhaps a "Service Pack"), while the upgrade
to
> the IPsec portions may in fact require changes to hardware.

I wouldn't agree with "entirely new system" - if the ECN handling logic
can be upgraded as part of the IKEv1 -> IKEv2 upgrade, everything's ok,
although the upgrade is more complicated (e.g., may have to patch in
a driver/stack change).

How much hardware is there out there that can't cope with handling ECN
correctly via an upgrade?  Unless the answer is "a whole lot", the right
thing to do may still be to require correct handling of ECN in IKEv2 and
leave that hardware at IKEv1.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------