Subject: [secdir] secdir review of draft-ietf-pwe3-p2mp-pw-requirements-09

From: Tobias Gondrom <[email-masked]>
Date: Sun, 25 May 2014 20:02:34 +0100

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.

The draft is informational and about requirements and a framework for
Point-to-Multipoint Pseudowire (PW) over MPLS Packet Switched Networks.

The document appears ready for publication.

A couple of comments:
1. Even though this document is only about requirements, it uses in a
couple of places 2119 language.
In principle that could even been seen as improving "readability",
however, I am not sure whether that is appropriate usage for a
requirement document, as 2119 is intended to signal conformance with a
specification (which this ID is not).

2. The security consideration section is basically empty, only referring
to RFC3916 and P2P PW. Considering that this is only a requirements
document, this can be sufficient.
(Note: it could have been nice to think about whether or how a move from
P2P to P2MP PW might change or require additional security requirements
for the specification. However, as this is only the requirements
document and not the specification, this question can also be answered
in the following spec.)

3. Nits:
section 5 security considerations:
should have a reference for "initial P2P PW definition"

Thank you and best regards.

Tobias

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 31 May 2014 13:46:27 +0100

The draft is standards track and describes how the default topology
plugin of RELOAD can be extended to support self-tuning, that is, to
adapt to changing operating conditions such as churn and network size.
It extends the mandatory-to-implement chord-reload algorithm by making
it self-tuning.

With one note for the IESG: This security review did only consider this
specification, but did not verify the scientific data and research that
lead to this algorithm.

The Security Consideration Section 8 seems appropriate for the draft. It
also refers to the security considerations of RFC6940 (RELOAD Base). 

One personal question to the authors:
In section 8 and 6.5, you introduce the concept of "the statistical
mechanisms applied in Section 6.5 (i.e., the use of 75th percentiles) to
process the shared estimates a peer obtains help ensuring that estimates
that are clearly different from..."
How did you determine the value of 75th percentile? Is this based on
research or experience or derived from some other estimates? Is this
choice influenced by number of peers or churn in certain environments.

Tobias