[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ipsec] VID for nat traversal
SafeNet's currently released VPN clients also use the -02 vendor ID.
Whenever this issue comes up, we send the below explanation to help ensure
interoperability...
Regards,
Bill
4.) NAT-T VID
Our version 8.0 client has support for draft -01:
draft-ietf-ipsec-nat-t-ike-01.txt
draft-ietf-ipsec-udp-encaps-01.txt
Field testing of draft -01 has proven that it only works with certain
NATdevices. Hence the move to draft 02 and 03. For backward compatibility
with products that implemented NAT-T-01, SoftRemote will continue to send
and accept the NAT-T-01 vendor ID:
SafeNet SoftRemote v9.0 supports:
draft-ietf-ipsec-nat-t-ike-02.txt ** same as -03 except for the Vendor
ID.
draft-ietf-ipsec-udp-encaps-03.txt
We strongly recommend implementing -02 / -03 instead of -01. As described
below the only difference between nat-t-ike-02 and nat-t-ike-03 is the value
of the vendor ID value. SafeNet's implementation is to send, and expect
receipt of, the nat-t-ike-02 vendor ID value.
Here are the minutes from the IETF meeting in which the situation was
discussed: http://www.vpnc.org/ietf-ipsec/mail-archive/msg04389.html
An excerpt from the minutes:
"Draft-03 versions submitted to update the author list and make some
clarifications. The draft-ietf-ipsec-nat-t-ike-03.txt did change the
Vendor-ID string to represent draft-03, although there are no changes that
would make it interoperably different from draft-02, except the vendor ID.
Vendors, which have implemented draft-02, should accept draft-02's vendor
ID. If recent implementation was done according to draft-03, send the vendor
ID for draft 02 as well to interoperate. Note however, the vendor ID string
in draft 02 was wrong for the hash value. Implementers should use the MD5
hash hex value, not the string to interoperate with
other implementations."
The actual -02 draft is hard to find on the internet. Below is the vendor
ID section from draft-ietf-ipsec-nat-t-ike-02.txt. As described above, make
sure the actual hex value is used.
"3.1. Detecting support of Nat-Traversal
The NAT-Traversal capability of the remote host is determined by an
exchange of vendor strings; in Phase 1 two first messages, the vendor id
payload for this specification of NAT-Traversal (MD5 hash of "draft-
ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e 086381b5 ec427b1f"]) MUST
be sent if supported (and it MUST be received by both sides) for the
NAT-Traversal probe to continue."
Bill Becker
Technology Manager
SafeNet, Inc.
4690 Millennium Drive
Belcamp, MD 21017
(443) 327-1335
bbecker@safenet-inc.com
www.safenet-inc.com
-----------------------------------------------
The information contained in this electronic mail transmission may be
privileged and confidential, and therefore, protected from disclosure. If
you have received this communication in error, please notify us immediately
by replying to this message and deleting it from your computer without
copying or disclosing it
-----Original Message-----
From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On Behalf Of
William Dixon
Sent: Tuesday, April 27, 2004 12:35 PM
To: 'Chris Stillson'; ipsec@ietf.org
Subject: RE: [Ipsec] VID for nat traversal
Chris, the earlier drafts provided the vendor ID being MD5 of the draft
name. If you support multiple versions, you include multiple vendor IDs.
From draft-ietf-ipsec-nat-t-ike-02.txt:
"the vendor id payload for this specification of NAT-Traversal (MD5 hash of
"draft-
ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e 086381b5 ec427b1f"])"
Windows NAT-T implementation so far uses draft-02 vendor ID. Here is the
Win2k & XP NAT-T update info.
http://support.microsoft.com/default.aspx?scid=kb;en-us;818043
> -----Original Message-----
> From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On
> Behalf Of Chris Stillson
> Sent: Tuesday, April 27, 2004 11:37 AM
> To: ipsec@ietf.org
> Subject: [Ipsec] VID for nat traversal
>
> Just wondering what different implementations use for the VID
> to signify an implementation supports nat-t (since there is
> no rfc # yet)
>
> By my calculations the md5 hash of "RFC XXXX" is
> 810fa565f8ab14369105d706fbd57279, which seems to make as much
> sense as anything at this point. But, other people may have a
> different solution which will make interoperability tricky :)
> So, before releasing anything to the public, I would like to
> get this issue sorted out.
>
>
> chris stillson
> IPSEC crypto monkey
> x82477
>
> Note: Preceding comments written by an engineer. There is
> nothing to read into them. He really has no hidden motives or agendas.
>
> 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right
> Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness
> 8.Right Concentration --Please inform author if he has
> forgotten about any of these
>
> _______________________________________________
> Ipsec mailing list
> Ipsec@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec
>
>
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec