Last Call Review of draft-ietf-mpls-tp-oam-framework-
review-ietf-mpls-tp-oam-framework-secdir-lc-roca-2010-12-16-00

Dear all,

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 Security Considerations section of this I-D is fairly strange.
The authors first highlight that OAM traffic contains sensitive
data (like passwords), and then quickly conclude that securing this
traffic is impossible and therefore they require that the network be
physically secured. The reason provided is the fact that there are
too many entities that are likely to communicate to establish and
maintain SAs between them.

Well, I don't know the specificities of MPLS networks, nor the
OAM operations in MPLS networks, however:
1- I need more information to be convinced that there is indeed no
   other solution than requiring that the whole physical network be
   totally secured;
2- I need more information to be convinced that fully securing such
   a physical network is feasible;

Honestly speaking I'm not convinced by 1-. What about solutions
based on temporary SA? Are the OAM exchanges so frequent to require
that each secure connection be maintained all the time? Would a
solution that establishes those connections on-the-fly, when needed,
be realistic? Another direction could be to use shared keys between
the entities of a group. Or perhaps using a per-packet signature
approach is feasible, using some public key infrastructure, if the
exchanges are infrequent. There are probably other IETF protocols
that have similar requirements. What about the KARP WG that focuses
on secure routing protocols? May some ideas be borrowed and applied
here (that's a fully open question)?

Concerning 2-, a quick search on "MPLS attacks" on the web provides
a small number of references. There's also a book on the subject
("Analyzing MPLS VPN Security", M. H. Behringer, M. Morrow, Cisco
Press, 2005). I don't known the domain at all but I'd like to be
convinced that 2- is feasible.


A minor comment.
I have the feeling that the authors use the term "man-in-the-middle
attack" to denote any attack where the attacker takes control of the
physical infrastructure. That's not an appropriate use and this term
refers to a very specific attack (e.g. see


http://en.wikipedia.org/wiki/Man-in-the-middle_attack

).

I hope these comments are useful.
Regards,

   Vincent