Last Call Review of draft-ietf-mpls-ldp-p2mp-

Request Review of draft-ietf-mpls-ldp-p2mp
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-07-12
Requested 2011-06-23
Authors Bob Thomas, IJsbrand Wijnands, Ina Minei, Kireeti Kompella
Draft last updated 2011-07-09
Completed reviews Secdir Last Call review of -?? by Taylor Yu
Assignment Reviewer Taylor Yu
State Completed
Review review-ietf-mpls-ldp-p2mp-secdir-lc-yu-2011-07-09
Review completed: 2011-07-09


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 (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)


* There is no normative reference for CRC32.