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

From: [email-masked]
Date: Wed, 29 Oct 2003 13:53:44 -0600

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. 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.

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

Regards,
Joy

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Oct 2003 10:55:34 +0200

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

> 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. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 30 Oct 2003 09:59:40 -0800

> draft-ietf-ipsec-nat-t-ike-07.txt document.

In other words, until this is published as an RFC there can be no 
interoperable implementations. This wouldn't be a problem if it didn't 
take so long for something to go from a draft to an RFC. As it is, a 
number of vendors have implemented something (they had to ship 
eventually) based on these drafts and used different vendor id codes. 
The result is implementations that would probably interoperate just 
fine if only they used the same vendor id codes.

-josh

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 31 Oct 2003 01:55:21 +0200

> interoperable implementations. This wouldn't be a problem if it didn't 

Yep. 

> eventually) based on these drafts and used different vendor id codes. 

Most of the vendors who have shipped NAT-T have been using the vendor
ID's from the previous draft WITH the numbers from the previous draft.
Those drafts used numbers from the private use space, thus along with
the vendor IDs in the drafts they can interoperate. There have been
couple of different vendor ID codes and different numbers and little
bit different protocol for each of them.

Draft-ietf-ipsec-nat-t-ike-04 tells also those previous vendor IDs and
numbers, but that was removed after that, as the protocol was actually
changed a bit thus implementations need more changes than simply
change of numbers and vendor IDs. 

> fine if only they used the same vendor id codes.

The reason there is no vendor ID code is to make sure that nobody will
implement the protocol using the IANA allocated numbers (or what is
the proposal for the IANA to allocate those numbers, as those numbers
are not yet allocated, in theory they could still change), i.e the
numbers not from the private use space.

The drafts are now on the IETF Last Call, so hopefully they will go
forward to RFC soon.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Tom Hu <[email-masked]>
Date: Thu, 30 Oct 2003 16:45:18 -0800

> unknown status notifications.

Question about NAT-T with v2. I read v2 RFC, my impression it does not allow to
send or process notification message until the peer is authenticated. It also means
that we only can send or process Notify message after 4th messages. It seems we
should send NAT-D in msg #1 and #2, is it against ikev2 protocol? Or we have some
selection of Notification message can allow before 4th message?

Tom

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 31 Oct 2003 12:29:58 +0200

Tom Hu writes:
> Question about NAT-T with v2. I read v2 RFC, my impression it does
> not allow to send or process notification message until the peer is
> authenticated.

I haven't found out any such restriction in the draft. It says that
status notifications can be added to any packet. Also those
notifications in the IKE_SA_INIT packets are also authenticated as the
packets are included in the AUTH hash. 

> It also means that we only can send or process Notify
> message after 4th messages. It seems we should send NAT-D in msg #1
> and #2, is it against ikev2 protocol?

The IKEv2 NAT-T clearly says that those NAT_DETECTION_*_IP
notifications are included in the IKE_SA_INIT exchange. 

> Or we have some selection of Notification message can allow before
> 4th message?

---

From: Tom Hu <[email-masked]>
Date: Fri, 31 Oct 2003 10:23:15 -0800

> packets are included in the AUTH hash.

Please see this paragraph in 11.txt

1.4 The INFORMATIONAL Exchange

   At various points during the operation of an IKE_SA, peers may desire
   to convey control messages to each other regarding errors or
   notifications of certain events. To accomplish this IKE defines an
   INFORMATIONAL exchange.  INFORMATIONAL exchanges MAY ONLY occur after
   the initial exchanges and are cryptographically protected with the
   negotiated keys.

Here initial exchange includes 1 to 4 messages.
And by the way, IKE_SA_INIT message does not have AUTH payload. AUTH
payload is sending at #3 and #4 messages.