Hi.
I worked on this problem on Apple's implementation of NAT-T for KAME
stack, here are comments based on my work:
On Tue, Apr 27, 2004 at 11:41:34PM +0200, Joern Sierwald wrote:
> overview:
>
> -00
[...]
>
> -01
>
> editorial changes to -00
> VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-00" - ["4485152d 18b6bbcd
> 0be8a846 9579ddcc"] (sic!)
First version, with two matching hashes.
> -02
>
> floats to port 4500
> one OA payload
> NAT-D 130, NAT-OA 131, UDP-Tunnel 61443, UDP-Transport 61443
> VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e
> 086381b5 ec427b1f"]
>
> -03
>
> same as -02, repost, VID changes.
> VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-03" - ["7d9419a6 5310ca6f
> 2c179d92 15529d56"]
Second version, also with two matching hashes....
> -04
[....]
>
> -05
[....]
>
> -06, -07, -08
>
> I have read them and found only editorial changes.
Third version (well, version 04 is not exactly the same, but I guess
an implementation of this version should work with an implementation
of 05-08 versions...), with hashes problems.....
> Your plan
> >1)"draft-ietf-ipsec-nat-t-ike-02" -
> >["90cb8091 3ebb696e 086381b5 ec427b1f"])"
> can't work, as draft -02 is not compatible with drafts -04 and higher at
> all.
> Assuming you implement the -08.
It is necessary to know which ones of the three "major versions" are
implemented, and to use only the corresponding Vid hashes.
If an implementation only support 05-08 drafts, it MUST NOT
send/matches Vids for older drafts !!!
> >md5("draft-ietf-ipsec-nat-t-ike-08")
> will be a problem after 10 July 2004 when -09 will be released, as a repost.
> Then people with md5("draft-ietf-ipsec-nat-t-ike-09") won't interoperate
> with your
> md5("draft-ietf-ipsec-nat-t-ike-08")
They may:
On my modified racoon, I added all hashes of versions which are
supported, including olders.
Let's says my modified racoon (patches avaiable on kame's mailing
list, if someone is interested....), which supports all drafts (so
from 00 to 08 today) negociates with an implementation which
implemented draft 07.
As an responder, racoon will match
md5("draft-ietf-ipsec-nat-t-ike-07"), will "know" that hash refers to
the "third major implementation", will send back the same VId, and
everything will work ok.
As an initiator, racoon will send all NATT VIds it has (so from
md5("draft-ietf-ipsec-nat-t-ike-00") to
md5("draft-ietf-ipsec-nat-t-ike-08"), and also
md5("draft-ietf-ipsec-nat-t-ike")).
The remote IKE daemon will match md5("draft-ietf-ipsec-nat-t-ike-07"),
will just discard others unknown VIds, will send the same hash, and it
will work.
So if another implementation is released tomorrow which support draft
09, it "just" has to also know Vids for drafts 04-08 (older drafts is
another problem)....
The only remaining problem is when both initiator and responder
supports various drafts. My solution was to send the latest one first,
and to select the first received if more than one matches....
> md5("draft-ietf-ipsec-nat-t-ike-05") seems practical to me, but not "good".
> I will include that in our product anyway. I still hate myself for the
> ".txt" incident.
> For the record, that'd be 80d0bb3def54565ee84645d4c85ce3ee
Is that '.txt' version released in a "public" version ?
(Well, my real question is: shall we add this VId to other products,
for compatibility reasons ?)
> md5("RFC NATT"). I like that one. or md5("RFC NAT-T"). or
> md5("draft-ietf-ipsec-nat-t-ike").
> Will be a big problem if somebody DOES change the draft again, obviously.
Yes.... I wasn't sure to use md5("draft-ietf-ipsec-nat-t-ike"), I must
have found it in another implementation (but I don't remember which
one !).
md5("RFC XXXX") would also be a big problem if another extension uses
the same VId mechanism to negociate and comes to the same statement of
"waiting for an RFC number".....
Regards,
VANHULLEBUS Yvan.
Attachment:
smime.p7s
Description: application/pkcs7-signature