[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
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.
It's also relatively evil if the client is thinking it has a working phase 1 SA,
when in fact it's dead due to an expired NAT table somewhere in the network.
This can of course be solved, but the simplest way is to have that NAT mapping
not expire.
At the Helsinki bakeoff there were seven implementations of the latest drafts,
including us. Additional three had implementations of some earlier draft.
This would be a good time for someone to provide really solid arguments
against using just one port, if such arguments exist. Like, statistical
calculations of actual overhead. The firewall-argument doesn't cut it, it
cannot understand either of the traffic streams even if they are separate,
and must just allow them through.
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
Follow-Ups:
References: