Re: [secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt

[Adrian Farrel <[e-mail]>]

Additions in-line...

---

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.

[DF] This is correct. This is also the way we have documented for some time 
with many documents referring backwards.  Ultimately for control plane it 
comes down to some form restricted access/private networks or some mechanism 
such as IPSec to protect public exposed portions of signaling.

[AF] I believe that RFC 5920 provides the global view that Juergen is 
looking for, and is referenced from the Security Section.

  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.

[DF] transport Ethernet is a term that we use to describe Ethernet 
technologies that offer similar service typically associated with L1 
transport networks (OAM (monitoring, tracing, integrity checking, fault 
signaling), protection switching). PBB-TE is one type of transport Ethernet. 
MACSEC can be used between the elements of the Ethernet network providing 
transport. If signaling is inland then MACSEC could be providing part of the 
security for the signaling. If the signaling is out of band over other 
technologies then IPSEC or other may ultimately be providing protection.

[AF] The term and concept are discussed in 
draft-ietf-ccamp-gmpls-ethernet-arch. Maybe a reference could be inserted?

  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.

[DF]  When configuration is not consistent it is normal for the connection 
simply not to come up.  The dual ended nature of the configuration requires 
the source must match the destination.  This draft is currently is covering 
PBB-TE which is defined for a single administrative domain so the result of 
the misconnection is that the signaling will report some form of failure 
through the management plane.

[DF] In my opinion these items have been covered at a level that is 
consistent with GMPLS documents in the past but if there additional text or 
clarification we need on any of these points please indicate and I will work 
with the authors, chairs and ADs to correct.

Regards,
Don


/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>