comments on draft-ietf-ipsec-nat-t-ike-07

[Darren Reed <avalon@caligula.anu.edu.au>]

As a person who implements an "ike" proxy for IP, I was reading
through the NAT-T draft and noticed a few glaring problems...

First, in the exchange of data, the current draft describes
UDP traffic like this (abbreviated):
I(500,500)->
          <-R(500,X)
I(500,500)->
          <-R(500,X)
This doesn't bode well for sane NAT setup as it requires two
NAT sessions to be maintained (well at least for ipfilter :):
one for the outgoing packets and another for the incoming.
The real problem here is that they're not the same, when they
should be as it's all the same "session".  The problem is that
the firewall/NAT device doesn't know that the responder is
going to use source port X and said device would appear to
have no way to know it should, when compared to a non-NAT-D
IKE conversation.

Second, to complicate matters, it deson't seem possible to
distinguish a NAT-D capable host from those that aren't at
the outset of the session.  The inclusion of the NAT-D section
in the initial packet would help the above problems but is
that problematic for other reasons?

Third, the same problem with port numbers and IKE traffic
has been made with the traffic on port 4500.  Is there any
advantage to using (4500,4500) on the first packet?  Or
why isn't Y in that packet ?  Personally, I see no advantage,
security or otherwise, to fixing the source port.  In the
historical case of DNS, it was a way to distinguish server
to server communication from regular client to server talk.
Here we've got client to server communication that has no
security benefit or otherwise from being on source port 4500.
Any benefit you get from being able to configure a rule for
both ports being 4500 on one side is lost completely with the
replies coming from ports unknown.

Fourth, wouldn't it be appropriate to specifically say, in
the draft, that NAT devices MUST NOT alter the NAT-OAi or
NAT-OAr sections?

Fifth, is this draft applicable to both IKEv1 and IKEv1?
It doens't say but whereas IKEv2 appears to make special
provisions for this protocol to work, IKEv1 doesn't?

I suppose the *REAL* problem with this entire draft is that
there isn't something in the IETF protocol suite equivalent
to UPNP (www.upnp.org) for the IKE/IPsec device to become
aware of the NAT device or talk to it, or should I not even
go there ? O:-)

Just one last question, if there are three or more NAT devices
in the chain betweem the two endpoints, does this draft expect
an IKE conversation & IPsec to succeed for AH ?

Darren