[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Use of Encryption in Heartbeat Packets
I was more concerned that you though encryption would provide a quick
authentication check and strengthen the authentication. Ok, re-reading, you
do say this is strengthening is only useful where the authentication
algorithm is weak in the first place. I could be wrong, but I wasn't aware
that the prescribed authentication algorithms were weak in this way.
You do go on to say that encryption helps you reject large spoofed packets
more quickly than authentication alone thus helping defeat a DOS attack.
This was the other point I was questioning.
Chris
> Chris & Henry,
>
> If you read my message closely, you will see that I was never
> considering
> using a heartbeat packet that is not authenticated.
>
> The choice was between AUTHENTICATED ONLY and AUTHENTICATED
> AND ENCRYPTED.
>
> I have most of the rest of the details of the protocol worked
> out already.
>
> Andrew
> _______________________________________________
> Beauty without truth is insubstantial.
> Truth without beauty is unbearable.
>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Chris Trobridge
> > Sent: Tuesday, February 29, 2000 5:18 AM
> > To: akrywani@newbridge.com; 'IPSEC Mailing List @ tis labs'
> > Subject: RE: Use of Encryption in Heartbeat Packets
> >
> >
> > If you're worried about the protocol being attacked, then
> > authentication is
> > a must. As Henry wrote, the less encrypt/bypass decisions
> > there are the
> > safer the product.
> >
> > I'm a little concerned that you think encryption will enable
> > you to reject
> > datagrams earlier. I presume that you mean you can decrypt
> > the initial few
> > bytes of the datagram to check for good plaintext. This
> may have some
> > merit, but it's not a substitute for authentication and
> > probably not that
> > useful over all. An attacker can still modify later bytes in
> > the datagram
> > which would pass any sensible decryption test but not the
> > authentication
> > check.
> >
> > The heart beat protocol continues to raise feelings a little.
> > My view is
> > that there should an SA by which the protocol is protected.
> > I think it
> > could be the ISAKMP SA, though others would rather it were
> > separate. I am
> > against putting it though a regular SA (ie a user negotiated
> > one) unless
> > there's some significant change in the SA semantics - eg
> > Transport mode with
> > IP-in-IP tunnelling for user traffic.
> >
> > I think that there only need to send heartbeats in the
> > absence of regular
> > traffic. This makes an assumption that if there's a valid SA
> > up in the peer
> > then they all are. I think this is a good assumption, though
> > there going to
> > be extreme cases where it's not true. In any case, a further
> > assumption
> > would be that if a particular SA had gone down and the peer
> > was generating
> > authenticated heartbeats that there would be still an
> > authenticated SA by
> > which the peer could report the loss of the SA. If it costs
> > more in CPU to
> > check whether a heart beat has been sent than the loss in
> > bandwidth, then
> > there's nothing to stop the heart beats being sent anyway.
> >
> > There are some schemes that involve ping type operations.
> > They have the
> > advantage that it is possible to detect peer loss without any
> > support in the
> > peer but I've not seen any proposal that works without
> > bending the rules, eg
> > spoofing addresses to meet the SA.
> >
> > Chris
> >
> > > -----Original Message-----
> > > From: Andrew Krywaniuk [mailto:akrywani@newbridge.com]
> > > Sent: 28 February 2000 15:06
> > > To: 'IPSEC Mailing List @ tis labs'
> > > Subject: Use of Encryption in Heartbeat Packets
> > >
> > >
> > > Hi everyone,
> > >
> > > I'm working on a heartbeat protocol draft based on the
> > > comments I received
> > > back in December.
> > >
> > > I want to get people's opinion on one subject that is not
> > > clear to me, which
> > > is whether heartbeat packets should be both encrypted and
> > > authenticated or
> > > just authenticated.
> > >
> > > Possible advantages of encryption are: a) the additional level of
> > > authentication it provides, and b) the confidentiality of
> > the packet.
> > >
> > > a) is not a problem if you use a hash function that is fully
> > > resistant to
> > > differential plaintext analysis (since consecutive packets
> > > may be quite
> > > similar).
> > >
> > > b) seems to be a minor issue because the packet contents
> are of low
> > > sensitivity. The only relevant information the adversary
> > > could gain is the
> > > list of negotiated Spis for that connection.
> > >
> > > The disadvantage of encryption is that it slows down packet
> > > throughput in
> > > the normal case.
> > >
> > >
> > > However, during a DoS attack, the use of encryption would
> > > allow the sgw to
> > > quickly discard invalid (spoofed/replayed) packets. This
> gives it an
> > > advantage over authentication in rejecting large spoofed
> > > packets. However,
> > > there is no advantage in rejecting small spoofed packets.
> > >
> > > So if the adversary can generate and route large numbers of
> > > small spoofed
> > > packets as easily as small numbers of large spoofed
> > packets, then this
> > > protection mechanism doesn't work and encryption does not
> > > provide a DoS
> > > advantage.
> > >
> > > I estimate that in the normal case, 1000 SAs will only
> > > generate an average
> > > of 5kb/sec of heartbeat traffic, so throughput is not a huge
> > > issue. But
> > > there doesn't seem to be a compelling reason to use
> > > encryption either. I'm
> > > tempted to say "better safe than sorry", but I'd like to get
> > > a straw poll on
> > > this issue.
> > >
> > > Andrew
> > > _______________________________________________
> > > Beauty without truth is insubstantial.
> > > Truth without beauty is unbearable.
> > >
> >
>
Follow-Ups: