[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=0



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


>>>>> "Ari" == Ari Huttunen <Ari.Huttunen@F-Secure.com> writes:
    Ari> Derek Atkins wrote:
    >> 
    >> Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
    >> 
    >> >     >> It isn't like the "gateway" is going to be able to initiate to the client
    >> >     >> unless the client cooperates.
    >> >
    >> >     Derek> No, but while the client is connected the "gateway" may still have
    >> >     Derek> something to say _during_ the conversation.
    >> >
    >> >   So, it says it.  If the NAT has timed out, it creates a new source
    >> >   port. The gateway updates its notion of where the client is if
    >> >   the ISAKMP packets decrypts properly.
    >> 
    >> Except if the NAT times out there is NO WAY for the "gateway" to send
    >> the IKE message to the "client".  Sure, if the "client" is the
    >> initiator of the new message then we don't have a problem, but the
    >> whole point was that the "server" may need to initiate re-key or other
    >> notification messages while the IKE SA is alive.

    Ari> It's also relatively evil if the client is thinking it has a working phase 1 SA,
    Ari> when in fact it's dead due to an expired NAT table somewhere in the network.
    Ari> This can of course be solved, but the simplest way is to have that NAT mapping
    Ari> not expire.

  How can that happen?
  When the client transmits, it will create a new NAT table entry. End of
problem.

    Ari> This would be a good time for someone to provide really solid arguments
    Ari> against using just one port, if such arguments exist. Like, statistical
    Ari> calculations of actual overhead. The firewall-argument doesn't cut it, it
    Ari> cannot understand either of the traffic streams even if they are separate,
    Ari> and must just allow them through.

  No you are very wrong.

  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)

]       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

iQCVAwUBO32gLIqHRg3pndX9AQHmFAP+NEKPcOD7zj9u5zn7HgABuidei0w4ACUB
ynSBDmevFBh3qh+e4n+bkmOefu/J3tzYxToNn/BAEC+RQIvtetIFj66PZEs++Pvh
uS9P7TQ6FM8ujpr9PN4afLYVbPZmZmCJshpJ/ir5HNkmhPOpw840AttnQLevfV9p
nb0Re2M9vuU=
=nWpg
-----END PGP SIGNATURE-----


Follow-Ups: References: