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

[Donald Eastlake <[e-mail]>]

Looks OK to me.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]



On Tue, Jun 2, 2009 at 3:35 PM, Al Morton <[e-mail]> wrote:
> 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]
>
>