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

Re: IKE v2 Requirements and backwards compatibility



At 6:03 PM -0800 12/17/01, Scott Fanning wrote:
>Unless IKEv2 is a subset of IKEv1 which would simplify things, but that seem
>not to be the approach of the WG.

Right. If you leave the version number the same, and SOI 
implementation implement a subset of IKEv1, then an SOI 
implementation and a IKEv1 implementation won't be able to interact 
well. The IKEv1 implementation will offer lots of things that the SOI 
implementation will not understand.

To make a simplification, you need to signal to the old 
implementation "I'm doing something you don't expect". Version 
numbers are a good way to do that.

This debate rages in many areas of the IETF, particularly the 
applications area. The two camps have the following basic features.

Same port, different version number:
- Works better through firewalls because no new port needs to be opened up
- Faster migration because the admin of an older version sees an 
increasing error log entries over time for attempts to negotiate 
using the new version and feels bad about it

Different port:
- Cleaner, particularly if you can't be sure that older versions will 
fail gracefully when seeing the initial message in a new version on 
the old port
- No extra round trip for falling back to the old version in 
dual-version systems

In the case of revising IKEv1, I think that the "same port, different 
version number" model works well. SOI implementors should have 
initiators keep a cache of responders known to not use the higher 
version, and should put a reasonable TTL on the cache so that when 
the responder upgrades, the initiator will try the new version in a 
reasonable time.

--Paul Hoffman, Director
--VPN Consortium


References: