Subject: [Tsvwg] Re: [Sigtran] SCTP: Heartbeat ack recieved without sending Heartbeat

From: ash kat <[email-masked]>
Date: Sun, 18 Jun 2006 23:14:09 -0700 (PDT)

Hi Brian
   
  Section 2.36 of RFC 4460 says.
   
  "....
     Upon receipt of the HEARTBEAT-ACK, a verification is made that the
   nonce included in the HEARTBEAT parameter is the one sent to the
   address indicated inside the HEARTBEAT parameter.  When this match
   occurs, the address that the original HEARTBEAT was sent to is now
   considered CONFIRMED and available for normal data transfer.
...
  "
   
  But is it mentioned anywhere that what should we do in case the verification results in a failure?
   
  In my opinion we should discard this kind of HB-Ack, which are received without sending the HB to peer.
   
  But there should be some standardized behavior [Whatever it will be as a result of this discussion] for this scenario.
   
  Please let me know your opinion about this.

  Regards,
   
  Ashwani Kathuria

"Brian F. G. Bidulock" <[email-masked]> wrote:
  ash,

See also RFC 4460 Section 2.36.

--brian

---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Jun 2006 03:05:46 -0600

ash,

ash kat wrote:                               (Sun, 18 Jun 2006 23:14:09)
>
>    But there should be some standardized behavior [Whatever it will be as
>    a result of this discussion] for this scenario.
> 

At one time there was some (more) mention of this in the I-G (which became
RFC 4460) because at early interops hacking the other implementation's HB
was a popular passtime, however, it was removed at some point along the way
(I'm not sure why).

IMO there should be some mention, as a hacked HB-ACK could cause an
implementation to overrun its congestion window, posing both a security risk
as well as a risk to the Internet.

--brian

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

---

From: ash kat <[email-masked]>
Date: Mon, 19 Jun 2006 04:21:27 -0700 (PDT)

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.

  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.
   
  1) So the remaining option of silently Discarding/Droping this HB-Ack [without informing the peer or user] is the most appropriate one.
   
  Please share your view on this?
   
  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.
   
  Regards,
  Ashwani Kathuria

--brian

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

---------------------------------
Do you Yahoo!?
 Get on board. You're invited to try the new Yahoo! Mail Beta.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Jun 2006 05:40:03 -0600

ash,

ash kat wrote:                                 (Mon, 19 Jun 2006 04:21:27)
>    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-masked]
http://www.openss7.org/

---

From: Randall Stewart <[email-masked]>
Date: Mon, 19 Jun 2006 08:58:20 -0400

Ash:

I don't remember the stuff being removed... the nonce stuff
came in roughly in rev-10 of the I-G.. if I remember
right.. might have been 11..

But in any event it SHOULD say to discard a HB-ACK
that has an incorrect nonce..

i.e. you ignore it dropping it silently..

Since if you get this, it most likely is an attacker
trying to get you to "CONFIRM" an address that it
does not own..

I will add this as a todo.. for the next pass of the
BIS.. this is obviously either, as Brian points out, a
place where we accidentally removed the text... or an
oversight.. in either case both sides of what to do should
be spelled out.. aka if you receive one and it matches
the address is confirmed.. if you receive one and it
does NOT match.. silently discard the HB-ACK...

Note, that if it is an attacker, most likely you will be
shortly receiving an ABORT() or ICMP-Protocol-Not-Available
(assuming of course ICMP is not screened out by a firewall :0)

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Randall Stewart <[email-masked]>
Date: Mon, 19 Jun 2006 08:59:49 -0400

> seomthing.  I always prefer to give such hackers "dead air".

I agree.. "dead air" is best here...

R