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

From: Meyknecht Bernward <[email-masked]>
Date: Fri, 17 Sep 2004 07:04:46 +0200

Hi all,

what I'm doing in that case is generating an error chunk, not abort, and stop 
processing the packet. Hope this will be allowed by the implementors
guide, too...

Best regards,
Bernward

-----Ursprungliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]Im Auftrag
von Vladislav Yasevich
Gesendet: Donnerstag, 16. September 2004 19:11
An: Randall Stewart
Cc: Michael Tuexen; [email-masked]
Betreff: Re: [Tsvwg] SCTP- processing of bundled chunks

Randall Stewart wrote:
> 
> if ((c-len == 0) || ((offset+c-len) > p-len))
>     stop processing

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.

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

Will this be clarified in the next implementors guide?

Thanks
-vlad

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

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

_______________________________________________
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: Randall Stewart <[email-masked]>
Date: Fri, 17 Sep 2004 20:01:52 -0400

> processing the packet. Hope this will be allowed by the implementors
The RFC (for that is what the implementors guide is modifying) leaves
this open to implementation decision.. you can ABORT or you can
generate an ERROR...

And I don't see that the I-G (and future BIS) will document every
error case and the cooresponding implementation decisions....

There are always things that are up to the implementation like this..
If you choose to continue processing with peers sending faulty chunks..
then that is ok.. if on the other hand you want to abort.. thats ok
too...

R