question about draft-ietf-ipsec-nat-t-ike-07

[Tero Kivinen <kivinen@ssh.fi>]

latten@austin.ibm.com writes:
> In draft-ietf-ipsec-nat-t-ike-07.txt, section 3.1, there is mention
> of vendor ID payload to be passed in Phase 1, but it is not defined
> in the draft nor in rfc 2409.

The actual vendor ID value will be added when the final RFC number
of the document will be known, i.e it will be the MD5 hash of the text
"RFC XXXX", where the XXXX is the actual RFC number of the
draft-ietf-ipsec-nat-t-ike-07.txt document. 

> I found mention of it in the draft for ikev2, and just want to be
> sure that the VID payload mentioned in this ikev2 draft is the same
> one to be passed in Phase 1 for ikev1 for NAT-T.

IKEv2 protocol does NOT have vendor ID for the NAT-T. The vendor ID is
needed in the IKEv1 to see if the other end supports NAT detection
payloads. In the IKEv2 this is not needed, as the NAT detection
payloads are notifications, and all IKEv2 implementations MUST ignore
unknown status notifications.

> A while back someone asked about the IPR claim for draft-ietf-ipsec-nat-t-ike
> and draft-ietf-ipsec-udp-encaps, because they were interested in
> implementing.  I was wondering if there was any new info on this claim
> or exactly what pieces of the technology are being claimed.
> See http://www.ietf.org/ietf/IPR/MICROSOFT-NAT-Traversal.txt

I haven't received any more information about that even when I tried
to ask from Microsoft. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/