-------------------- Tero Kivinen (2005-07-12): > 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? -------------------- Pasi Eronen (2005-07-14): 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...? -------------------- Jari Arkko (2005-07-14): I agree. -------------------- Tero Kivinen (2005-07-14): 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. -------------------- Jari Arkko (2005-07-14): 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? -------------------- Tero Kivinen (2005-07-14): > (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). -------------------- Pasi Eronen (2005-07-14): I think it's more likely that we'll have extensions that are (to some degree) independent of each other, and don't follow a nice linear progression where each new version includes all features from the older ones. If that happens, adding a version number will waste bytes instead of saving them. (But predicting the future is of course difficult, so it might be so that we'll have linear versions instead. Or we might not have many versions at all.) If we really want to keep this option open, we could of course say that "hosts implementing this version don't send any data in the notification, but ignore any data they receive". -------------------- Jari Arkko (2005-08-15): Issue 35: Version numbers -- the proposal that we came up with in the meeting was that if we move the mobike-supported negotiation to the second pair of messages (see issue 37), then the length of the messages is not such an issue. As a result, we can use plain payload without a version number. -------------------- Tero Kivinen (2005-08-23): The issue 37 will solve this problem, so we can close that if issue 37 decides to move notifications to IKE_AUTH message. --------------------