Subject: [Mobike] Issue 35: Adding version number to MOBIKE_SUPPORTED

From: <[email-masked]>
Date: Thu, 14 Jul 2005 10:23:10 +0300

Tero Kivinen wrote:
>> 3.  Payload formats
>> 
>> 3.1  MOBIKE_SUPPORTED notification payload
>> 
>>    The MOBIKE_SUPPORTED notification payload is included in
>>    the IKE_SA_INIT messages to indicate that the
>>    implementation supports this specification.  >>
>> 
>>    The Notify Message Type for MOBIKE_SUPPORTED is
>>    TBD-BY-IANA (16396..40959).  The Protocol ID field is set
>>    to one (1), and SPI Size is set to zero.  There is no data
>>    associated with this Notify type.
> 
> How about adding 32 bits of data, with the MOBIKE version 
> number, initially 0?

If someone later creates a version of MOBIKE with more
functionality (or something), we could always negotiate the
support for it the same way we do now (add a new notification
payload).  I don't quite see what would be the advantage
of creating a separate negotiation mechanism just for MOBIKE...?

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Jul 2005 10:46:47 +0300

I agree. --Jari

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Jul 2005 11:51:03 +0300

> of creating a separate negotiation mechanism just for MOBIKE...?

Because I do not want to see:

      HDR, SAi1, KEi, Ni,
           N(MOBIKE_SUPPORTED),
	   N(MOBIKE_SUPPORTED_VER01),
	   N(MOBIKE_SUPPORTED_VER02),
	   N(FOO_SUPPORTED_VER00),
	   N(BAR_SUPPORTED),
           [N(NAT_DETECTION_*)]  -->

etc....

Like you already see in IKEv1 NAT-T. Implementations send out lots of
different vendor IDs.

I think our current implementation sends 5 different NAT-T IKEv1
vendor ids:

md5(draft-stenberg-ipsec-nat-traversal-02)
md5(draft-huttunen-ipsec-esp-in-udp-00.txt)
md5(draft-ietf-ipsec-nat-t-ike-02)
md5(draft-ietf-ipsec-nat-t-ike-03)
md5(RFC 3947)

and there is even some vendors sending out vendor id's for
md5(draft-ietf-ipsec-nat-t-ike-0{4,5,6,7,8}) even when those documents
didn't have the vendor ID defined, so nobody would ever implement
them.

I really do not want to that happen to MOBIKE too. Adding 4 bytes of
version number to the payload is quite easy way to fix that. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Jul 2005 11:56:03 +0300

Tero,

Let me try to understand your worry better. Are you
worried about

(a) Some functional deficiency of the N(feature) scheme
     that is corrected in the scheme that you proposed?
(b) Waste of bits, N(featurevers1)+N(featurevers2) is
      bigger than N(feature)+bits?
(c) Headache when you look at IKEv2 packets in
      Ethereal?

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Jul 2005 13:46:20 +0300

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

>       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

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-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike