Hello Paul and Everybody,
According to the RFC, its true that application could receive duplicate
data. And, section 7.5.5 (sequence number attacks) states:
....
Send DCCP-Data packets with random Sequence Numbers. If one of
these packets hits the valid sequence number window, the attack
packet's application data may be inserted into the data stream.
....
Ofcourse, this is true for if guessed sequence number is greater then GRS
(greatest received sequence number). But, I am quite surprised myself to
see that even old but sequence-valid packet's data would qualify to be
passed to an application (according to the pseudocode in section 8.5).
There is only sequence validity check in step 6 (swl <= sno <=swh), and
then data goes upstairs in step 16 with only restriction of no double data
from request/response packets.
Meaning that with apropriatelly big window (like 16) with the GSR 4, On
the application one could see any give amount of data from packets with
numbers 1,2,3 if some strange reordering/duplicating events on the network
will take place?
Can anybody clarify this issue? Was there a special purpose for such
definition (like to allow higher layer protocols to handle the data) or am
I missing something inb the rfc?
B.R.
Vladimir.
On Fri, 30 Nov 2007, Paul D. Amer wrote:
First:
I'm teaching a graduate networking class that includes
DCCP as a new experimental protocol. I want to show
students various simple examples. In particular I want to show
which data is delivered (or read by the receiving application)
for different sizes of receive windows, and with/without
loss of DCCP packets. Best I can tell,
the RFC doesn't contain examples. Does anyone know
if any are available elsewhere?
Second:
After reading the RFC, it's my understanding that
DCCP provides 'in-order, maybe-loss, no duplicate,
controlled/partial data integrity' service.
(TCP provides 'in-order, no-loss, no duplicate, full
data integrity' service.)
Am I correct that the data delivered to the receiving
application will be in order and never have duplicates,
(albeit with some data missing, and possibly
some bits in error for those data fields not covered
by the checksum)?
For example, if a sender sends DCCP packets 1,2,3,4,5,6,
the following are valid deliveries to the receiving app:
1,2,3,4,5,6
1,3,4,6
1,6
and the following deliveries may not occur:
2,1,3,4,5,6
1,2,2,2,3,4,5,6
If my understanding is correct, it would help
the RFC intro to explicitly discuss that DCCP service provides
in-order and no-duplicates (just like TCP). If
my understanding is incorrect, it would help the
RFC to have an example or two showing how data
is delivered to the receiver out-of-order or
in duplicate.
Thanks,
Paul Amer, Professor
Univ of Delaware
