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

From: ash kat <[email-masked]>
Date: Fri, 16 Jun 2006 02:09:40 -0700 (PDT)

Hi All
   
  What should be the behavior of SCTP when an endpoint recieved a Heartbeat-ack from peer when it has not sent any heartbeat to peer?
   
  Is RFC 2960 say anything about this?
   
  If Not then What is the proper solution:
  1. The Endpoint should drop the message [ ignore the Heartbeat ack ]
  2. Process the Hearbeat ack as normal.
  3. Send an Abort to peer.
  4. Some other option.....
   
  Regards,
  Ashwani Kathuria.

---------------------------------
Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 16 Jun 2006 12:14:01 +0200

Hi,

since it is not from you:
Do not process it.

I would also just drop it and take no further action.

Best regards
Michael

PS: When receiving a HB-ACK in response to an HB I would check if
     all fields make sense. You should not be attackable by a peer
     which modifies the HB info...

On Jun 16, 2006, at 11:09 AM, ash kat wrote:

> Hi All
>
> What should be the behavior of SCTP when an endpoint recieved a  
> Heartbeat-ack from peer when it has not sent any heartbeat to peer?
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 Jun 2006 04:18:36 -0600

ash,

See also RFC 4460 Section 2.36.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 16 Jun 2006 13:43:33 +0200

Comments in-line,
Best regards
Michael

> See also RFC 4460 Section 2.36.
That section describes initial path verification. I think his question
was more general: How do you process a received HB-ACK, when you
have never sent a HB?
The other point I made was: Even if you sent a HB, you can not be
sure that the peer reflects the HB info. It could be an attacker...
(we did this years ago at an interop and this provided some  
implementations
problems...)

---

From: radhika agarwal <[email-masked]>
Date: Fri, 16 Jun 2006 11:05:16 -0700 (PDT)

Hi,
   
  If an OOTB heartbeat ack is received, then it shall anyways lead to sending of an abort chunk to the peer, as per section 8.4 of RFC 2960.
   
  If an heartbeat ack chunk is received from a destination addr of a valid association, to which no heartbeat was sent, then the heartbeat ack msg should be discarded. 
   
  The processing of such a heartbeat ack message may lead to incorrect calculations of association parameters like RTT
   
  Michael, as for peer sending an incorrect HB info , dont we assume that the peer with which the 4 way handshake is successfully executed is not an attacker. If not then we might have to include another MAC with the HB info field.
   
  Regards,
  Radhika

Michael Tuexen <[email-masked]> wrote:
  Comments in-line,
Best regards
Michael

 

 
 
_______________________________________________________________
Life is Beautiful.
______________________________________________________________

---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 16 Jun 2006 20:20:03 +0200

Hi Radhika,

see my comment in-line.

Best regards
Michael

On Jun 16, 2006, at 8:05 PM, radhika agarwal wrote:

> Hi,
>
> If an OOTB heartbeat ack is received, then it shall anyways lead to  
> sending of an abort chunk to the peer, as per section 8.4 of RFC 2960.
>
> If an heartbeat ack chunk is received from a destination addr of a  
> valid association, to which no heartbeat was sent, then the  
> heartbeat ack msg should be discarded.
>
> The processing of such a heartbeat ack message may lead to  
> incorrect calculations of association parameters like RTT
>
> Michael, as for peer sending an incorrect HB info , dont we assume  
> that the peer with which the 4 way handshake is successfully  
> executed is not an attacker. If not then we might have to include  
> another MAC with the HB info field.
If the peer sends wrong HB-ACKs he should not be able to affect other  
associations and not get better
throughput... What I saw is that implementations had an array index  
in the HB Info and we could modify it
such that it was not a valid index anymore. The stack crashed. This  
is what I mean: Check all stuff you get
before using it.

---

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,

--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/