[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Use of Encryption in Heartbeat Packets
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.
> >
>
References: