FLUTE - File Delivery over Unidirectional Transport
draft-ietf-rmt-flute-08

[Ballot comment]
Draft: draft-ietf-rmt-flute-08
Reviewer: Scott W Brim
Date: 8 July 2004

This draft is ready for publication as an Experimental RFC.

I'd go with "no objection".  It's internally consistent.  I can't tell
if it's a good match to actual requirements, or if there is a better
match, and the security scenario is a little disturbing, but that all
just means it's a good match for Experimental.

[Note]: 'This is for RE-Review only - revised thoroughly to address Steve and Ted''s Discusses, and the comments by others.  Email on how the revision addressed the comments has been recorded in the comment log, and sent to Steve and Ted.
If it were new, it would be BLUE Team.' added by Allison Mankin

Responses to the Discusses and comments -

>
> 18 issues identified and responses below.
>
> ----------------------
>
> ISSUE #1
>
> 1) The draft needs a terminology section.  FEC, Asynchronous Layered =
> Coding,
>    would be good to define.  FEC should be expanded on its first use as =
> well.
>
>
> RESPONSE #1
>
> Advised by AD that it was not appropriate to add a separate terminology =
> section.  Suggest writing out "Forward Error Correction" at the first =
> use of FEC in the body of the document.
>
> ----------------------
> ----------------------
>
> ISSUE #2
>
> 2) Section 1.1.3, 2nd paragraph, last line:
>
>    Thus, the inherent raw scalability of FLUTE is unlimited.
>
> This seems unsubstantiated, I would suggest deleting this line.
>
>
> RESPONSE #2
>
> Suggest deleting "Thus, the inherent raw scalability of FLUTE is =
> unlimited." from Section 1.1.3.
>
> ----------------------
> ----------------------
> ISSUE #3
>
> less important:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 1) Odd formatting between UDP layer & Default LCT header in section 3.4:
>
>    |                                                              |
>    =
> +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
> =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+
>    |                Default LCT header (with TOI =3D 0)              |
>
> (I thought I was seeing double at first ...)
>
>
> RESPONSE #3
>
> Suggest changing this to the same style as fig. 1, Section 3.4, i.e., =
> "-+-+-+-".=20
>
> I ran out of time to really pick at the document thoroughly, but =
> otherwise
> the document seems in good order.
>
> ----------------------
> ----------------------
>
> ISSUE #4
>
> Steve Bellovin:
> Discuss:
> The Security Considerations should point to the MIME security
> considerations -- probably RFC 2048's, though 1521 has a better
> discussion.  In particular, while it's quite clear that FLUTE
> receivers shouldn't write to protected locations without a *lot* of
> authorization (is this a legitimately-signed patch file being
> distributed?), blithely listening to the extension can be dangerous,
> too.
>
>
> RESPONSE #4
>
> Suggest deleting the existing text:
>
>    Even more damaging, a malicious forger may spoof FDT Instance
>    packets, for example sending packets with erroneous FDT-Instance
>    fields.  Many attacks can follow this approach. For instance a
>    malicious attacker may alter the Content-Location field of TOI 'n',
>    to make it point to a system file or a user configuration file.
>    Then, TOI 'n' can carry a Trojan horse or some other type of virus.
>    It is thus RECOMMENDED that the FLUTE delivery service at the
>    receiver does not have write access to the system files or
>    directories, or any other critical areas. Another example is...
>
> And replacing with the new text:
>
>    Even more damaging, a malicious forger may spoof FDT Instance =
> packets, for example sending packets with erroneous FDT-Instance fields. =
> Many attacks can follow this approach. For instance a malicious attacker =
> may alter the Content-Location field of TOI 'n', to make it point to a =
> system file or a user configuration file. Then, TOI 'n' can carry a =
> Trojan Horse or some other type of virus. It is thus STRONGLY =
> RECOMMENDED that the FLUTE delivery service at the receiver does not =
> have write access to the system files or directories, or any other =
> critical areas. As described for MIME [REF:RFC2048] [REF:RFC1521], =
> special consideration should be paid to the security implications of any =
> MIME types that can cause the remote execution of any actions in the =
> recipient's environment.
>
>    Another example is...
>
> Also suggest adding these informative references:
>    * Freed, N., Klensin, J., Postel, J., "Multipurpose Internet Mail =
> Extensions (MIME) Part Four: Registration Procedures", RFC 2048, =
> November 1996.
>    * Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part =
> Three: Message Header Extensions for Non-ASCII Text", RFC 1521, November =
> 1996
>
> Question to AD: Please note that RFC 1521 is obsoleted by RFC 2048.  =
> However, as noted by Steve Bellovin, it contains more useful discussion. =
> Is it allowed to reference an obsolete RFC, when we also reference the =
> RFC that obsoletes it, in the same context?

*** It is ok to reference the obsoleted RFC - say something like
*** RFC 1521 describes important security issues for this environment,
*** even though its protocol is obsoleted by RFC 2048.

