Re: [tsvwg] Kathleen Moriarty's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT)

[Kathleen Moriarty <[e-mail]>]

Sent from my iPhone

On Aug 31, 2017, at 4:01 AM, Michael Tuexen <[e-mail]> wrote:

>> On 30. Aug 2017, at 22:54, Kathleen Moriarty <[e-mail]> wrote:
>> 
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-tsvwg-sctp-ndata-12: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> I looked at the references for security considerations, [RFC4960] and
>> [RFC6458], and don't see an explicit mention of fragmentation overlap and in my
>> skim, didn't see that it was covered for reassembly as a warning.  Does this
>> need to be added?  If not, can you explain how it is covered?
> Hi Kathleen,
> 
> the fragments don't use a byte range which could overlap, but a sequence
> numbers. So if the peer doesn't violate the protocol specification, there
> can not be any overlap. If the peer does not follow the specification,
> it could try to send different I-DATA chunks (using different TSNs) but
> with the same SID, U bit and FSN. A receiver can detect this. In the
> FreeBSD implementation we ABORT the association in this case indicating
> a Protocol Violation. An alternative would be to just drop the first
> (in case it is not partially delivered yet) or drop the second I-DATA
> chunk. I guess this is implementation dependent. We had already in RFC 4960
> the situation that we have no specified the various ways on inconsistent
> parameter combinations and how to deal with them.
> 
> Does this clarify this issue? 

Yes, thank you.
Kathleen 
> 
> Best regards
> Michael
>> 
>> 
>