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

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Jul 2007 11:15:29 -0600

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jul 2007 12:10:48 -0600

Hi Miguel:

Thanks for your attention to this review. A few additinoal comments inline.

Miguel Garcia wrote:

> Ok. We'll do. If you happen to have some detailed changes that you
> propose, please send them to me.

I did not have time to complete a copy-edit while reviewing the
document, but if I find the time I will send along some proposed fixes.

> Well, the draft can only briefly compare both mechanisms, and let
> implementors decide which one to use or implement, depending on the
> requirements the have. I have added the following sentence at the end of
> the paragraph the compares the two mechanisms:
> 
>         The
>     level of requirements in implementations decides which solution
>     meets the requirements.

Fair enough. Let the market decide. :)

> Fixed. I have added at the end of the indented text in Section 1.1:
> 
>             Essentially, such protocol should be able to
>         be negotiated on an SDP offer/answer exchange (<xref
>         target="RFC3264">RFC 3264 </xref>) and be able to carry
>         MIME objects between two endpoints.

And presumably use a reliable rather than lossy transport?

> Yes. The issue is not new, there have been concerns in the MMUSIC WG
> with respect the size of SDP, but not due to this draft, but due to the
> long list of SDP extensions, which in many cases are needed. Well,
> probably the solution to address these concerns (or relieve them) is to
> use SIP and TCP. Although this won't solve the issue, perhaps it
> mitigates the side effects.
> 
> Again, the size of SDP is an issue with or without this draft.

Agreed. Probably the issue needs to be addressed elsewhere (e.g., an
implementor's guide to SIP/SDP development).

> Why do you think this is not realistic? It is a common way of operation
> in MSRP. There is the concept of a logical MSRP session and the concept
> of a TCP connection. It is possible to instantiate several MSRP logical
> sessions that share the same TCP connection.
> 
> I would say that a direct TCP connection between two endpoints could
> share file transfer of several simultaneous files and instant message.
> The same would apply for a TCP connection established towards an MSRP
> relay.

Yes, as I said this is probably more of a deployment issue than a
specification issue.

> As indicated later, SDP is large with or without this draft. I don't
> dare to put a limit, because this limit depends on mostly the operating
> system. There is text suggesting to sanitize the received file name,
> including cropping the name. But on the sending size, I don't dare to
> place a limit. There are no limits in any of the other text fields in
> SIP or SDP either.

OK.

> Is it simpler? I don't know, I thought it would be simpler to send the
> file with the local time.
> 
> Also: whenever is possible, we have tried to express in SDP what is
> otherwise available in MIME headers. The date-param is an example of it.
> 
> So, if it is possible to use time zones with MIME headers, then we
> shouldn't convert them in SDP.

Ah, I hadn't realized this was a re-use of MIME headers. Carry on. :)

> No, your interpretation is not correct. MSRP requiries the 200 OK as a
> mechanism to acknowledge a next hop delivery.
> 
> But read again what the text says:
> 
> When chunking, notice that MSRP does not require to wait for a 200-class
> response for a chunk before sending the following one. Therefore, it is
> valid to send pipelined MSRP SEND requests containing chunks of the same
> MSRP message (the file). Section 9.1 (Offerer sends a file to the
> Answerer)  contains an example of a file transfer using pipelined MSRP
> requests.
> 
> This comes from a common implementation error that we saw in several
> implementations: they were all waiting for receiving a 200 OK for a
> chunk before sending the next chunk. This made the transfer of a file
> waaaaay too long, and unacceptable from the user's point of view. So the
> text just tries to say that implementations can send all the chunks one
> after each other and then sit down to wait for the 200 responses for
> each chunk. This is far more efficient. Figure 3 shows way of operation
> with two chunks.

OK.

> No, it doesn't. There have been discussions in the SIMPLE mailing list
> with respect the need for it. The MSRP authors and myself do not see the
> need for it. Those who advocate for this need, IMHO, seemed to have
> artificial implementation constraints that wanted to solve by signaling
>  such constraint.

I agree. Mostly I was just curious.

> Right... the idea is as follows:
> - The mechanism in the draft is backwards compatible with endpoints that
> implement vanilla SDP and MSRP, but not the SDP extensions of the draft
> - The use case that Section 8.7 consider is: The offerer implements the
> draft, so it implements MIME multipart and uses it. The answerer does
> not implement the draft, so it does not necessarily implements MIME
> multipart. The offer contains an icon, as a multipart attachment that
> makes the answerer to reject the offer. If the offer is repeated without
> an icon, and thus without a multipart, it will be understood by the
> answerer, although just the pure vanilla SDP, not the extensions defined
> by the draft.
> 
> I'll try to clarify the text.

Great, thanks.

> The text is mostly copied from RFC 3261. There is no guidance with the
> icon size. I would like to see even smaller sizes than 8 k. I have been
> able to create readable icons with about 700 bytes. But it is hard to
> say a figure.

True -- probably it is hard to provide exact guidance on this issue.

> ok, I will read these RFCs and see if there is something else that need
> to be added. In general, this is an extension to a number of existing
> protocols (mostly SDP, SDP/offer answer). So I don't believe we are
> introducing new security concerns above those introduced by these
> protocols.
> 
>>
> OK, I have added the following text:
> 
>        Once a file has been transferred the file receiver must take
>        care with it. Typically file transfer is a commonly used
>        mechanism for transmitting computer virus, spyware, and other
>        types of malware. File recipients should apply all possible
>        security technologies (e.g., antivirus, antispaware, etc.) to
>        dismiss the risk of damage at their host.

Yes, that's better. Whether end users will be smart is another question,
but at least we can encourage implementors to do the right thing.

> Certainly. It was obvious to me, perhaps we forgot it. I have added the
> following text:
> 
>        Prior to accepting a file transfer, the file receiver should
>        first verify the identity of the file sender, and perhaps, only
>        accept file transfers from trusted sources. Mechanisms to
>        verify the identity of the file sender depend on the high-level
>        protocol that carries the SDP, for example, <xref
>        target="RFC3261">SIP </xref>.

Better, thanks.

Peter

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 18 Jul 2007 15:16:53 +0300

Hi Peter:

Thank you for taking your time to review the draft. We will address your
comments in the next version of the document.

See some inline discussion.

Peter Saint-Andre wrote:
> which detract from the specification. I am sure that most of these From [email-masked] Thu Jul 19 08:32:42 2007
Date: Wed, 18 Jul 2007 15:16:53 +0300
From: Miguel Garcia <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked], [email-masked],
	[email-masked], [email-masked]
