[APPS-REVIEW] Review of draft-ietf-mmusic-file-transfer-mech-03

Review of: draft-ietf-mmusic-file-transfer-mech-03
By:        Peter Saint-Andre
Date:      2007-07-09

Eric Burger has asked me (as a member of Apps-Review team) to review the
I-D referenced above. Please note that such reviews have no special
weight within the Internet Standards Process. In completing this review,
I have attempted to follow some relevant guidelines as well as examples
of previous reviews, such as:

http://www.rfc-editor.org/rfc-editor/reviewer.guide.txt
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00019.html
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00028.html
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00029.html

Overall the document appears to be technically sound. Please take the
following comments in the spirit of suggestions.

1. The document contains numerous typographical and grammatical errors,
which detract from the specification. I am sure that most of these would
 be discovered by the RFC Editor team. However, in order to lighten
their load and reduce the number of AUTH48 changes, I would suggest
completing a thorough copy-edit before WGLC or IETF Last Call.

2. The bullet list of requirements in Section 1 contains the normative
term MUST. However, that term is reserved for normativity with regard to
protocol implementations, not specification requirements. For details,
see draft-peterson-informational-normativity.

3. In Section 1.1, the alternative of the SIP content indirection
mechanism (RFC 4483) is considered. Although the document provides a
list of difference between SIP content indirection and the defined file
transfer mechanism, the document does not provide a clear set of
guidelines to user agent developers in determining when it might be
preferable to use SIP content indirection and when it might be
preferable to use the defined file transfer mechanism.

4. In Section 1.1, the specification does not clearly explain why MSRP
(draft-ietf-simple-message-sessions) is the preferred transport
protocol. Furthermore, although the specification mentions that it is
possible to use similar protocols in place of MSRP, the specification
does not provide guidelines for choosing or developing such protocols.
Such guidelines would be helpful to those who might re-use (or gateway
to) the defined file transfer mechanism.

5. Section 4 mentions that the transfer of multiple simultaneous files
would require one SDP (RFC 4566) m= line per file. Might this result in
large SDP descriptions in certain scenarios?

6. Section 4 asserts that use of the defined file transfer mechanism to
transfer multiple files "will not lead to excessive use of transport
resources" because "multiple MSRP media streams can share a single
transport layer connection". It strikes me that this assertion may not
be realistic in deployments, depending on the number and size of files
being transferred.

7. According to the ABNF in Section 6, there is no limit to the length
of the filename string. Might this lead to excessively large SDP
descriptions?

8. The date-param attributes all include timezone offsets. Might it be
better (i.e., simpler to implement) if the document specified the use of
UTC instead?

9. Section 6 contains the following sentence:

   Only one parameter of each type (creation, modification, or read)
   MUST be present in a 'file-date' attribute.

I think you mean that a 'file-date' attribute MUST NOT contain more than
one parameter of each type, since it is OPTIONAL to include any given
parameter.

10. In Section 7, the specification mentions that the 'attachment'
disposition type indicates that presentation of a file to a human user
should be contingent upon some action by the user. Does this enable a
possible denial of service (DoS) attack against the user (by sending
multiple file transfer requests requiring human intervention)?

11. The only two modes allowed are "sendonly" and "recvonly" (see
Section 8). Why is bidirectional file transfer not allowed?

12. In Section 8.2.1, the specification suggests that whether the file
shall be accepted or rejected will typically depend on explicit action
by the file receiver. Here again there may be the potential for a DoS
attack (e.g., by sending a large number of file transfer requests).

13. In Section 8.2.2., user interaction is again suggested if the file
selector points to multiple candidate files. Here again there may be the
potential for a DoS attack (e.g., if the file selector specifies only a
common media type, forcing the user to select from among a large number
of candidate files).

14. Section 8.3 states that "An SDP answer that MUST not downgrade the
offered 'file-transfer' value." (BTW I think the word "that" is a typo
and that you mean to say "MUST NOT".) The use of the term "downgrade"
suggests that there is a possible attack here. What is the attack and
how does the quoted text help to prevent it?

15. Section 8.3 uses the phrase "SDP file". I think the phrase "SDP
description" is more accurate and less confusing, especially in the
context of a file transfer specification.

16. Section 8.6 states that when chunking is used, MSRP does not require
acknowledgements (200-class responses). Does this potentially result in
a lossy transport? If not, why not? If so, how does that influence the
ability to transfer a complete file?

17. Section 8.6 mentions a 'max-size' attribute for the file; does MSRP
also include the ability to set a maximum chunk size?

18. Section 8.7 states that compliant implementations MUST implement the
multipart/mix MIME type but then goes on to describe the behavior of
file receivers that do not support multipart MIME types; this is a bit
confusing so perhaps the text could be clarified here.

19. Section 8.7 states that if an icon (a.k.a. thumbprint) is sent as
part of the signalling, the size of the icon in bytes should be limited;
however, no suggested size limits are provided to guide developers. 8k
perhaps?

20. The Security Considerations provide no information about the
potential for denial of service attacks. See above. See also RFC 4732
and Section 4.6 of RFC 3552.

21. The Security Considerations provide no information about the
potential for the transmission of viruses and other malware over the
defined file transfer mechanism. Given that file transfer using other
technologies (e.g., multipart MIME email messages or file attachments)
commonly results in the transmission of malware, I think some text
regarding this threat is in order.

22. The Security Considerations provide no information about the need to
verify the identity of a sender before accepting an offer to transfer a
file (e.g., in order to avoid file transfers from unknown or malicious
users). This may be addressed at a lower layer or in another
specification (e.g., in RFC 3264 or RFC 3261), but it would be helpful
to make reference to the relevant specification here if possible. See
also Section 2.1.3 of RFC 3552.

Thanks.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

[APPS-REVIEW] Review of draft-ietf-mmusic-file-transfer-mech-03

Attachment: smime.p7s