Last Call Review of draft-ietf-ippm-more-twamp-

Request Review of draft-ietf-ippm-more-twamp
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-06-16
Requested 2009-05-13
Authors Al Morton, Kaynam Hedayat
Draft last updated 2009-06-05
Completed reviews Secdir Last Call review of -?? by Donald Eastlake
Assignment Reviewer Donald Eastlake 
State Completed
Review review-ietf-ippm-more-twamp-secdir-lc-eastlake-2009-06-05
Review completed: 2009-06-05


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This draft does two things in connection with the Two-Way Active
Measurement Protocol (TWAMP) a protocol which builds on the One-Way
Active Measurement Protocol (OWAMP):
     (1) Add an extension whereby the TWAMP-Test protocol can be done
in an unauthenticated mode while TWAMP-Control is authenticated and
encrypted, where previously they had been required to have the same
security mode. TWAMP-Control is used to initiate, start, and stop,
etc. test sessions, while TWAMP-Test is used to exchange test packets.
     (2) The draft establishes an IANA registration called TWAMP-Modes
for adding features. Establishing the IANA registry as such is not
security relevant.

This draft has a brief Security Considerations section. It
incorporates by reference the lengthy Security Considerations in RFC
4656, which specified OWAMP, and from RFC 5357, which specifies TWAMP
and adds considerations for one DoS attack which overlooked in RFC
4656. Generally, this incorporation by reference is adequate.

However, the draft Security Considerations sections has one additional
sentence which includes the words "thus making it possible to increase
overall security when compared to the previous options". That would
only be true if the additional burden, under previous options where
both control and test had the same security mode, of securing both
TWAMP-Control and TWAMP-Test was prohibitive, forcing less security
for TWAMP-Control and where having TWAMP-Test unauthenticated is not a
problem with respect to the security threats in the particular
instance. I believe the Security Considerations section should be
re-worded to either drop the claim of "increase overall security" or
at least make it clear that the claim only applies under resource
constraints that would, under previous modes, have forced less
security for TWAMP-Control and where unauthenticated TWAMP-Test is not
a significant security concern.

 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at