Subject: [secdir] Secdir review of draft-ietf-rmt-bb-lct-revised-09

From: Catherine Meadows <[email-masked]>
Date: Thu, 2 Jul 2009 16:54:34 -0400

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: [email-masked]

---

From: "Watson, Mark" <[email-masked]>
Date: Wed, 8 Jul 2009 14:59:29 -0700

Hi Catherine,

Thanks for your comments. To addess them I propose a small re-write of the security section as shown below. Note that I am suggesting to remove the section on "Forged session description attacks" section as transport of session descriptions is not a service provided by LCT. Instead I added a new paragraph to the introduction and expanded a little (since the issue of securely verifying the correspondance between session description and session data packets was not addressed).

8. Security Considerations

LCT is a Building Block as defined in [RFC3048] and as such does not
define a complete protocol.  Protocol Instantiations which use the
LCT building block MUST address the potential vulnerabilities described
in the following sections.  For an example, see
[I-D.ietf-rmt-pi-alc-revised].

Protocol Instantiations could address the vulnerabilities described below
by taking measures to prevent receivers from accepting incorrect packets,
for example by using a source authentication and content integrity mechanism.

Note that for correct operation LCT assumes availability of session description information (see Section 4). Incorrect or maliciously modified session description information may result in receivers being unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. Protocol Instantiations MUST address this potential vulnerability, for example by providing source authentication and integrity mechanisms for the session description. Additionally, these mechanisms MUST allow the receivers to securely verify the correspondence between session description and LCT data packets.

The following sections consider further each of the services provided by LCT:

8.1  Session and object multiplexing and termination

The Transport Session Identifier, Transport Object Identifier in the LCT header provide for multiplexing of sessions and objects. Modification of these fields by an attacker could have the effect of depriving a session or object of data and potentially directing incorrect data to another session or object, in both cases effecting a denial-of-service attack.

Additionally, injection of forged packets with fake TSI or TOI values may cause receivers to allocate resources for additional sessions or objects, again potentially effecting a DoS attack.

The Close Object and Close Session bits in the LCT header provide for signaling of the end of a session or object. Modification of these fields by an attacker could cause receivers to incorrectly behave as if the session or object had ended, resulting in a denial-of-service attack, or conversely to continue to unnecessarily utilize resources after the session or object has ended (although resource utilisation in this case is largely an implementation issue).

As a result of the above vulnerabilities, these fields MUST be protected by Protocol Instantiation security mechanisms (for example source authentication and data integrity mechanisms).

8.2  Time synchronisation

The SCT and ERT mechanisms provide rudimentary time synchronization features
which can both be subject to attacks.  Indeed an attacker can easily de-synchronize
clients, sending erroneous SCT information, or mount a DoS attack by informing all
clients that the session (resp. a particular object) is about to be closed.

As a result of the above vulnerabilities, these fields MUST be protected by Protocol Instantiation security mechanisms (for example source authentication and data integrity mechanisms).

8.3  Data transport

The LCT protocol provides for transport of information for other Building Blocks, specifically the PSI field for the Protocol Instantiation, the Congestion Control field for the Congestion Control Building Block, the Codepoint field for the FEC Building Block, the EXT-AUTH Header Extension (used by the Protocol Instantiation) and the packet payload itself.

Modification of any of these fields by an attacker may result in a Denial-of-service attack. In particular, modification of the Codepoint or packet payload may prevent successful reconstruction or cause inaccurate reconstruction of large portions of an object by receivers. Modification of the Congestion Control field may cause receivers to attempt to receive at an incorrect rate, potentially worsening or causing a congestion situation and thereby effecting a DoS attack.

As a result of the above vulnerabilities, these fields MUST be protected by Protocol Instantiation security mechanisms (for example source authentication and data integrity mechanisms).

...Mark

On 7/2/09 1:54 PM, "Catherine Meadows" <[email-masked]> wrote:

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