Last Call Review of draft-ietf-mpls-tp-oam-requirements-

Request Review of draft-ietf-mpls-tp-oam-requirements
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-10-06
Requested 2009-09-23
Authors Malcolm Betts, David Ward, Martin Vigoureux
Draft last updated 2009-10-08
Completed reviews Secdir Last Call review of -?? by Phillip Hallam-Baker
Assignment Reviewer Phillip Hallam-Baker 
State Completed
Review review-ietf-mpls-tp-oam-requirements-secdir-lc-hallam-baker-2009-10-08
Review completed: 2009-10-08


I am reviewing 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. Feel free to
forward to any appropriate forum.

This documents sets out requirements for Operations, Administration
and Maintenance of MPLS Transport Profile.

It is a high level architectural requirements document, intentionally
separated from the details of specific implementations. As such it is
appropriate for the security considerations section to be at a high

It is however a mystery to this reader why encryption is specified as
a should but integrity protections only merit a MAY. I would be much
more reassured by a document that ignores confidentiality issues
completely (as has been the general policy for low level routing &ct.)
and points out the fact that this is yet another opportunity for a
malicious party to play merry heck by introducing bogus data that
other parts of the network will then operate on.

For example, introduction of bogus messages would allow an attacker to
reserve excessive bandwidth in the name of another party, possibly
performing a DoS attack or possibly to perform a financial fraud,
causing some party to incur costs for bandwidth not required.

In comparison the confidentiality issues are rather minor, and in any
event almost certainly subsumed by the fact that anyone who can
observe the content of the OAM packets can almost certainly observe
the volumes of the data flows and infer that information. While
confidentiality is a nice to have, it is not worth much without

I suggest that the security considerations section makes the ability
to support integrity protections a MUST or SHOULD requirement. If only
a SHOULD is applied, confidentiality would be better demoted to MAY.

New Website:

View Quantum of Stupid podcasts, Tuesday and Thursday each week,