Re: Issue 35: Adding version number to MOBIKE_SUPPORTED

Jari Arkko writes:
> (a) Some functional deficiency of the N(feature) scheme
>      that is corrected in the scheme that you proposed?

I do not want to see multiple different notifications each negotiating
something small in the IKEv2. 

> (b) Waste of bits, N(featurevers1)+N(featurevers2) is
>       bigger than N(feature)+bits?

Yes, as for version 11 (current IKEv1 NAT-T (stenberg, huttunen,
nat-t-ike version 01-08, RFC version) it will be N(feature)+bits,
compared to the N(version1) + N(version2) + N(version3) + N(version4)
+ N(version5) + N(version6) + N(version7) + N(version8) + N(version9)
+ N(version10) + N(version11).

There is already lots of concerns in the IESG that the IKEv2 packets
will be too big, and there will be UDP fragmentation which will cause
IKEv2 to break. It is especially important to keep the FIRST
IKE_SA_INIT packet as small as possible to prevent fragmentation, as
it is required for stateless operations when under attack.

I mean if you are using stateless cookies of IKEv2 because you are
under attack, you do not want to do reassembly of the IKEv2 packets
before you can see the cookie, thus the first IKEv2 packet
(IKE_SA_INIT) should not be fragmented. For the bit D-H group we are
already quite close to the fragmentation limit, and I do not want to
add 8*11 bytes to that packet, when I can go with 12 bytes...

> (c) Headache when you look at IKEv2 packets in
>       Ethereal?

That too :-)

It is ugly to add new notification for each version, as it makes it so
that you cannot ever get rid of those notifications. I mean I am
pretty much sure we cannot get ever rid of the very early IKEv1 NAT-T
draft compatibility code, as there is still our old implementations
out there using those so they will be there for ever (or until we
switch to IKEv2). I do not want the same thing happening to IKEv2,
when we can avoid it with version number of the extension.

It is good practice to make sure there is version numbers in the
protocol, and well tought plan how to do extensions to the protocol
(i.e. suitable reserved bits, or at least make sure there can be new
data added later).

What is the reason NOT to add the version number? Saving 4 bytes now,
but wasting lot later? (or saving paragraph or two describing how
version number and extensions work together, i.e. say that all later
versions much include all features of the older ones, and newer
versions should not use the features other peer does not unrestand).
-- 
[email protected]