[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats draft (fwd)
On Tue, 28 Mar 2000, Jan Vilhuber wrote:
> On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote:
> > Probably we can be more specific(after some experimentation) about under
> > what conditions we initiate, then try to analyse the risk. I am sure it is
> > not very hard to come up with a simple algorithm, that can bound the risk.
> > I think we can be smart about initiating, and it is not a major risk.
> >
> > Considering the recent discussion on cookies on this mialing list, I
> > wonder how many implementations are handling the DOS risk, even in the
> > responder case.
> >
> > Making the IKE protocol chatty, with expensive heartbeats to save
> > ourselves from DOS doesn't look very logical to me.
> >
> I really don't get your logic. It seems faulty to me.
If you look at the two proposals for solving the problem of syncing peers
when one of them goes down (which I think is a fairly corner case):
heartbeats/no heartbeats.
Heartbeats solution is chatty, and it sucks up a lot of processing and
bandwidth, but it doesn't have any DOS considerations. And the major
disadvantage is that it is not very acceptable in dialer scenarios, which
represent a major portion of our deployment base for IPSec.
No heartbeats solution has some DOS considerations, that I feel are EASY
to tackle. Advantages are it can be used in dial environments, and not
bandwidth/processing intensive.
So, I feel that we should tackle the DOS issues here, instead of imposing
an un-ending DOS attack on ourselves by doing Heartbeats, once every 20
seconds (the recommended heartbeat interval) to all the peers in the world
that we know of. This doesn't scale. I would rather prefer to tackle the
DOS issues, and save processing and bandwidth for sending real traffic.
>
> Just because there's issues with cookies doesn't mean we should add yet
> ANOTHER way that IKE can be taken down via DOS (bounded.. yes yes...).
>
For any protocol, bad implementations can be brought down, and that
doesn't mean that it is a failure of the protocol. I guess it is pretty
sraight forward to avoid any DOS vulnerablity in this case, and if the
implementation chooses to be dumb about it, then I guess it is the
implementation's problem, and not a protocol problem.
> Also, we're not creating an, as you put it, 'chatty protocol', JUST to save
> ourselves from DOS stuff. We're creating this protocol to do keepalives which
> serve a useful purpose, besides DOS stuff.
>
The problem that the heartbeats are trying to solve, can be solved even
without them. If you have any specific scenario where heartbeats are the
only solution to the problem, please post it.
-chinna
> I'm not following you at all.
> jan
>
>
> > -chinna
> >
> > On Tue, 28 Mar 2000, Jan Vilhuber wrote:
> >
> > > Granted, but 'one more place' is 'one more attack'. Just because DOS is a
> > > problem doesn't mean we should give attackers ever more places to do DOS
> > > attacks through.
> > >
> > > I realize it can be bounded (as Dan pointed out in San Diego), but I think
> > > it's a dangerous thing to do. Not to be taken lightly at all. And there will
> > > always be people that will refuse to 'just initiate' so I think a more
> > > general solution that does NOT rely on initiating based on unknown SPI's is
> > > called for.
> > >
> > > jan
> > >
> > >
> > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote:
> > >
> > > > I have addressed the DOS risk in another mail, and I feel that the risk
> > > > can be bounded easily. You have to deal with DOS in every aspect of IKE,
> > > > and this is just one more place.
> > > >
> > > > -chinna
> > > >
> > > > On Tue, 28 Mar 2000, Jan Vilhuber wrote:
> > > >
> > > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote:
> > > > > > An invalid SPI error can be the trigger point (along with other carefully
> > > > > > selected conditions). The peer that just came up will know the
> > > > > > tunnel/transport end point of the peer who is trying to send traffic, and
> > > > > > it can initiate a Main Mode SA to that endpoint. This peer should also
> > > > > > include the initial contact, so that the SADs can be sync'ed back again.
> > > > > >
> > > > > Some would consider that a potential denial-of-service attack, since I can
> > > > > send you dozens of spoofed packets with random spi's..
> > > > >
> > > > > jan
> > > > >
> > > > >
> > > > > > If there is some traffic originating on the side of the peer that went
> > > > > > down, then it has to initiate an SA negotiation anyway. An initial contact
> > > > > > will sync the SADs again.
> > > > > > -chinna
> > > > > >
> > > > > > On Tue, 28 Mar 2000, Henry Spencer wrote:
> > > > > >
> > > > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote:
> > > > > > > > When one of the peer goes down, and comes back up, as I said before, the peer
> > > > > > > > that went down can ("intellegently") initiate fresh SAs with the Initial
> > > > > > > > Contact...
> > > > > > >
> > > > > > > This assumes that the peer which went down is aware, when it comes back
> > > > > > > up, that it *should* initiate fresh SAs. That is not necessarily true.
> > > > > > > If it were, life would indeed be much simpler.
> > > > > > >
> > > > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be
> > > > > > > told to re-initiate when it comes back up. Unfortunately, many people
> > > > > > > wish to use IPSec in much more dynamic situations, where only one end may
> > > > > > > be aware of the immediate desire to send packets. How does a rebooted
> > > > > > > server determine which of its potential clients it should re-initiate
> > > > > > > with? It may not even know their IP addresses!
> > > > > > >
> > > > > > > Henry Spencer
> > > > > > > henry@spsystems.net
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > chinna narasimha reddy pellacuru
> > > > > > s/w engineer
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Jan Vilhuber vilhuber@cisco.com
> > > > > Cisco Systems, San Jose (408) 527-0847
> > > > >
> > > > >
> > > >
> > > > chinna narasimha reddy pellacuru
> > > > s/w engineer
> > > >
> > >
> > > --
> > > Jan Vilhuber vilhuber@cisco.com
> > > Cisco Systems, San Jose (408) 527-0847
> > >
> > >
> >
> > chinna narasimha reddy pellacuru
> > s/w engineer
> >
>
> --
> Jan Vilhuber vilhuber@cisco.com
> Cisco Systems, San Jose (408) 527-0847
>
>
>
chinna narasimha reddy pellacuru
s/w engineer
References: