[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dccp] Review of DCCP specification

Hi,

Here is my DCCP specification (Draft-ietf-dccp-spec-04.txt) review comments so far. Lets see if I have some more at the WG meeting. A few of them may need discussion. Happy reading.


This review is divided into two parts, editorial comments that would
either increase readability and understanding or correcting what seems
to be obvious mistake. The other part is the more substantial comments
that has more to do with how the protocol works.

Protocol comments and questions.
--------------------------------

P1. Section 2: Design rationale, why is not ECN a motivation behind
deploying DCCP instead of UDP?

P2. Regarding Identification option. Is it possible to exchange the
connection nonce out-of-band in regards to DCCP? If one has a secure
communications channel one can exchange these and that way ensure that
any identification hash is actually non-spoofable, even for an
eavesdropping attacker. This provides protection against hi-jacking,
that otherwise is hard to protect against for hosts without
authentication possible IP addresses, like hosts behind NATs.

P3. Another problem that I think is important that DCCP helps solve is
the RTP DoS attacks. See draft-rosenberg-mmusic-rtp-denialofservice-
00.txt and draft-ietf-mmusic-rtsp-nat-01.txt for more details. This
attack can be clearly mitigated by having a connection establishment
that requires the receiving host to acknowledge the data flow. So this is
a further motivation to deploy DCCP. However DCCP does not provide
protection as I understand it against any attack capable of
eavesdropping the connection attempt. In that case the attacker can
spoof a DCCP-Response packet to establish the session. However
the attacker must also continue to spoof ACK packets for the
congestion control to not back off. However to have full protection
against this attack requires that the receiving host can
authenticate the packet in an unspoofable way.

P4. Section 4.1, packet types: Are not packet type 9-15 reserved for
future extensions?

P5. Section 5.3, Page 21, second paragraph: Why is the sequence number
set to zero? Does this have impact on the selection of random initial
sequence number, basically saying that 0 SHALL NOT be used.

P6. Section 5.6, page 26, First complete paragraph, last sentence: What
do you mean with inappropriate here. When is a link congested so that it
is inappropriate, some hint should be provided.

P7. Section 5.9, DCCP move packet. If an end-point needs to move its
connection it needs to know the old IP address and port seen as from the
other end-point. How should this work if there is NATs between the
client and server? To enable this one basically needs to have STUN
functionality in DCCP or running something like this over DCCP.

P8. Section 6.3.7, Request State Diagram: Why is the reception of any
packet forcing B to send a change? Can't features remain in state
unknown even though data is flowing over the connection? Secondly, why
is there a possibility for a state transition "changing->changing" when
receiving a confirm? Also why is an timeout missing in the state diagram?

P9. Section 6.3.7 Feature Location State Diagram: Why does a feature
need to be set, when a DCCP packet is received? Why not include timeout
process in the diagram. I guess that the known->confirming transition is
done when a chg(x) is received, resulting in the sending of prefer(O)?
Further the diagram is to wide to fit into the page width.

P10. Section 6.7: What is the reason for the Elapsed time option. Does
anybody know of a usage that does not relate to the timestamp and
timestamp echo functionality where this is already included?

P11. Section 8.6: You have examples of two different reasons for sending
the slow receiver option. Why not have two different options one
indicating slow receiver due to I/O. Another indicating slow receiver
due to overload on CPU. That way the mechanism would be more expressive.

P12. Section 11, MTU discovery. I would think that there should be an
informative reference to the work in the newely started PMTUD WG. The
nice thing is that by using ACK vector a sender can use the so far
proposed application based method in that WG.

P13. Section 15, third paragraph. RTCP will stop being sent rarely now
that the new profile AVPF (draft-ietf-avt-rtcp-feedback-07.txt) is
almost approved. The RTCP rate can be expected to jump up being
bandwidth limited instead of timer restricted. I think that AVT must
look at this problem of how to combine the DCCP congestion control with
the desired limitations on RTCP. Further I don't think that RTCP is as
redundant as the text indicates. RTCP has also other functionalities. Of
course the transport related feedback will in DCCP just as well being
fetched from the DCCP stack.

P14. Section 15. Second last paragraph: I don't like this suggestion
that a CCID may utilize the RTP sequence number. I think this is a bad
idea due to the possibilities of failure it can result in. The first
problem is for DCCP to know that it transports RTP. There is no protocol
identifier or something clearly marking it as such. Also how should it
be distinguished from RTCP? A further comment is that the recovery of
the RTP sequence number will not be possible unless the RTP packets are
sent in strict RTP sequence number order. This can't be guaranteed. There are already bad implementations that do packet level repetition without increasing the RTP sequence number as it should. There are also
possibilities that RTP sequence numbers are sent out of order on purpose. Therefore I would strongly argue that this proposal for using the RTP sequence number to be removed.

P15. Section 17. I think the IANA section is missing some fields and
their possible values. The Drop states is not completely full and seems
at least possible to be extended in the future. The Packet types should
also have their own repository. I could also think the IANA section
could be more complete and give more information about the registration
rules for each repository. Especially the service names should have a
better explained strategy for registration. The others I assume are all
IETF standards track specification needed.

