Skip to main content

Last Call Review of draft-ietf-rmt-bb-lct-revised-
review-ietf-rmt-bb-lct-revised-secdir-lc-meadows-2009-07-03-00

Request Review of draft-ietf-rmt-bb-lct-revised
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-04-15
Requested 2009-04-02
Authors Lorenzo Vicisano , Mark Watson , Michael Luby
I-D last updated 2009-07-03
Completed reviews Secdir Last Call review of -?? by Catherine Meadows
Assignment Reviewer Catherine Meadows
State Completed
Request Last Call review on draft-ietf-rmt-bb-lct-revised by Security Area Directorate Assigned
Completed 2009-07-03
review-ietf-rmt-bb-lct-revised-secdir-lc-meadows-2009-07-03-00
I have reviewed this document as part of the security directorate's

ongoing effort to review all IETF documents being processed by the

IESG.  These comments were written primarily for the benefit of the

security area directors.  Document editors and WG chairs should treat

these comments just like any other last call comments.

This paper concerns the Layered Coding Transport building block.  LCT provides

support for massively scalable protocols using the IP multicast network service.

LCT supports sessions
consisting or multiple channels, all with the same sender, but

many different receivers.  This makes it compatible with many massively scalable congestion

control protocols that use this structure.

When we are dealing with massively scalable congestion control protocols, the question

of denial of service naturally comes to mind.  Thus the security considerations section

rightly mainly concerns itself with that.  However, it left me with several questions.

1.  The introduction says that "Protocol Instantiations that use the LCT building block MUST

address the security requirements described in the following sections."   But there are no MUSTs

or MUST NOTs in the following sections.  Indeed,sections 8.1 and 8.2 don't contain any recommendations

at all; they simply identify vulnerabilities (which could, however, be addressed by authentication).
 I would

suggest either toning down the introduction ("MUST address the potential
vulnerabilities" instead of "MUST address

the requirements") or beef up the specific sections.

2.  The sections themselves have a kind of piecemeal feel about them,
addressing specific potential attacks, but

without giving a feeling that everything that is covered.  It might be a better
idea to describe what services security mechanisms

could provide (e.g. authentication, confidentiality) describe the various each
service offered by LCT and its vulnerabilities,

and then what security services would address.  I suspect, given the
vulnerabilities that the authors have already described, it

would mostly boil down to identifying which LCT data should or must be
authenticated.

Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942

email:

catherine.meadows at nrl.navy.mil