Telechat Review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-
review-ietf-ccamp-gmpls-ethernet-pbb-te-secdir-telechat-schoenwaelder-2010-10-10-00

Request Review of draft-ietf-ccamp-gmpls-ethernet-pbb-te
Requested rev. no specific revision (document currently at 06)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2010-09-07
Requested 2010-09-03
Draft last updated 2010-10-10
Completed reviews Secdir Last Call review of -?? by Jürgen Schönwälder
Secdir Telechat review of -?? by Jürgen Schönwälder
Assignment Reviewer Jürgen Schönwälder
State Completed
Review review-ietf-ccamp-gmpls-ethernet-pbb-te-secdir-telechat-schoenwaelder-2010-10-10
Review completed: 2010-10-10

Review
review-ietf-ccamp-gmpls-ethernet-pbb-te-secdir-telechat-schoenwaelder-2010-10-10

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.

I have reviewed -05 and my editorial comments have been addressed in
the -06 version. My other comments have apparently not been acted on
nor did I receive any response from the authors. The comments were:

  Security wise, this document essentially refers to other documents,
  namely RFC 4872 amd RFC 4873. These documents again refer to other
  documents and ultimately to IPsec as a security solution. If this is
  correct, perhaps this could be made clearer so people like me do not
  have to recursively resolve security considerations to find out how
  things are protected.

  The security considerations of this document also refer to 802.1AE
  Media Access Control Security for the protection of "transport"
  Ethernet. It is not clear what "transport" Ethernet is, perhaps it is
  the Ethernet traffic carried over the paths. If my interpretation is
  correct, I would argue that this pointer does not really belong into
  the security considerations of this document since this specification
  deals with a part of the signaling plane, not the data plane.

  Section 5 states that "configuration should be consistent". What
  happens security wise if configuration is not consistent? This might
  deserve some discussion in the security considerations.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <

http://www.jacobs-university.de/

>