>
> ----------------------
> ----------------------
>
> ISSUE #5
>
> Ted Hardie:
> Discuss:
> This documents use of URIs needs review and rewrite.  For example:
>
>    As an example, let us consider a 5200 byte file referred to by
>    "www.ex.com/docs/file.txt". Using the example, the following
>    properties describe the properties that need to be conveyed by the
>    file delivery protocol.
>
>    *  Globally unique identifier of the file, expressed as either
>      absolute or relative URI. This is used as an identifier and
>      optionally also as a location for the file.  In the above example:
>      "www.ex.com/docs/file.txt".
>
> The string given is not a valid URI, since there is no scheme.  Nor is =
> there
> any guarantee that a random URI will be a "globally unique identifier", =
> and
> expecting any relative URI to be one doesn't make much sense.
>
>
> RESPONSE #5
>
> Suggest replacing the offending text with:
>    As an example, let us consider a 5200 byte file referred to by
>    "http://www.example.com/docs/file.txt". Using the example, the=20
>    following properties describe the properties that need to be=20
>    conveyed by the file delivery protocol.
>
>    *  Identifier of the file, expressed as a URI. This identifier
>      may be globally unique. The identifier may also provide a location
>      for the file. In the above example:
>      "http://www.example.com/docs/file.txt".
>
> And, to match Section 3.2, delete the following existing text:
>    "Each file description entry MUST include the TOI for the file that =
> it describes and the URI indicating the location of the file"
>
> and replacing with the following text:
>    "Each file description entry MUST include the TOI for the file that =
> it describes and the URI identifying the file"
>
> ----------------------
> ----------------------
>
> ISSUE #6
>
> The discussion in 3.4.2 on Content-length versus Transfer-length could
> benefit from a reading of RFC 3230, where Jeff Mogul went to great
> pains to describe "instances" vs. "entitites".  Something similar might
> be required here, and the authors might want to consider whether
> declaring a digest algorithm as it does for HTTP might be useful here.
> RFC3230 explains that HTTP (RFC).
>
>
> RESPONSE #6
> =20
> RFC 3230 indeed is good background and discussion.  However, the main =
> point of RFC 3230 is to distinguish between entity which is a piece of =
> content that is to be delivered to reconstruct the entire content and =
> the entity which is the entire content, and in FLUTE there is no notion =
> of delivering pieces of content, it is always the cases that the entire =
> content is delivered.  What the reviewer is discussing with respect to =
> the FLUTE document is the distinction between Content-Length and =
> Transfer-Length (where transfer length is the size of the actual =
> transferred object, which could for example be shorter than the original =
> object because of the use of compression.)  Reviewing RFC 3230, RFC =
> 2616, FLUTE (ALC & LCT) shows that RFC 3230 does not define a term for =
> Transfer-Length (it talks about Transfer-Length but does not suggest any =
> concept since FEC codes are used to encode the transferred object and =
> thus the receiver often needs to know the transfer length to properly =
> decode (depending on the FEC code used).=20
>
> Suggest deleting the following existing text in Section 3.4.2:=20
>
>    If the length of the file is described, the attribute =
> "Content-Length" MUST be used for the purpose as defined in [6]. If the =
> length of the file is different than the length of the transport object =
> that carries it (the file was content encoded before transport), another =
> attribute "Transfer-Length" MAY be used. The attribute "Transfer-Length" =
> specifies the size of the transport object in bytes.
>
> And replacing with the following text:
>
>    Where the length is described, the attribute "Content-Length" MUST be =
> used for the purpose as defined in [6]. The transfer length is defined =
> to be the length of the object transported in bytes.  It is often =
> important to convey the transfer length to receivers, because the FEC =
> codec is applied to the object that is transported, and to properly =
> decode the object the transfer length is often needed.  There generally =
> will be a difference between the length of the original file and the =
> transfer length if content encoding is applied to the file before =
> transport, and thus the "Content-Encoding" attribute is used.  If the =
> file is not content encoded before transport (and thus the =
> "Content-Encoding" attribute is not used) then the transfer length is =
> the length of the original file, and in this case the "Content-Length" =
> is also the transfer length. However, if the file is content encoded =
> before transport (and thus the "Content-Encoding attribute is used), =
> e.g., if compression is applied before transport to reduce the number of =
> bytes that need to be transferred, then the transfer length is generally =
> different than the length of the original file, and in this case the =
> attribute "Transfer-Length" MAY be used to carry the transfer length.
>
> Suggest replacing the following existing text also in Section 3.4.2:=20
>
>    *  If the MD5 message digest of the file is described, the attribute
>      "Content-MD5" MUST be used for the purpose as defined in [6].
> With the following new text:=20
>
>    *  If the MD5 message digest of the file is described (which is =
> computed from the original file, and not from the content encoded file =
> if content encoding is used), the attribute "Content-MD5" MUST be used =
> for the purpose as defined in [6].
>
>
> To help readability, we suggest expanding every abbreviated occurrence =
> of "instance" to the full "FDT Instance" (this is the only context in =
> which Instance is used in the document).
>
> ----------------------
> ----------------------
>
> ISSUE #7
>
> There are lots of ways in which the XML seems under-specified.  As an =
> example,
> the "Content-encoding" type is given as:
>
>                          type=3D"xs:string" use=3D"optional"/>
>
> As it stands, it is not clear whether just the Content-type or the =
> content type and its parameters should be included in this string, and =
> what effect the inclusion would have on mapping or equivalence.  Are =
> these really tokens, or are they being passed to other systems which are =
> expected to parse them?
>
>
> RESPONSE #7
>
> There seems to have been a copy and paste typo issue here.  This should =
> have read:
>
>    The "Content" type is given as:
>                                    type=3D"xs:string" use=3D"optional"/>
>    The "Content encoding" type is given as:
>                                    type=3D"xs:string" use=3D"optional"/>
>
> RFC 2822 (Internet Message Format) presents :. =
> The value of field name corresponds to the XML attribute name (e.g. =
> Content-Encoding) and the value of the field body corresponds to the XML =
> attribute value (of type xs:string). Thus the schema would validate this
>
> ...Content-Encoding=3D"gzip"... where the value is "gzip"
>
> Note, these references elaborate on XML usage (they are refered to in =
> FLUTE-07):
>    [8]  Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML =
> Schema Part 1: Structures", W3C Recommendation, May 2001.
>    [9]  Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C =
> Recommendation, May 2001.
>
> In terms of how to more fully-specify the XML we consider that adding =
> session level default values to be inherited by all objects (unless =
> overwritten by file specific data) would be a good idea. We also note =
> that there was an error in the complexType element of the schema (the =
> element declarations must be before attribute declarations).
>
> These result in this changed FDT schema in section 3.4.2:
>   
>                  xmlns:fl=3D"http://www.example.com/flute"=20
>              elementFormDefault:xs=3D"qualified"=20
>              targetNamespace:xs=3D"http://www.example.com/flute">
>   
>     
>     
>       
>       
>                                  type=3D"xs:anyURI"=20
>                        use=3D"required"/>
>                                  type=3D"xs:positiveInteger"=20
>                        use=3D"required"/>
>                                  type=3D"xs:unsignedLong"=20
>                        use=3D"optional"/>
>                                  type=3D"xs:unsignedLong"
>                        use=3D"optional"/>
>                                  type=3D"xs:string"=20
>                        use=3D"optional"/>
>                                  type=3D"xs:string"=20
>                        use=3D"optional"/>
>                                  type=3D"xs:base64Binary"=20
>                        use=3D"optional"/>
>                                  type=3D"xs:unsignedLong"=20
>                        use=3D"optional"/>
>                                  type=3D"xs:unsignedLong"=20
>                        use=3D"optional"/>
>                                  type=3D"xs:unsignedLong"=20
>                        use=3D"optional"/>
>                                  type=3D"xs:unsignedLong"=20
>                        use=3D"optional"/>
>                                  type=3D"xs:unsignedLong"=20
>                        use=3D"optional"/>
>         
>       
>       
>     
>                            type=3D"xs:string"=20
>                    use=3D"required"/>
>                            type=3D"xs:boolean"=20
>                    use=3D"optional"/>
>                            type=3D"xs:unsignedLong"=20
>                    use=3D"optional"/>
>                            type=3D"xs:unsignedLong"=20
>                    use=3D"optional"/>
>                            type=3D"xs:unsignedLong"=20
>                    use=3D"optional"/>
>                            type=3D"xs:unsignedLong"=20
>                    use=3D"optional"/>
>                            type=3D"xs:unsignedLong"=20
>                    use=3D"optional"/>
>     
>     
>   
>   
>
> Suggest adding this text supporting the changed schema as paragraph 3 of =
> section 3.4.2:
>    The "FDT-Instance" element MAY contain attributes that give common =
> parameters for all files of an FDT Instance. These attributes MAY also =
> be provided for individual files in the "File" element. Where the same =
> attribute appears in both the "FDT-Instance" and the "File" elements, =
> the value of the attribute provided in the "File" element takes =
> precedence.
>
> Suggest also replacing the following existing text in Section 3.4.2:
>    The attributes of "File" element in the XML structure represent the =
> attributes given to the file that is delivered in the file delivery =
> session. Each "File" element MUST contain at least two attributes "TOI" =
> and "Content-Location". "TOI" MUST be assigned a valid TOI value as =
> described in section 3.3 above. "Content-Location" MUST be assigned a =
> valid URI as defined in [6].
>
> With the following text:
>    The attributes of "File" element in the XML structure represent the =
> attributes given to the file that is delivered in the file delivery =
> session. The value of the XML attribute name corresponds to the MIME =
> field name and the XML attribute value corresponds to the value of the =
> MIME field body. Each "File" element MUST contain at least two =
> attributes "TOI" and "Content-Location". "TOI" MUST be assigned a valid =
> TOI value as described in section 3.3 above. "Content-Location" MUST be =
> assigned a valid URI as defined in [6].
>
> Suggest also replacing the following existing text in Section 3.4.2:
>    In addition to mandatory attributes, the "File" entity MAY contain
>    other attributes of which the following are specifically pointed out.
>    *  Where the MIME type is described, the attribute
>      "Content-Type" MUST be used for the purpose as defined in [6].
>
> Suggest also replacing the following existing text in Section 3.4.2:
>    *  If the content encoding scheme of the file is described, attribute
>      "Content-Encoding" MUST be used for the purpose as defined in [6].
>
>    *  If the MD5 message digest of the file is described, attribute
>      "Content-MD5" MUST be used for the purpose as defined in [6].
>
> With the following text:
>    *  Where the content encoding scheme is described, the attribute
>      "Content-Encoding" MUST be used for the purpose as defined in [6].
>
>    *  Where the MD5 message digest is described, the attribute
>      "Content-MD5" MUST be used for the purpose as defined in [6].
>
> Suggest also replacing the following existing text in Section 3.4.2:
>    In case the basic FDT XML Schema is extended in terms of new =
> descriptors, those MUST be placed within the attributes of the element =
> "File". It is RECOMMENDED that the new descriptors applied in the FDT =
> are in the format of MIME fields and are either defined in HTTP/1.1 =
> specification [6] or otherwise well-known specification.
>
> With the following text:
>    In case the basic FDT XML Schema is extended in terms of new =
> descriptors, for attributes applying to a single file, those MUST be =
> placed within the attributes of the element "File", and for attributes =
> applying to all files described by the current FDT Instance MUST be =
> placed within the element "FDT-Instance". It is RECOMMENDED that the new =
> descriptors applied in the FDT are in the format of MIME fields and are =
> either defined in HTTP/1.1 specification [6] or otherwise well-known =
> specification.
>
> Suggest also replacing the following existing text in Section 5.2
>    The FDT delivers FEC Object Transmission Information for each file =
> using an appropriate attribute within the "File" element of the FDT =
> structure. For future FEC Encoding IDs, if the attributes listed below =
> do not fulfil the needs of describing the FEC Object Transmission =
> Suggest also replacing the following existing text in Section 5.2
>    The FDT delivers FEC Object Transmission Information for each file =
> using an appropriate attribute within the "File" element of the FDT =
> structure. For future FEC Encoding IDs, if the attributes listed below =
> do not fulfil the needs of describing the FEC Object Transmission =
> Information then additional new attributes MAY be used.
>
>    *  "Transfer-Length" is semantically equivalent with the field =
> "Transfer Length" of EXT_FTI.
>
> With the following text:
>    The FDT delivers FEC Object Transmission Information for each file =
> using an appropriate attribute within the "FDT-Instance" or the "File" =
> element of the FDT structure. For future FEC Encoding IDs, if the =
> attributes listed below do not fulfill the needs of describing the FEC =
> Object Transmission Information then additional new attributes MAY be =
> used.
>
>    *  "Transfer-Length" is semantically equivalent with the field =
> "Transfer Length" of EXT_FTI.
>
>    *  "FEC-OTI-FEC-Encoding-ID" is semantically equivalent with the =
> field "FEC Encoding ID" as carried in the Codepoint field of the ALC/LCT =
> header.
>
> ----------------------
> ----------------------
>
> ISSUE #8
>
> This statement in that same section:
>
> Any XML document that conforms with the above XML Schema is a valid FDT.
>
> is exactly backward; any valid FDT must use that XML schema, but there =
> are
> lots of documents that use that schemat hat would not be valid FDTs, =
> because
> they would not be valid for file delivery.
>
>
> RESPONSE #8
>
> Suggest changing the offending sentence to "Any valid FDT Instance must =
> use the above XML Schema".
> ----------------------
> ----------------------
>
> ISSUE #9
> In section 6, this text:
>
>    How the receiver acquires the above-mentioned parameters is out of
>    scope of this document. The specification, in particular, does not
>    mandate or exclude any mechanism. The description can be conveyed to
>    the receiver via techniques such as Session Announcement Protocol
>    [11], email, accessing URL, manual configuration, etc. Similarly the
>    format of this session description is out of the scope of this
>    document.
>
> left me a bit cold.  This is an experimental doc, but the authors state
> that they plan to resubmit for standards track as soon as the congestion
> control is done.  Some description of how this is conveyed seems like it
> would be required before that next step, and hints of the general =
> strategy
> woudldn't be amiss even now.
>
>
> RESPONSE #9
>
> The history on this is that various versions of FLUTE had a discussion =
> of how receivers can receive the information they need to know about and =
> join a FLUTE session, first as a normative section, then as an =
> informative section, then as an informative appendix, and finally it was =
> dropped based on feedback from the RMT WG chairs and the MMUSIC chairs, =
> jointly.  The eventual goal is to propose one standardized way of doing =
> this in MMUSIC, but not restrict it to that way in the FLUTE document =
> since leaving open a variety of ways of delivering the initial session =
> information is very useful in practice and restricting it will only =
> restrict the deployment of FLUTE in various environments.  To warm it =
> up a bit, suggest changing the above cited text to the following:=20
>
>    It is envisioned that these parameters would be described according =
> to some session description syntax (such as SDP [REF:SDP] or XML based) =
> and held in a resource which would be acquired by the receiver before =
> the FLUTE session begins by means of some transport protocol (such as =
> Session Announcement Protocol [11], email, HTTP, SIP [REF:SIP], manual =
> pre-configuration, etc.) However, the way in which the receiver =
> discovers the above-mentioned parameters is out of scope of this =
> document, as it is for LCT and ALC. In particular, this specification =
> does not mandate or exclude any mechanism.
>
> Also suggest adding these informative references:
>    * Handley, M., Jacobson, V., "SDP: Session Description Protocol", RFC =
> 2327, April 1998
>    * Rosenberg, J., Schulzrinne H., Camarillo, G., Johnston, A. R., =
> Peterson, J., Sparks, R., Handley, M., and Schooler, E., "SIP: session =
> initiation protocol," RFC 3261, Internet Engineering Task Force, June =
> 2002.
>
> ----------------------
> ----------------------
>
> ISSUE #10
> As a purely non-blocking statement of personal preference, this document =
> has
> a *lot* of marketing in it for an experimental protocol.  Toning it down =
> a
> bit might help the readability of the document.

*** I think the marketing is fixed by deleting the one sentence.
>
>
> RESPONSE #10
>
> As noted in Issue #2 in Section 1.1.3, suggest deleting the sentence =
> "Thus, the inherent raw scalability of FLUTE is unlimited.". The target =
> is for proposed standard so generally we want the level of background =
> information to reflect this.  If there is any other offending marketing =
> type information then please identify it and we will look at it and =
> consider deleting it.=20
>
> ----------------------
> ----------------------
>
> ISSUE #11
> Russ Housley:
> Comment:
>  The security considerations begin with:
>  >
>  > The same security consideration that apply to ALC and to the LCT, =
> FEC
>  > and the congestion control building block used in conjunction with
>  > FLUTE also apply to FLUTE.
>  >
>  Pointers to the documents that contain the appropriate security
>  considerations would be very helpful.
> RESPONSE #11
>
> Suggest adding the pointers to the ALC, LCT and FEC documents and to =
> explicitly mention the security sections in these documents.  Thus, the =
> above text would be replaced with:
>
>  The security considerations that apply to, and are described in,
>  ALC [2], LCT [3], and FEC [4] also apply to FLUTE.  In addition,
>  any security considerations that apply to any congestion=20
>  control building block used in conjunction with FLUTE also apply to =
> FLUTE.
>
> ----------------------
> ----------------------
>
> ISSUE #12
>  Please give the 'Statement of Intent' portion of the Introduction
>  a subsection number.
>
>
> RESPONSE #12
>
> Advised by AD that it was not appropriate to do this.
>
> ----------------------
> ----------------------
>
> ISSUE #13
>  Please spell out FEC the first time it is used.
>
>
> RESPONSE #13
>
> See response to Issue #1, (i.e. suggest doing this.)
>
> ----------------------
> ----------------------
>
> ISSUE #14
>  Please use 'example.com' instead of 'ex.com'
>
>
> RESPONSE #14
>
> Suggest doing this.
>
> ----------------------
> ----------------------
> ----------------------
>
> ISSUE #15
>  Please change 'SMIME' to 'S/MIME'
>
>
> RESPONSE #15
>
> Suggest doing this.
>
> ----------------------
> ----------------------
>
> ISSUE #16
>  Please change 'Trojan horse' to 'Trojan Horse'
>
>
> RESPONSE #16
>
> Suggest doing this.
>
> ----------------------
> ----------------------
> ----------------------
> ----------------------
>
> ISSUE #17
> Allison Mankin:
> Discuss:
> 1.
> Even though this is an Experimental, we know that
> there is going to be deployment due to the adoption
> by 3GPP.  Most of the Security Considerations risks
> are in the category of attacks against the protocol,
> but this one is a very bad attack using the protocol,
> and amplified due to its scale:
>
>    Even more damaging, a malicious forger may spoof FDT Instance
>    packets, for example sending packets with erroneous FDT-Instance
>    fields.  Many attacks can follow this approach. For instance a
>    malicious attacker may alter the Content-Location field of TOI 'n',
>    to make it point to a system file or a user configuration file.
>    Then, TOI 'n' can carry a Trojan horse or some other type of virus.
>    It is thus RECOMMENDED that the FLUTE delivery service at the
>    receiver does not have write access to the system files or
>    directories, or any other critical areas.
>
> Though the protocol is Experimental, this RECOMMENDED needs to
> be a STRONGLY RECOMMENDED at least.  Better, why not add a
> tamper-prevention feature to the Content-Location field of TOI=20
> 'n'?  My point is orthogonal to Steve Bellovin's though it's
> one of points in the document to fix for his as well. =20
> Btw, on his Discuss, I agree with him that RFC 1521 is the=20
> better resource.
>
>
> RESPONSE #17
>
> Suggest changing "RECOMMENDED" to "STRONGLY RECOMMENDED".
>
> Tamper-prevention is an important issue in several cases. Section 3 =
> describes an example of using XML-DSIG to sign and authenticate the FDT =
> Instance. The Content-Location field can be protected thus. We don't =
> think further details belong in FLUTE but we wish to study this more and =
> return to the issue for propsed standard. In the meantime, the 3GPP =
> (MBMS) use of FLUTE could only suffer from tampering within the trusted =
> sender's domain and will specify security at other layers to deal with =
> (the reasonably low risk of) faked operator base-station signals.
>
> ----------------------
> ISSUE #18
> 2.
> Scoping the TSI by the source address - change it
> to be scoped by the source FQDN rather than IP address?
> It's not a good idea for the application level to
> have an awareness of IP addresses, because routing
> (even mcast) may be working over systems with
> translation issues (6to4 multicast, later multi6), or there
> may be NAT hacks...apps should be insulated from any
> of this.

*** issues acknowledged.
>
>
> RESPONSE #18
>
> It does not seem appropriate to scope the session by a FQDN, as this is =
> more of an application concept and not a transport concept, and FLUTE is =
> transport.  Furthermore, this would still require the receiver to =
> understand which packets came from which FQDN, and this is not possible =
> for receivers to do since they see IP addresses in packets, not an FQDN =
> (and it would be a radical change to an FQDN into packets).  =
> Furthermore, this is also the same issue for using SSM: the receiver =
> would have to send an IGMP join message to some globally known address, =
> and if the sender is behind a NAT or if  there is IPv6 to IPv4 =
> conversion then still the receiver would have to know the global address =
> of the sender that is advertised by the NAT or the IPv4 address in any =
> case.  Thus, the suggested resolution of this is to insert the following =
> further clarification on what the global sender IP address is (which =
> should also be the same for SSM, and it is suggested that this same =
> clarification be made at some future point in the ALC/LCT =
> specifications):
>
>    If the sender is not assigned a permanent IP address accessible to =
> receivers, but instead packets that can be received by receivers contain =
> a temporary IP address for packets sent by the sender, then the TSI is =
> scoped by this temporary IP address of the sender for the duration of =
> the session. As an example, the sender may be behind a Network Address =
> Translation (NAT) device that temporarily assigns an IP address for the =
> sender that is accessible to receivers, and in this case the TSI is =
> scoped by the temporary IP address assigned by the NAT that will appear =
> in packets received by the receiver.  As another example, the sender may =
> send its original packets using IPv6, but some portions of the network =
> may not be IPv6 capable and thus there may be an IPv6 to IPv4 translator =
> that changes the IP address of the packets to a different IPv4 address.  =
> In this case, receivers in the IPv4 portion of the network will receive =
> packets containing the IPv4 address, and thus the TSI for them is scoped =
> by the IPv4 address. How the IP address of the sender to be used to =
> scope the session by receivers is delivered to receivers, whether it is =
> a permanent IP address or a temporary IP address, is outside the scope =
> of this document.

[Note]: 'This is for RE-REVIEW only - revised thoroughly to address Steve and Ted''s Discusses.  Email on how the revision addressed the comments has been recorded in the comment log.  This is a Critical deliverable for 3GPP so they have asked for an Expedited publication.
If it were new, it would be BLUE Team.' added by Allison Mankin

[Note]: 'This is for RE-REVIEW only - revised thoroughly to address Steve and Ted''s Discusses.  Email on how the revision addressed the comments has been recorded in the comment log.  This is a Critical deliverable for 3GPP so they have asked for an Expedited publication.
If it were new, it would be BLUE Team.' added by Allison Mankin

[Note]: 'Reviews and direction sent to authors/chairs, and acked by them (2004-02-09) - my AD Review comments added in to the IESG Discusses.' added by Allison Mankin

[Ballot discuss]
1.
Even though this is an Experimental, we know that
there is going to be deployment due to the adoption
by 3GPP.  Most of the Security Considerations risks
are in the category of attacks against the protocol,
but this one is a very bad attack using the protocol,
and amplified due to its scale:

  Even more damaging, a malicious forger may spoof FDT Instance
  packets, for example sending packets with erroneous FDT-Instance
  fields.  Many attacks can follow this approach. For instance a
  malicious attacker may alter the Content-Location field of TOI 'n',
  to make it point to a system file or a user configuration file.
  Then, TOI 'n' can carry a Trojan horse or some other type of virus.
  It is thus RECOMMENDED that the FLUTE delivery service at the
  receiver does not have write access to the system files or
  directories, or any other critical areas.

Though the protocol is Experimental, this RECOMMENDED needs to
be a STRONGLY RECOMMENDED at least.  Better, why not add a
tamper-prevention feature to the Content-Location field of TOI
'n'?  My point is orthogonal to Steve Bellovin's though it's
one of points in the document to fix for his as well.
Btw, on his Discuss, I agree with him that RFC 1521 is the
better resource.


2.
Scoping the TSI by the source address - change it
to be scoped by the source FQDN rather than IP address?
It's not a good idea for the application level to
have an awareness of IP addresses, because routing
(even mcast) may be working over systems with
translation issues (6to4 multicast, later multi6), or there
may be NAT hacks...apps should be insulated from any
of this.

[Ballot discuss]
1.
Even though this is an Experimental, we know that
there is going to be deployment due to the adoption
by 3GPP.  Most of the Security Considerations risks
are in the category of attacks against the protocol,
but this one is a very bad attack using the protocol,
and amplified due to its scale:

  Even more damaging, a malicious forger may spoof FDT Instance
  packets, for example sending packets with erroneous FDT-Instance
  fields.  Many attacks can follow this approach. For instance a
  malicious attacker may alter the Content-Location field of TOI 'n',
  to make it point to a system file or a user configuration file.
  Then, TOI 'n' can carry a Trojan horse or some other type of virus.
  It is thus RECOMMENDED that the FLUTE delivery service at the
  receiver does not have write access to the system files or
  directories, or any other critical areas.

While the protocol is Experimental, this RECOMMENDED needs to
be a MUST, I believe.  Better, can you add a tamper-prevention
feature to the Content-Location field of TOI 'n' now?

I think the Sec ADs missed this because they didn't have
the awareness of the potential wide deployment.

2.
Scoping the TSI by the source address - change it
to be scoped by the source FQDN rather than IP address?
It's not a good idea for the application level to
have an awareness of IP addresses, because routing
(even mcast) may be working over systems with
translation issues (6to4 multicast, later multi6), or there
may be NAT hacks...apps should be insulated from any
of this.

[Ballot discuss]
1.
Even though this is an Experimental, we know that
there is going to be deployment due to the adoption
by 3GPP.  Most of the Security Considerations risks
are in the category of attacks against the protocol,
but this one is a very bad attack using the protocol,
and amplified due to its scale:

  Even more damaging, a malicious forger may spoof FDT Instance
  packets, for example sending packets with erroneous FDT-Instance
  fields.  Many attacks can follow this approach. For instance a
  malicious attacker may alter the Content-Location field of TOI 'n',
  to make it point to a system file or a user configuration file.
  Then, TOI 'n' can carry a Trojan horse or some other type of virus.
  It is thus RECOMMENDED that the FLUTE delivery service at the
  receiver does not have write access to the system files or
  directories, or any other critical areas.

While the protocol is Experimental, this RECOMMENDED needs to
be a MUST, I believe.  Better, can you add a tamper-prevention
feature to the Content-Location field of TOI 'n' now?

I think the Sec ADs missed this because they didn't have
the awareness of the potential wide deployment.

2.
Scoping the TSI by the source address - change it
to be scoped by the source FQDN rather than IP address?
It's not a good idea for the application level to
have an awareness of IP addresses, because routing
(even mcast) may be working over systems with
translation issues (6to4 multicast, later multi6), or there
may be NAT hacks...apps should be insulated from any
of this.

[Ballot comment]
The security considerations begin with:
  >
  > The same security consideration that apply to ALC and to the LCT, FEC
  > and the congestion control building block used in conjunction with
  > FLUTE also apply to FLUTE.
  >
  Pointers to the documents that contain the appropriate security
  considerations would be very helpful.

  Please give the 'Statement of Intent' portion of the Introduction
  a subsection number.

  Please spell out FEC the first time it is used.

  Please use 'example.com' instead of 'ex.com'

  Please change 'SMIME' to 'S/MIME'

  Please change 'Trojan horse' to 'Trojan Horse'

[Ballot comment]
From Gen-ART reviewer John Loughney:

It seems that this document is in good shape.  It is well written. Security Considersations seems to be quite thorough.
Boiler plate is in good order.

I would recommend the following changes:

Fairly important:
=================
1) The draft needs a terminology section.  FEC, Asynchronous Layered Coding,
  would be good to define.  FEC should be expanded on its first use as well.

2) Section 1.1.3, 2nd paragraph, last line:

