Re: SCTP: Heartbeat ack recieved without sending Heartbeat

ash,

ash kat wrote:                                 (Mon, 19 Jun 2006 04:21:27)
> 
>    Hi
> 
> 
> 
>    IMO there can be 3 possible solutions to this problem:
> 
> 
> 
>    1. The Endpoint should drop/discard the Heartbeat ack chunk
> 
>    2. Process the Heartbeat ack as normal.
> 
>    3. Send an Abort to peer.
> 
> 
> 
>    If we take the:
> 
>    3) Third option [Sending the ABORT chunk] : The received HB-ACK is for
>    a valid association but the receiver hasn't sent the HB so this HB-Ack
>    can  be from  an  attacker.  So  sending  an  ABORT will close [ABORT]
>    the right  association  and will solve the purpose of the attacker. So
>    this option is ruled out.

According to RFC 4460 or rfc2960bis, you must send a nonce-HB to each
destination before it is used.  Therefore, you always have sent a HB.
You cannot send an ABORT until the destination is verified.

Therefore, if you want to send an ABORT, you should also verify that the
HB-ACK is not just some delayed HB-ACK corresponding to a previously sent
HB.

> 
>    2) Second  option  [Process the Heartbeat Ack as normal ] : Doing this
>    will result  in  the  modification  of some internal parameters of the
>    SCTP stack for that association. So this option is also ruled out.

Do not.  (I fully agree with Michael here.)

>    1)  So the remaining option of silently Discarding/Droping this HB-Ack
>    [without informing the peer or user] is the most appropriate one.

This is also the proper response if it is just a delayed HB-ACK that no
longer corresponds to the last outstanding sent HB.

>    Brian: If you  remember  then please mention what was the behavior for
>    this  scenario in the IG that is now removed. It willl help us to make
>    a proper solution for this problem.

I remember the behaviour as discarding the HB-ACK, but also permitting an
ABORT to be sent.  But, wherever ABORT may be sent, it may also be suppressed
according to the new RFC 4460 rfc2960bis.  Also, because of attack scenarios,
ABORT should be avoided when the peer is suspected of fiddling around with
seomthing.  I always prefer to give such hackers "dead air".

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/