Subject: [APPS-REVIEW] Re: Review of draft-ietf-mmusic-file-transfer-mech-03

Hi Peter:

Thank you for taking your time to review the draft. We will address your
comments in the next version of the document.

See some inline discussion.

> see draft-peterson-informational-normativity.

Fixed

         The

As indicated later, SDP is large with or without this draft. I don't
dare to put a limit, because this limit depends on mostly the operating
system. There is text suggesting to sanitize the received file name,
including cropping the name. But onwould

> see draft-peterson-informational-normativity.

Fixed

         The

> one parameter of each type, since it is OPTIONAL to include any given

YES, thanks.

> multiple file transfer requests requiring human intervention)?

No. Remember that the SDP offer is carried in an INVITE request, which
already requires human intervention. A DoS attack cannot be considered
an alert to the user.

Also, most e-mail readers allow to configure automatic actions, if the
user desires to do so.

> Section 8). Why is bidirectional file transfer not allowed?

Because it would be a mess with the file descriptions, in the offer an
answer. It won't be possible to distinguish what is being sent in which
direction.

On the other hand, there is no use case for bidirectional transfer: a
file is physically located in one endpoint and is going to move to the
other endpoint. There is never a file that moves in both directions. But
there could be one file in each endpoint that is to be transferred to
the other endpoint, in which case, the simplest and cleanest mechanism
is the two unidirectional file transfers.

> attack (e.g., by sending a large number of file transfer requests).

See point 10 above.

> common media type, forcing the user to select from among a large number

See point 10 above.

> how does the quoted text help to prevent it?

The wording is fixed as you suggested.

The word downgrade does not have any security connotations. Instead, it 
is a way of speaking to indicate which value has precedence over another 
one in an enumeration. This has been used in the past in SIP related 
RFCs, so it should be ok for a person familiar with SIP.

> context of a file transfer specification.

To be consistent with the rest of the specification, I have replace it 
with "SDP file description".

> a lossy transport? If not, why not? If so, how does tha the sending size, I don't dare to

> one parameter of each type, since it is OPTIONAL to include any given

YES, thanks.

> multiple file transfer requests requiring human intervention)?

No. Remember that the SDP offer is carried in an INVITE request, which
already requires human intervention. A DoS attack cannot be considered
an alert to the user.

Also, most e-mail readers allow to configure automatic actions, if the
user desires to do so.

> Section 8). Why is bidirectional file transfer not allowed?

Because it would be a mess with the file descriptions, in the offer an
answer. It won't be possible to distinguish what is being sent in which
direction.

On the other hand, there is no use case for bidirectional transfer: a
file is physically located in one endpoint and is going to move to the
other endpoint. There is never a file that moves in both directions. But
there could be one file in each endpoint that is to be transferred to
the other endpoint, in which case, the simplest and cleanest mechanism
is the two unidirectional file transfers.

> attack (e.g., by sending a large number of file transfer requests).

See point 10 above.

> common media type, forcing the user to select from among a large number

See point 10 above.

> how does the quoted text help to prevent it?

The wording is fixed as you suggested.

The word downgrade does not have any security connotations. Instead, it 
is a way of speaking to indicate which value has precedence over another 
one in an enumeration. This has been used in the past in SIP related 
RFCs, so it should be ok for a person familiar with SIP.

> context of a file transfer specification.

To be consistent with the rest of the specification, I have replace it 
with "SDP file description".

ok, I will read these RFCs and see if there is something else that need 
to be added. In general, this is an extension to a number of existing 
protocols (mostly SDP, SDP/offer answer). So I don't believe we are 
introducing new security concerns above those introduced by these protocols.

        Once a file has been transferred the file receiver must take
        care with it. Typically file transfer is a commonly used
        mechanism for transmitting computer virus, spyt influence the

ok, I will read these RFCs and see if there is something else that need 
to be added. In general, this is an extension to a number of existing 
protocols (mostly SDP, SDP/offer answer). So I don't believe we are 
introducing new security concerns above those introduced by these protocols.

> Thanks.

Once more, thank you very much for your review.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 19 Jul 2007 09:21:04 +0300

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 19 Jul 2007 09:21:04 +0300

Hi Peter:

Just one more comment:

> And presumably use a reliable rather than lossy transport?

Yes, of course. I will add a reliable transport as well.

/Miguel

ubject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/apps-review>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/apps-review>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Hi Peter:

Just one more comment:

> And presumably use a reliable rather than lossy transport?

Yes, of course. I will add a reliable transport as well.

/Miguel