Subject: Re: [Tsvwg] SCTP- processing of bundled chunks

From: Randall Stewart <[email-masked]>
Date: Thu, 16 Sep 2004 05:46:06 -0400

Bhanu/Valdislav:

Comments in line...

Vladislav Yasevich wrote:
> Bhanu
> 
> bhanu wrote:
> 
>> Hai Michael
>>
>> The feedback was helpfull
>>
>> But again, is it really possible to find out wheather the size 
>> indicated by the
>> chunk_length parameter is correct or not..???
> 
> 
> I think, as long as the end of the chunk is computed to be within the
> payload, you have to assume that it's valid.  The only additional
> assuarances I can think of require some sort of transport or network
> security.
Well you can look at this with two scenarios:

1) Its an attacker.. i.e. your security comment above... which
    if that is the case it is either sniffing packets... and thus
    got the v-tags and can abort you or whatever... Or is very good
    at guessing... i.e. it must get a 1 in 4billion number (the vtag)
    correct... In either case it can break your association.. so you
    must assure that your O/S does not panic at the minimum :-D

2) Its a sick peer... in which case again, you want to make sure
    you do not die (and loose 20 points if you are at a inter-op :->).

No matter which is the case you always have:

a) The packet length (from the ip header) (p-len)
b) The offset into the packet where you are (offset)
and
c) The length the chunk says it is... (c-len)

So you should always do:

if (offset+c-len) > p-len
    stop processing.

as long as the above condition is NOT true, you must
assume the chunk is correct and that your peer is sane.. obviously
if the peer is crazy the next chunk will most likely lead you
to realize the problem... and thus the test above will not
be true...

Another little nasty to watch for is (c-len == 0)  otherwise
you will find yourself spinning endlessly

soo the modified test should be:

if ((c-len == 0) || ((offset+c-len) > p-len))
     stop processing

Now, what to do when one stops processing... Michael as suggested
an ABORT()... which is probably the right thing to do... since
if its scenario <1> you don't want to continue talking.. and
it its scenario <2> you probably also don't want to continue to
talk... However.. this is an implementation decision... so you
MUST stop processing the chunk.. and you MAY abort with the
error Michael describes..

R

> 
>>
>> Is there exists an ABORT with error cause 'PROTOCOL VIOLATION' !!!!!
> 
> 
> It is definied in the SCTP Implementer's Guide 
> (draft-ietf-tsvwg-sctpimpguide-nn).
> 
> -vlad
> 
>>
>> Thanks
>> Bhanu.
>>
>>
>> Michael Tuexen wrote:
>>
>>> Hi Bhanu,
>>>
>>> see my comments in-line.
>>>
>>> Best regards
>>> Michael
>>>
>>> On 31. Aug 2004, at 11:02 Uhr, bhanu wrote:
>>>
>>>> Hai All
>>>>
>>>> While processing each chunk from a bundle, individual chunks are 
>>>> extracted
>>>> using the chunk_length parameter as the size of that chunk.
>>>> So the next chunk will be at the location = CHUNK_HEADER_SIZE +  
>>>> CHUNK_LENGTH.
>>>>
>>> No, the chunk size does include the chunk header, So you need to do
>>> offset += ADD_PADDING(chunk_length)
>>> where ADD_PADDING adds the padding (0 to 3 Bytes).
>>>
>>>> Consider the processing of any variable length chunk (e.g : COOKIE 
>>>> ECHO or DATA).
>>>> If the chunk_length parameter of a chunk indicates a size which is 
>>>> more than the actual size
>>>> of the chunk, what should be the action by the reciever of such 
>>>> chunk..???
>>>
>>>
>>>
>>> Well, that chunk is violating the spec, right? So I would send back an
>>> ABORT with error cause 'PROTOCOL VIOLATION'.
>>>
>>>> what about extracting and processing of the chunks which are bundled 
>>>> after this,
>>>> as the chunk_length indicates some wrong value it is not possible to 
>>>> know the end of this chunk.
>>>
>>>
>>>
>>> Since you do not know the 'real' size you have to give up, I think. 
>>> That is
>>> why I'm suggesting the ABORT...
>>>
>>>> (The RFC-2960 does not talk about handling of such scenario).
>>>>
>>>> Can anybody guide us in this regard.
>>>>
>>>> Regards
>>>> Bhanu.
>>>>
>>>>
>>>> _______________________________________________
>>>> tsvwg mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/tsvwg
>>>>
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> tsvwg mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/tsvwg
>>
> 

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

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 16 Sep 2004 13:10:37 -0400

> if ((c-len == 0) || ((offset+c-len) > p-len))

Actually, this could a bit different and catch a bad length
sooner:

if ((c-len < sizeof(chunk_header)) || ((offset+ c-len) > p_len))
	stop processing

This way you stop sooner and can identify the faulty chunk.

> error Michael describes..

Will this be clarified in the next implementors guide?

Thanks
-vlad

>>>>> what about extracting and processing of the chunks which are 
>>>>> bundled after this,
>>>>> as the chunk_length indicates some wrong value it is not possible 
>>>>> to know the end of this chunk.
>>>>
>>>>
>>>>
>>>>

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Linux and Open Source Lab
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 18 Sep 2004 11:00:51 +0200

Vland,

see my comments in-line.

Best regards
Michael

> Will this be clarified in the next implementors guide?
Just to be clear:
(offset+ c-len) > p_len)
describes the case of a 'partial chunk'.
This notion is currently used in the RFC but not defined.
(c-len < sizeof(chunk_header)
describes a chunk which is malformed. This is, in my opinion, the
same a SACK chunk, where the c-len is smaller than the minimum
SACK header size which is larger than the chunk header.

Randall is talking only about partial chunks and malformed chunks
you can not skip (c-len == 0) (You would loop forever).

There is no requirement to stop processing of the packet
if you find a malformed chunk. You can send an ERROR or an ABORT
depending on what you prefer and stop processing of the packet.
If you prefer to send and ERROR you could even continue to process
the packet.

So there is a semantic difference between you condition and the
one Randall posted.

The implementer is free to choose a way of handling and we do not
have to specify this. But it seems to be good to clarify what
a partial chunk is.
I propose text to the IG for a definition.
>>>>>> Consider the processing of any variable length chunk (e.g : 
>>>>>> COOKIE ECHO or DATA).
>>>>>> If the chunk_length parameter of a chunk indicates a size which 
>>>>>> is more than the actual size
>>>>> Since you do not know the 'real' size you have to give up, I 
>>>>> think. That is

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 21 Sep 2004 10:58:55 -0400

Michael

Thanks for response.  See below.

> If you prefer to send and ERROR you could even continue to process

Ok, but I wasn't really looking for a requirement.  I was hoping
for a guidance (a MAY).  Currently, there is nothing at all that
suggests how to handle mallformed chunks (and mallformed parameters)
whethere they have a length of 0 or not.

> have to specify this. But it seems to be good to clarify what

You are right, you don't *have to* specify this.  However a few
people have asked how this can be handled, and from what I've heard,
some discussions also happened at the latest interop event.  Based
on that, it would be good if the short guidance be included in the
IG or the BIS spec when it comes up.

Thanks
-vlad