[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt

"Mason, David" <David_Mason@NAI.com> writes:

> Well that would be at least an order of magnitude less
> keepalives.

Um, not necessarily.  And then you add the complication of how an IKE
daemon knows to contact its peer via the TCP connection.  You also are
now doubling the connection state in each IKE daemon (requiring a
fully connected TCP stream) and also more NAT firewall state to keep
the TCP session alive.

What are you saving, here?  You're adding complexity and state because
you're worried about traffic during 'idle' connections?

You don't need to use the keepalives as long as there is traffic.
Where there isn't traffic, sure, you need a keepalive packet every
30-60 seconds or so, on average.  Honestly, I don't consider a single
UDP packet this often to be overly heinous.

> > If your connection is idle for that long a period of
> > time, send an IKE DELETE notification and tear down
> > the session.
> 
> Do you think that this recommendation should go into the
> ID (and would you suggest a default - if the inside system
> would lose connections after 10 minutes without using VPN
> then perhaps a 10 minute default would be appropriate).

Whoa, nellie.  There is a disconnect here.  I think you're making an
assumption that a box that is idle necessarily _wants_ to tear down
the session.  That is not always a valid assumption.  Sometimes an
idle session is just an idle session.

Keep in mind Bill's scenario.  I user (behind a NAT) has a connected
TCP session from their client to some other machine, protected by
IPSec.  IPSec absolutely _MUST_ keep the UDP mapping alive because
_either host_ can send a packet on this connection.  Note that the NAT
box only sees ESP packets going back and forth -- it has no idea that
those ESP packets are encoding TCP session state.  They could just as
easily be carrying RTP, UDP, or DecNet packets (ok, maybe not DecNet
:)

Basically, so long as that TCP connection is alive, you MUST keep the
UDP mapping alive so that IPSec packets can pass back and forth.

> > The reason you need the keepalive there is that if the
> > IKE SAs are still in place, there is no way to know
> > _which side_ will want to send the 'next' packet.  If it's
> > the 'server' (e.g. the non-natted host' then there is no way
> > for that server to contact the client (the natted host)
> > because all state information has been lost.  And there is no
> > way to notify the client that there is any data to transmit,
> > either,for the same reason.
> 
> If there are IKE SAs still in place then all state information
> has not been lost so I'm assuming you mean the NAT mappings
> are gone.  That's why I proposed using a TCP second channel.
> So the server could contact the client via the TCP NAT mapping
> and request that the client reactivate the UDP NAT mapping.

You need keepalives as long as the IKE SA and IPSEC SAs are active.
The point of keepalives beyond the length of the IKE SA is that the
non-natted host may want to rekey, and may delay re-keying until the
SA has expired.  In that case, you want to keep the NAT mapping alive
_JUST LONG ENOUGH_ to let that happen.  If the SAs expire and DONT get
rekeyed, then the keepalives stop.

Regardless, as long as the SAs _are_ active, you MUST keep the session
alive (as far as NAT is concerned).  There is no option, you have to
do it.

> -dave

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available
References: