[secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.txt

[Juergen Schoenwaelder <[e-mail]>]

Hi,

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 document describes how GMPLS can be used to manage Ethernet
Switched Paths and TE (traffic engineering) Service Instances. As you
will see below, I am not at all familiar with the terminology and the
technology and all the acronyms used in the document.

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.

Editorial nits:

- Expland the acronym PBB-TE in the title

- Explain somewhere what I and B components are; what das I and B
  stand for?

- Explain what the TE in TESI stands for

- dangling ] in item 2) on page 11 (also make it clear that the RFC
  editor may need to adjust the value pending IANA's assignment
  action)

- It seems that several of the informative references are in fact
  normative; the citations in the document should all be carefully
  checked

- Can a reference be provided where the IEEE defines the set of
  reserved MAC addresses discussed in section 5.2?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir