Re: [secdir] draft-ietf-ippm-more-twamp-02.txt

[Al Morton <[e-mail]>]

Thanks for your comments, Donald, well-sorted through.

I think the following will do it,
Al

5.  Security Considerations
OLD
    The extended mixed-mode of operation permits stronger security/
    integrity protection on the TWAMP-Control protocol while
    simultaneously emphasizing accuracy or efficiency on the TWAMP-Test
    protocol, thus making it possible to increase overall security when
    compared to the previous options.

NEW
    The extended mixed-mode of operation permits stronger security/
    integrity protection on the TWAMP-Control protocol while
    simultaneously emphasizing accuracy or efficiency on the TWAMP-Test
    protocol, thus making it possible to increase overall security when
    compared to the previous options (when resource constraints would
    have forced less security for TWAMP-Control and where unauthenticated
    TWAMP-Test is not a significant concern).



At 03:04 PM 6/2/2009, Donald Eastlake wrote:
>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.
>
>Thanks,
>Donald
>=============================
>  Donald E. Eastlake 3rd   [phone] (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [e-mail]