[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
The Firewall Mapping dying is a great concern, We found different devices
will time out the mappings between 25seconds - 2 minutes for UDP traffic.
Since in most scenereo's nobody will be able to "modify" the firewall (i.e.
Contractor working behind NAT, hotel room working behind NAT) we need to
come up with some idea intervals for the keepalive packets.
We are defaulting to 5 seconds, and only send keepalives if no traffic has
been sent for 5 seconds - so only when its needed as to not consume
bandwidth. I suggest most implementations keep this user-configurable or at
least not hard-coded somewhere.
We are also interested in testing with anyone who we havn't yet tested with,
Email me if interested.
-----Original Message-----
From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com]
Sent: Friday, August 17, 2001 3:46 PM
To: Derek Atkins
Cc: Michael Richardson; ipsec@lists.tislabs.com
Subject: 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