P16. Section 23.1, last paragraph. I don't like the suggestion that
dropping packets due to that the ACK vector is to small is a okay
strategy. I think the application would be might upset with an
implementation that follow this suggestion. I can understand it as a last ditch effort, due to out of memory or something similarly almost fatal condition.

Editorial comments
------------------

E1. The short copyright message is missing between Status of this memo
and abstract. read ID-nits.

E2. Abstract, last sentence. I would like to see some more use cases for
DCCP be present in the abstract, like on-line gaming.

E3. Changes section, page 2: How can PMTU discovery be MORE mandatory?
The comment seems strange.

E4. Concepts and Terminology: Why is not a definition of how to handle
reserved bits part of this section? Any bit defined as reserver is
normally MUST be set to 0, SHOULD be ignored. Stating this upfront as a
common policy will simplify the document and remove any ambiguity, if
one otherwise forgot to declare them.

E5. Section 4.1.1, bullet list. In this list there are references to
"its data packets". I think this becomes a bit unclear in what direction
the packets go.

E6. There is some sentences that has two spaces before them, other that
has not. I would suggest that you are more consistent in the usage of
either of the methods. Having two is of course the recommended based on
the ID-nits.

E7. Section 5.1, CCval: In the last sentence starts with "DCCP proper
..." Not being a native english speaker I have a hard time understanding
what you mean with "DCCP proper", the dictionary did not help much as
several explanations seems possible. I would ask the authors to restrain
themselves from using difficult or ambiguous terms.

E8. Section 5.1 Checksum: The use of left and right when talking about
bit fields should be avoided I think, isn't is better to talk about MSB
and LSB? At least explain how you envision the representation, that the
most significant bit is always to the left in section 3.

E9. Section 5.1 Checksum: Last paragraph, first sentence: I find this
somewhat ambiguous, as there is a payload checksum options, I would
prefer that the sentence be rephrased to point out that it is the header
checksum that is the important one.

E10. Section 5.3, the state table: What is missing an explanation to
what the different states are. Now one can find some explanations later,
but it is really fragmented. Please add a explanatory list of the
states.

E11. Section 5.3, The missing figure, I believe the missing figure in
the text version makes significant difference and needs to be resolved.

E12. Section 5.4, page 22, second last paragraph in section: The last
sentence makes a reference to how you retransmit TCP SYNs. I think this
can result in ambiguities or mistakes. Either the definition can be
directly referenced in a TCP specification, or a normative if necessary
text should be added here. It should not be necessary to be TCP master
to implement the protocol.

E13. Section 5.5, Page 24, Second paragraph: This paragraph uses the
sender and receiver to indicate which end-point is doing what. I
assume that you mean HC-receiver and HC-sender. Using the defined terms
would be better.

E14. Section 5.7, First paragraph, last sentence. This reference section
5.3 for information. In my opinion this paragraph provides more
information about this state then what is present in 5.3.

E15. Section 6: Please clarify directly that the combination of all DCCP
options MUST be 32 bit aligned.

E16. Section 6.2, Second paragraph. "Ignored options SHOULD be sent only
on packets that contain Acknowlegement numbers ...", there seem to be an
error here. I guess that you mean that the option should only be sent in
in packets that has Acknowledgement numbers.

E17. Section 6.3.3, first sentence: Seem to be an error, the prefer
option should be sent from A->B for features that are located at A, not
B.

E18. Section 6.3.3, Third sentence: What is an relevant response?

E19. Section 6.3.3, Fourth sentence: I think a little bit more
informative text about the two usages of Prefer is desirable. With the
two use cases I mean to try to get the other end-point to change a
feature located at me, and as a response to a not agreeable change
option.

E20. Section 6.4.3: I don't think that phrasing of the sentence "The
Identification data provided for the MD5 Regime consists of a 16-byte
MD5 digest of: the second and fourth 32-bit words in the generic DCCP
header," is correct, as the generic header doesn't contain a fourth 32
bit word. I assume the intent it as pointed out to include the
acknowledgement number. However this is not there for all packet types.

E21. Section 6.5: I think one should be clearer that the INIT cookie
can't be longer than 255 bytes due to the option length field.

E22. Section 6.7, second paragraph: "If Elapsed time is less than a
second, the first, more parsimonious form of the option SHOULD be used."
I should thank you for making me learn one more word as parsimonious
was not in my vocabulary before. However I think this is another word
that might be a bit difficult to understand for non-native english
readers.

E23. Section 15, second paragraph on page 70: "While RTP receiver
reports ..." I guess that this should be RTCP.

E24. Section 21. The RFC 1889 reference should be replaced as soon as
the new RFC becomes available, which is hopefully just a few weeks away.
It is at least something that will need to be updated before
publication.

E25. This draft is missing the Copyright and IPR sections.


Best Regards


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info: https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html