Negotiation of NAT-Traversal in the IKE
RFC 3947

Note: This ballot was opened for revision 08 and is now closed.

(Russ Housley) Yes

(Harald Alvestrand) No Objection

Comment (2003-11-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Steven Bellovin) (was Discuss) No Objection

(Margaret Cullen) No Objection

Comment (2003-11-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
>> 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"
>> (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,/

(Bill Fenner) No Objection

(Ned Freed) No Objection

Comment (2003-11-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

No copyright boilerplate.
Old way of doing IPR notification?

(Allison Mankin) No Objection

(Thomas Narten) (was Discuss) No Objection

Comment (2003-11-20)
No email
send info
> 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.

(Jon Peterson) (was Discuss) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection

(Ted Hardie) (was No Record, Abstain) Abstain

Comment (2003-11-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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...)