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