MPLS Transport Profile (MPLS-TP) Security Framework
RFC 6941
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Stewart Bryant; former steering group member) Yes
(Barry Leiba; former steering group member) No Objection
Luyuan Fang handled all my comments during last call, so I have nothing left now. :-)
(Benoît Claise; former steering group member) No Objection
Minor editorial comment OLD Security reference model 1(a) An MPLS-TP network with Single Segment Pseudowire (SS-PW) from PE1 to PE2. The trusted zone is PE1 to PE2 as illustrated in Figure 1. NEW Security reference model 1(a) An MPLS-TP network with Single Segment Pseudowire (SS-PW) from PE1 to PE2. The trusted zone is PE1 to PE2 as illustrated in Figure 1.
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
1) s4: Contains the following: Authentication includes entity authentication for identity verification, encryption for confidentiality, management system authentication, peer-to-peer authentication, ... Now my head is full of cough medicine but does authentication really include encryption for confidentiality? Should that bit be struck from the sentence? 2) s4: r/authentication,the/authentication, the 3) For what it's worth I agree with Stephen's comments.
(Stephen Farrell; former steering group member) No Objection
I guess as an abstract framework there's not much to critique here, so feel free to take or leave the following comments. - I think you're right to focus on the NMS. I'm not sure if there's any way to validate what's going on from two independent points on the n/w using different vendor's kit, but that might be something to consider. - I think there's a missing threat, which is running insufficiently audited or even malicious vendor supplied (i.e. genuine) code on devices. Not all operators seem to be trusting of all vendors these days. - The inside==trusted; outside==there-be-dragons model is probably less useful than was once the case. Many "inside" systems end up being compromisable via e.g. laptops that get connected in the wrong places or USB sticks etc. While that ought not happen, it does. That does call into question the "full control" statements in section 2 here. Section 3 does however consider this to an extent. - The use of isolated infrastructure wasn't that effective in the face of a determined attacker in e.g. the case of stuxnet. And that was with an air gap reportedly, whereas use of "non-IP based communication paths" seems more like just security by obscurity.
(Wesley Eddy; former steering group member) No Objection