Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
RFC 6371
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
(Adrian Farrel; former steering group member) Yes
Three Directorate reviews have been addressed, but a few non-blocking comments remain that should be addressed to improve the document before it is published as an RFC: SecDir - vincent.roca@inrialpes.fr > However there's a (naive) question which you didn't answer: is it > realistic to assume the physical network can be secured? Are there > known weaknesses in the MPLS infrastructure? Nothing is said in > the I-D. > > Another point (from -10). It is said: > > However > it should be observed that the combination of the need for > timeliness of OAM transaction exchange and all permutations of > unique MEP to MEP, MEP to MIP, and intermediate system > originated transactions mitigates against the practical > establishment and maintenance of a large number of security > associations per MEG either in advance or as required. > > The reasons mentioned here to justify nothing is done is critical. > Only two reasons are listed: timeliness and combinatorial motivations. > In your answer you also mention the high transmission frequency of > heartbeats. This is not mentioned. Something else? GenArt - david.black@emc.com > The authors have addressed most of the items noted in the Gen-ART review > of the -09 version, but there is one item that could still use some attention. > From the original review: > > [D] The security considerations section should include specific mention > of injection of LKI request OAM packets as a vector for a denial-of-service > attack (this is an obvious way for a man-in-the-middle to quickly cause > serious havoc). That would be a good specific example to add to the end > of the current security considerations paragraph that requires the network > to be physically secure against man-in-the-middle attacks. > > This has not been done. While the security considerations section does > cover the countermeasures necessary to prevent this attack, I prefer security > considerations sections that include examples of things that can go badly > wrong when implementers don't pay attention when the examples are simple. > That preference is a matter of style/taste that I'll leave to the responsible AD's > judgment RtgDir - thomas.morin@orange-ftgroup.com > I replied to Dave Allan that my current > feeling, after going through today's revision of the OAM framework > document, is that the comments I made are only partially addressed.
(Dan Romascanu; former steering group member) No Objection
(Peter Saint-Andre; 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
The Gen-ART Review by David Black lead to some document updates. However, one comment was not addressed. Please consider updates to the security considerations section. David said: > > [D] The security considerations section should include specific > mention of injection of LKI request OAM packets as a vector for a > denial-of-service attack (this is an obvious way for a man-in-the- > middle to quickly cause serious havoc). That would be a good > specific example to add to the end of the current security > considerations paragraph that requires the network to be > physically secure against man-in-the-middle attacks. > While the security considerations section does cover the countermeasures necessary to prevent this attack, it seems like a good idea to document something that can go badly wrong when implementers do not pay attention.
(Sean Turner; former steering group member) No Objection
(Stewart Bryant; former steering group member) (was Discuss) No Objection
(Tim Polk; former steering group member) No Objection