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