[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



-----BEGIN PGP SIGNED MESSAGE-----


 >>>>> "Tero" == Tero Kivinen <kivinen@ssh.fi> writes:
     Tero> 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)

     Tero> If there is no NAT involved in the firewall, then the NAT-T will not
     Tero> be enabled, and you will be using just normal IKE and ESP traffic.

   True. 
   But, the security evaluation of what you permit through the firewall has
now changed because standard products now make UDP port 500 a tunneling port.

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

   You are complicated the non-NAT case in order to support the NAT case.
   At least use a different port than 500.

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

     Tero> 	1) Only one keepalive needed, and we only need keepalives
     Tero>            while there is no IKE and ESP traffic.

   I disagree with the need to keep the IKE port alive.

     Tero> 	2) It is simple, and much easier to implement.

   For bump-in-the-stack implementations where you get to inspect every packet
anyway, it might be, but for other people it is much harder to implement. 

   It is possible, for instance, to implement IPsec using "tun0" and a
usermode-process plus some IP-protocol bound sockets since IKE processing is
just normal UDP. Now it is not normal UDP.
   Now, if I want to do this, I must put my IKE daemon in the fast path.

     Tero> 	3) IKE SA mapping through the NAT stays up as long as the IKE
     Tero>            SA/IPsec SAs, which means that the rekeying, deletes,
     Tero>            notifications etc can use same mechanism they are using the
     Tero>            IKE normally, no need to specify some special mechanism to
     Tero>            wake up original initiator who is behind NAT to create the
     Tero>            IKE SA mapping again so original responder can do rekey,
     Tero>            send delete or something like that. 

   In the situations where you really want to do this from the gateway to the
road warrior, I do not buy that not having IKE keepalives is too expensive.

     Tero> 	4) We only need to configure one port for those firewalls
     Tero>            which also do NAT to pass. If the firewall want to inspect
     Tero>            the data he can just check the first 8 bytes if the
     Tero>            traffic, and if it is zeros, then assume that this is ESP
     Tero>            traffic and act accordingly.

   This is a security issue to me.

     Tero> 	5) Did I already mention it is simple and easy to implement :-)

   I do not buy that.

   In order to support this in a BSD protocol stack I must write a kernel
thread (or "nfsd"-like kernel process) that waits on UDP port 500 socket, and
*if* the zeros are not present, must push the packet into a *different* port
500 so that my regular IKE can receive this. 

   Again:
	1) use a different UDP port for IPsec traffic.
	2) if you won't do this, at least do not use port 500.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [
   

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface

iQCVAwUBO4VNB4qHRg3pndX9AQH17QQAqJ0qZp0vNEcaGHlS4qRqBiWZfXXSk8RJ
QRY2k4sD07dEXcrjWBaANEZxe9YSJfCOOgT2M0M3aTTBBgwlKMSUnXLLYs4Ov6yN
cX1VZpmOa8BNs8MhsrUBO6HJ6VLNMBicRsJxwiJdK4w+K3Ny1e9PpBUKy3ts6pvj
Nt7O63lcSpM=
=jMOd
-----END PGP SIGNATURE-----



Follow-Ups: References: