Skip to main content

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

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