Negotiation of NAT-Traversal in the IKE
draft-ietf-ipsec-nat-t-ike-08

[Ballot comment]
> Take the common case of the initiator behind the NAT. The initiator must
> quickly change to 4500 once the NAT has been detected to minimize the

s/4500/port 4500/


> If there is a NAT box between normal tunnel or transport encapsulations
> may not work and in that case UDP-Encapsulation SHOULD be used.

hard to parse.

[Ballot discuss]
> 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 "RFC XXXX"
> - ["XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX"]) MUST be sent if supported
> (and it MUST be received by both sides) for the NAT-Traversal probe to
> continue.

We have to do this with vendor IDs? I could understand using vendor
IDs if this was for backwards compatability, but the above indicates a
new has value gets defined (including the RFC number). Can't we do the
negotiation using more standards mechanisms?

> Once port change has occurred, if a packet is received on 500, that
> packet is old. If the packet is an informational, it MAY be processed if
> local policy allows. If the packet is a main mode or aggressive mode
> packet, it SHOULD be discarded.

Is an informational one that starts the negotiation? If so, it should
be a SHOULD/MUST, since the initiater might reboot and lose all
state. Bottom line, please assure me that if the initiator reboots, and
restarts the IKE exchange, the right thing happens (i.e, the responder
doesn't drop the packets as describe above).

[Ballot discuss]
This document does not contain a reference to RFC3424. It should do so, and it should explicitly address the five concerns raised in RFC3424 Section 4. For a good example, see Section 14 of RFC3489. I would also recommend reading the NAT taxonomy in RFC3489 Section 5, and identifying which sorts of NATs this mechanism will accommodate, and whether or not different behavior is required for different types of NATs (there is a little of that already, but more would be nice).

This document seems to address only the case where one of the IKE endpoints is behind a NAT (and the other is apparently in public address space), since initial reachability is just assumed. Little considerations seems to be given of cases where both are behind a NAT - the most material case for common peer-to-peer applications on the net today, and the most difficult to solve. While I don't expect the authors to take on that problem, the draft should at least identify (in Section 1, I'd imagine) that this is its scope.

There's more that could be said here (along the lines of Ted's comment), but I'll leave it at that.

[Ballot comment]
Needs a little language wash. Examples:
3.2 "and the one of the other NAT-D payloads must match"
    "as defined in the [Hutt03]"
7 "There are cases where NAT box decides to remove mappings"

The RFC Editor can do that, I think.

[Ballot comment]
There are a lot of design assumptions about the number and type of NATs in the
path between the two ipsec speakers buried in this text.  I can see the strong
desire people have to work around both the common case and more especially
the frustrating "helpful" ipsec-aware NAT.  This kind of NAT discovery is full of
pitfalls, though, and it ends up being an arms-race.  I won't stand in the
way of folks wanting to add this to their arsenal, but I fundamentally think
this is the wrong approach--and "helpfulness" is only going to kick you again
when you have this deployed.  (I already have nightmares about "helpful" NATs
pretending to be STUN servers out on the network, and this is probably going
to add a twist to those...)

[Ballot comment]
>> 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 "RFC XXXX"
>> - ["XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX"]) MUST be sent if supported
>> (and it MUST be received by both sides) for the NAT-Traversal probe to
>> continue.

The above sentence doesn't make sense to me.  Perhaps:

s/strings; in Phase 1 two first messages,/strings. In the first
two Phase 1 messages,/

[Ballot discuss]
3.1: The exact string to feed to MD5 isn't clear.  Are the quote marks included?  The hyphen?  The blanks on either side of the hyphen?  The square brackets?

Why is this using a vendor ID?  Where does XXX... come from?  It's not listed in the IANA Considerations section.

(Note: this document shows a fascinating item  protocol-awareness by the NAT has actually proved harmful!)