Thus, the inherent raw scalability of FLUTE is unlimited.

  This seems unsubstantiated, I would suggest deleting this line.


less important:
==============
1) Odd formatting between UDP layer & Default LCT header in section 3.4:

  |                                                              |
  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  |                Default LCT header (with TOI = 0)              |

(I thought I was seeing double at first ...)

I ran out of time to really pick at the document thoroughly, but otherwise
the document seems in good order.

[Ballot discuss]
The Security Considerations should point to the MIME security considerations -- probably RFC 2048's, though 1521 has a better discussion.  In particular, while it's quite clear that FLUTE receivers shouldn't write to protected locations without a *lot* of authorization (is this a legitimately-signed patch file being distributed?), blithely listening to the extension can be dangerous, too.

[Ballot discuss]
This documents use of URIs needs review and rewrite.  For example:

    As an example, let us consider a 5200 byte file referred to by
  "www.ex.com/docs/file.txt". Using the example, the following
  properties describe the properties that need to be conveyed by the
  file delivery protocol.

  *  Globally unique identifier of the file, expressed as either
      absolute or relative URI. This is used as an identifier and
      optionally also as a location for the file.  In the above example:
      "www.ex.com/docs/file.txt".

The string given is not a valid URI, since there is no scheme.  Nor is there
any guarantee that a random URI will be a "globally unique identifier", and
expecting any relative URI to be one doesn't make much sense.

