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

Re: IKE transport (was INITIAL-CONTACT issues)

Dan:

If supporting thousands of SAs on a security gateway is not a problem, how
are you doing resource recovery again? That is, how do you recover the
security associations whose keys have not yet timed out but which are no
longer in use (because the peer has dropped its keys). There is no
standardized algorithm to do this. Some implementations do nothing. Other
implementations have an inactivity timeout. Other implementations
aggressively renegotiate their keys. Others run proprietary keepalive
algorithms. IKE's lack of a proper call-control or session management
infrastructure is a real problem. That is why it takes hours for the
implementers themselves to trouble-shoot any problem at the IPSec bakeoffs.
How is this stuff supposed to work in the real world? Just my two cents...

Jesse Walkere





Dan Harkins <dharkins@network-alchemy.com> on 05/14/99 09:57:27 PM

To:   Sankar Ramamoorthi <Sankar@vpnet.com>
cc:   ipsec@lists.tislabs.com (bcc: Jesse Walker/Shiva Corporation)
Subject:  Re: IKE transport (was INITIAL-CONTACT issues)




On Fri, 14 May 1999 18:46:52 PDT you wrote
> My main desire for requesting the use of a reliable transport was to
avoid
> the
> problem of tuning retransmit timers.

Except using your suggestion you'd have to establish every peer-wise
relationship using UDP with retransmit timers and then you'd get to do
Quick Modes over TCP. Doesn't sound like much of a benefit.

> I was looking at it from the point of security gateways needing to
support
> thousands of IKE sessions.

Supporting thousands of IKE sessions on a security gateway is not a
problem.

  Dan.

> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> Sent: Friday, May 14, 1999 5:16 PM
> To: Sankar Ramamoorthi
> Cc: 'Derrell D. Piper'; Dan McDonald; pkoning@xedia.com;
> ipsec@lists.tislabs.com
> Subject: Re: IKE transport (was INITIAL-CONTACT issues)
>
>
>   Sounds like a pointless hack. You'd have to do an regular UDP-based
> IKE to generate IPSec SAs which would cover TCP traffic for IKE. And
> this buys you what?
>
>   It sounds like the only desire for using TCP is to give some "network
> security aware" IS guy a warm fuzzy. If this IS guy wants end-to-end
> security then he has to allow stuff through his firewall (and it's more
> than just UDP too). If he doesn't want end-to-end security then IKE's
> transport mechanism isn't an issue.
>
>   UDP does _not_ changed the problem set. Introduction of TCP does
because
> there's a new problem as Dan McDonald pointed out.
>
>   Dan.
>
> On Fri, 14 May 1999 16:05:01 PDT you wrote
> > How about using udp for the first IKE session between 2 endpoints and
then
> > using a tcp-over-ipsec as the transport for the rest of the IKE
sessions
> > that could happen between the end-points?
> >
> > DOS as the sole reason for not using TCP seems to be a high price.
> > And udp has just changed the problem set.
> >
> > -- sankar --
> >
> >
> > -----Original Message-----
> > From: Derrell D. Piper [mailto:ddp@network-alchemy.com]
> > Sent: Friday, May 14, 1999 2:59 PM
> > To: Dan McDonald
> > Cc: pkoning@xedia.com; ipsec@lists.tislabs.com
> > Subject: Re: IKE transport (was INITIAL-CONTACT issues)
> >
> >
> > RE: TCP/UDP/DoS
> >
> > Denial-of-service is such a slipery slope.  If you want to actively
attack
> > IKE, just eat the last packet of Main Mode or Quick Mode...  Dan's
right
> in
> > that using TCP only changes the problem set.  It doesn't solve anything
> > other
> > than by providing a fairly high-cost keepalive mechanism.
> >
> > Derrell