[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie

mcr@sandelman.ottawa.on.ca (Michael Richardson) writes:
 >   There are multiple places where there are firewalls which permit
 > *IKE* on port 500 through. They also currently permit IP proto 51,
 > which is can understand through. By putting ESP traffic on port 500,
 > you circumvent a specific firewall policy. We knew what the risks
 > were with letting IKE through.
 > 
 >   (Note, the firewall does not do NAT nor is it stateful, nor are there any
 > private network addresses involved)

If there is no NAT involved in the firewall, then the NAT-T will not
be enabled, and you will be using just normal IKE and ESP traffic.
There is NO REASON to use NAT-T unless you have NAT between the two
hosts. The NAT-T NAT discovery will automatically detect if there is
NAT between and enable using of NAT-T only and only if there is NAT
between and the NAT-T is supported by both ends.

Having IKE and ESP on the same port is UGLY, I agree, but so is NAT
anyways. When there is NAT involved there is no clean beautiful
solution available :-)

Anyways puting the IKE and ESP on the same port has some advantages:

	1) Only one keepalive needed, and we only need keepalives
            while there is no IKE and ESP traffic.
	2) It is simple, and much easier to implement.
	3) IKE SA mapping through the NAT stays up as long as the IKE
            SA/IPsec SAs, which means that the rekeying, deletes,
            notifications etc can use same mechanism they are using the
            IKE normally, no need to specify some special mechanism to
            wake up original initiator who is behind NAT to create the
            IKE SA mapping again so original responder can do rekey,
            send delete or something like that. 
	4) We only need to configure one port for those firewalls
            which also do NAT to pass. If the firewall want to inspect
            the data he can just check the first 8 bytes if the
            traffic, and if it is zeros, then assume that this is ESP
            traffic and act accordingly.
	5) Did I already mention it is simple and easy to implement :-)
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
Follow-Ups: