[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats draft (fwd)
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.
-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
Follow-Ups:
References: