Re: Issue 35: Adding version number to MOBIKE_SUPPORTED

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

Tero Kivinen wrote:

>[email protected] writes:
>  
>
>>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...?
>>    
>>
>
>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. 
>  
>