[secdir] secdir review of draft-ietf-mpls-ldp-p2mp-14

Tom Yu <tlyu@MIT.EDU> Mon, 04 July 2011 07:46 UTC

To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-ldp-p2mp.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Mon, 04 Jul 2011 03:46:03 -0400
Message-ID: <ldv8vsesd38.fsf@cathode-dark-space.mit.edu>
Lines: 32
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [secdir] secdir review of draft-ietf-mpls-ldp-p2mp-14
Precedence: list

This document extends the Label Distribution Protocol to support the
operation of Point-to-Multipoint and Multipoint-to-Multipoint
Label-Switched Paths.

The Security Considerations section states that the same security
considerations in RFC 5036 apply.  It also states that authorization
mechanisms for controlling which LSRs join a given MP LSP are out of
scope for this document.  These seem reasonable to me.

The protocol appears to be initiated by the receivers (egress nodes),
which could make the design of authorization mechanisms challenging.

The following comments are not directly security-related:

Section 2.4.1.1 (Determining one's 'upstream LSR') recommends using an
operation based on CRC32 for selecting among candidate upstream LSRs.
How important is it for the selection to be uniformly distributed?
CRC32 is known to have poor avalanche properties that might make it
unsuitable as a hash function, even for non-cryptographic purposes.

Also, there is often ambiguity when specifying the use of CRC32, even
if the particular generator polynomial (e.g., the ISO/IEC 3309 32-bit
FCS as specified in this document) is specified.  Some common
implementations omit the ones-preload and/or post-complement.  The
input bit ordering also needs to be specified when using CRC32 with a
byte-oriented protocol.  (as does the translation of the CRC remainder
bit vector into an integer to perform modulo operations when used as a
hash function)

Editorial:

* There is no normative reference for CRC32.

[secdir] secdir review of draft-ietf-mpls-ldp-p2m… Tom Yu