Subject: [Tsvwg] SCTP: Association receiving malformed packet in established state

From: kumar gaurav <[email-masked]>
Date: Wed, 13 May 2009 16:47:50 +0530 (IST)

Hi All,
 
      Consider a scenario where an sctp host receives a malformed packet which has valid src port, dst port, src address, dst address and verification tag but has wrong chunk fields("protocol error"). In this case it is possible to identify the the association(which is in established state) to which it is destined for. 
 
1) Should this packet be considered as valid and responded with an ABORT and also delete the association or
2) Should this packet be considered as malicious packet and responded with an ABORT but not deleting the association.
 
I could not find anything directly relating to this scenario from RFC 4960. Any suggestions would be helpful.
 
Thanks and Regards,
Gaurav

      Bollywood news, movie reviews, film trailers and more! Go to http://in.movies.yahoo.com/

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 13 May 2009 12:23:48 -0400

kumar gaurav wrote:
> Hi All,
>  
>       Consider a scenario where an sctp host receives a malformed packet
> which has valid src port, dst port, src address, dst address
> and verification tag but has wrong chunk fields("protocol error"). In
> this case it is possible to identify the the association(which is in
> established state) to which it is destined for.

Yes.  The association is typically identified by the port and address pairs.
Thus if those pairs are correct, you will identify the association.

> 2) Should this packet be considered as malicious packet and responded
> with an ABORT but not deleting the association.

Things like this typically trigger an ABORT with protocol violation error.
It is up to the implementation whether to remove the association or not.

-vlad

> ------------------------------------------------------------------------
> Cricket on your mind? Visit the ultimate cricket website. Enter now!
> <http://in.rd.yahoo.com/tagline_cricket_1/*http://beta.cricket.yahoo.com>

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 14 May 2009 08:20:28 -0400

Randall Stewart wrote:
> Vlad:
> 
> Has I said in my previous email..
> 
> This is NOT a protocol violation. One must look
> at the "chunk type" bits.. and then based
> on that you respond as appropriate.
> 
> You would have to look at the bit fields (per 3.2) and
> then respond.
> 
> If the packet itself is mal-formed.. i.e. incorrect lengths
> etc.. thats a different story.. but my read of what Kumar
> was asking is about a incorrect value in the chunk field
> and this is well specified in the RFC.
> 
> 

Hi Randy

I took his message to mean that a chunk is malformed somehow.
Looking at his follow up, he did mean malformed length and that's
a protocol violation.

If the chunk type is simply unrecognized, then yes, the spec spells
out very clearly how to handle it.

-vlad

> R
> 
> 
> On May 13, 2009, at 12:23 PM, Vlad Yasevich wrote:
> 
>> kumar gaurav wrote:
>>> Hi All,
>>>
> ------------------------------
> Randall Stewart
> 803-317-4952 (cell)
> 803-345-0391(direct)
>

---

From: Randy Stewart <[email-masked]>
Date: Wed, 13 May 2009 11:45:09 -0400

Kumar:

Neither of your options are what is to be done.

What you must do is follow the bit values on the chunks in question.  
I.e the
chunk that has the "wrong chunk field" must be examined and
you follow the RFC's specification on this.

Looking at the chunk id as an 8 bit value
X Y - - - - - -

Gives you how to handle the chunk.

Just because your implementation does NOT support a new chunk
that you have never seen does NOT mean its a protocol violation.
The RFC is very specific on how to handle these bits. In fact
it is always tested at interops (and newbees generally have it wrong..
which is why we test it).

See section: 3.2 of the RFC..

R

On May 13, 2009, at 7:17 AM, kumar gaurav wrote:

> Hi All,
>
>       Consider a scenario where an sctp host receives a malformed  
> packet which has valid src port, dst port, src address, dst address  
> and verification tag but has wrong chunk fields("protocol error").  
> In this case it is possible to identify the the association(which is  
> in established state) to which it is destined for.
>
> 2) Should this packet be considered as malicious packet and  
> responded with an ABORT but not deleting the association.
>
> I could not find anything directly relating to this scenario from  
> RFC 4960. Any suggestions would be helpful.
>
> Thanks and Regards,
> Gaurav
>

-----
Randall Stewart
[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Thu, 14 May 2009 06:29:08 -0400

Opps..

I sent this from the wrong account ;-)

R
On May 13, 2009, at 11:45 AM, Randy Stewart wrote:

>> In this case it is possible to identify the the association(which  
>> is in established state) to which it is destined for.
>>

---

From: Randall Stewart <[email-masked]>
Date: Thu, 14 May 2009 06:05:43 -0400

Vlad:

R

On May 13, 2009, at 12:23 PM, Vlad Yasevich wrote:

>> packet
>> 1) Should this packet be considered as valid and responded with an  
>> ABORT
>> and also delete the association or
>> <http://in.rd.yahoo.com/tagline_cricket_1/*http://beta.cricket.yahoo.com 
>> >
>