[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



Michael Richardson wrote:
>     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.

This requires that the gateway allows the client's IP address and port to vary
during a connection, and to record the latest values. It's possible, but is not
the choice made for the drafts.

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

Yes. If you allow encrypted traffic through a firewall, the firewall loses all
possibility to enforce any sort of policy for the packets inside the encryption.
End of story. It makes no difference whether ESP packets go inside port 500 or
by themselves.

Ari

-- 
Ari Huttunen                   phone: +358 9 2520 0700
Senior Software Engineer       fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security


References: