[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Use of Encryption in Heartbeat Packets
> No heartbeat protocol can realistically hope to protect
> against an adversary
> who can modify packets in transit. This is a reasonable
> limitation, and if
> you read the client puzzles document that was recently posted
> to this list
> (http://www.rsasecurity.com/rsalabs/staff/ajuels/papers/client
> puzzles.pdf),
> you will see that they make a similar assumption for their protocol.
>
> Remember that such an adversary (presumably an intermediate router) can
> easily convince you that the peer has crashed simply by refusing to
forward
> any packets on the link (unless you are using ToS = high reliability, but
> that's besides the point).
>
> If the packet is modified in transit, it will still be rejected, just not
in
> a fully DoS-resistant fashion.
>
> Andrew
I'm not at all convinced about the usefulness of assumptions made in the
puzzle paper. He also goes on to say that the DOS problem could be solved
by a PKI...
What I think is that the heartbeat protocol isn't a particularly valuable
target and should be afforded the protection of an existing IPSEC/ISAKMP SA
(definition). From a complexity point of view, it's best if it can be
fitted in without having to modify or add to the existing crypto
architecture.
The problems with the encryption test for integrity are that you need to
know what the plaintext should be, and that it adds to the cost of
processing a correct datagram. If the code for processing the datagram is
generic then it won't be aware of what would be correct plaintext (it
probably won't be a single value), and a lot of solutions can probably keep
up with checking authentication of long datagrams anyway (it's actually
short datagrams that cause more work/byte!).
Chris