The discussion in 3.4.2 on Content-length versus Transfer-length could
benefit from a reading of RFC 3230, where Jeff Mogul went to great
pains to describe "instances" vs. "entitites".  Something similar might
be required here, and the authors might want to consider whether
declaring a digest algorithm as it does for HTTP might be useful here.

There are lots of ways in which the the XML seems under-specified.  As an example,
the "Content-encoding" type is given as:



As it stands, it is not clear whether just the Content-type or the content type and its
parameters should be included in this string, and what effect the inclusion would have
on mapping or equivalence.  Are these really tokens, or are they being passed to
other systems which are expected to parse them?

This statement in that same section:

Any XML document that conforms with the above XML Schema is a valid FDT.

is exactly backward; any valid FDT must use that XML schema, but there are
lots of documents that use that schemat hat would not be valid FDTs, because
they would not be valid for file delivery.

In section 6, this text:

  How the receiver acquires the above-mentioned parameters is out of
  scope of this document. The specification, in particular, does not
  mandate or exclude any mechanism. The description can be conveyed to
  the receiver via techniques such as Session Announcement Protocol
  [11], email, accessing URL, manual configuration, etc. Similarly the
  format of this session description is out of the scope of this
  document.

left me a bit cold.  This is an experimental doc, but the authors state
that they plan to resubmit for standards track as soon as the congestion
control is done.  Some description of how this is conveyed seems like it
would be required before that next step, and hints of the general strategy
woudldn't be amiss even now.

