Negotiation of NAT-Traversal in the IKE
RFC 3947
Yes
No Objection
Abstain
Note: This ballot was opened for revision 08 and is now closed.
(Russ Housley; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
(Bill Fenner; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
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.
(Jon Peterson; former steering group member) (was Discuss) No Objection
(Margaret Cullen; former steering group member) No Objection
>> 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,/
(Ned Freed; former steering group member) No Objection
Nits: No copyright boilerplate. Old way of doing IPR notification?
(Steven Bellovin; former steering group member) (was Discuss) No Objection
(Thomas Narten; former steering group member) (was Discuss) No Objection
> 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.
(Ted Hardie; former steering group member) (was No Record, Abstain) Abstain
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...)