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

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

ash kat wrote:
> 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 F. G. Bidulock" <[email protected]> wrote:
>   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.
>>
>>Please let me know your opinion about this.
> 
> 
> 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
> 


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