As a purely non-blocking statement of personal preference, this document has
a *lot* of marketing in it for an experimental protocol.  Toning it down a
bit might help the readability of the document.

[Ballot discuss]
This documents use of URIs needs review and rewrite.  For example:

    As an example, let us consider a 5200 byte file referred to by
  "www.ex.com/docs/file.txt". Using the example, the following
  properties describe the properties that need to be conveyed by the
  file delivery protocol.

  *  Globally unique identifier of the file, expressed as either
      absolute or relative URI. This is used as an identifier and
      optionally also as a location for the file.  In the above example:
      "www.ex.com/docs/file.txt".

The string given is not a valid URI, since there is no scheme.  Nor is there
any guarantee that a random URI will be a "globally unique identifier, and
expecting any relative URI to be one doesn't make much sense.

The discussion in 3.4.2 on Content-length versus Transfer-length could
benefit from a reading of RFC 3230, where Jeff Mogul went to great
pains to describe "instances" vs. "entitites".  Something similar might
be required here.

There lots of ways in which the the XML seems under-specified.  As an example,
the "Content-encoding" type is given as:



As it stands, it is not clear whether just the Content-type or the content type and its
parameters should be included in this "string", and what effect the inclusion would have
on mapping or equivalence.

This statement:

Any XML document that conforms with the above XML Schema is a valid
  FDT.

is also exactly backward; any valid FDT must use that XML schema, but there are
lots of documents that use that schemat hat would not be valid FDTs, because
they would not be valid for file delivery.

In section 6, this text:

  How the receiver acquires the above-mentioned parameters is out of
  scope of this document. The specification, in particular, does not
  mandate or exclude any mechanism. The description can be conveyed to
  the receiver via techniques such as Session Announcement Protocol
  [11], email, accessing URL, manual configuration, etc. Similarly the
  format of this session description is out of the scope of this
  document.

kind of left me a bit cold.  This is an experimental doc, but the authors state
that they plan to resubmit for standards track as soon as the congestion
control is done.  Some description of how this is conveyed seems like it
would be required before that next step, and hints of the general strategy
woudldn't be amiss even now.

As a purely non-blocking statement of personal preference, this document has
a *lot* of marketing in it for an experimental protocol.  Toning it down a
bit might help the readability of the document.