Subject: [ippm] security review of draft-ietf-ippm-owdp-09.txt

From: stanislav shalunov <[email-masked]>
Date: 03 Aug 2004 18:00:38 -0400

"Steven M. Bellovin" <[email-masked]> writes:

> Sam Weiler <[email-masked]> and Bernard Aboba <[email-masked]>
> are looking at it.

Sam and Bernard,

The OWAMP specification document is now almost ready for working group
last call (and implemented by several people, including a SONET
hardware implementation of OWAMP-Test).  One area that bothered me was
security; I did not feel like it received adequate review.  In order
to catch potential problems earlier rather than at the stage of IESG
review, we asked for a security review now.  Should you need
clarifications, you can contact me directly (or publicly, if you
wish).  The results of your review, of course, should be posted to
[email-masked]; I wouldn't mind taking a look at them beforehand, but
it's up to you.

Keep in mind that the requirements document for OWAMP is RFC 3763.

The changes that are currently pending according to my TODO file (I
plan to make them when submissions are accepted again) are as follows:

- decide whether to communicate actual start time explicitly via OWAMP-Control
- change order of error estimate and timestamp, per Henk
- remove start-in-the-past feature
- add to security consideration required properties of AES and CBC mode
- clarify behavior of sender in case of scheduling delays
- acknowledgments section
- id-nits

None of them should materially affect the security of the protocol.

At an early stage in designing the protocol, we considered using TLS
and IPsec as cryptographic security mechanisms for OWAMP.  The
disadvantages of those are as follows (not an exhaustive list):

Regarding TLS:

* Could be used to secure TCP-based OWAMP-Control, but difficult to
  use to secure UDP-based OWAMP-Test: OWAMP-Test packets, if lost, are
  not resent, so packets have to be (optionally) encrypted and
  authenticated while retaining individual usability.  Stream-based
  TLS is not conducive of this.

* Dealing with streams, does not authenticate individual messages
  (even in OWAMP-Control).  The easiest way out would be to add some
  known-format padding to each message and verify that the format of
  the padding is intact before using the message.  The solution would
  thus lose some of its appeal (``just use TLS''); it would also be
  much more difficult to evaluate the security of this scheme with the
  various modes and options of TLS---it would almost certainly not be
  secure with all.  The capacity of an attacker to replace parts of
  messages (namely, the end) with random garbage could have serious
  security implications and would need to be analyzed carefully:
  suppose, for example, that a parameter that is used in some form to
  control the rate were replaced by random garbage---chances are the
  result (an unsigned integer) would be quite large.

* Dependent on the mode of use, one can end up with a requirement for
  certificates for all users and a PKI.  Even if one is to accept that
  PKI is desirable, there just isn't a usable one today.

* Requires a large implementation.  OpenSSL, for example, is larger
  than the implementation of OWAMP as a whole.  This can matter for
  embedded implementations.

Regarding IPsec:

* What we now call authenticated mode would not be possible (in IPsec
  you can't authenticate part of a packet).

* The deployment paths of IPsec and OWAMP could be separate if OWAMP
  does not depend on IPsec.  After nine years of IPsec, only 0.05% of
  traffic on an advanced network such as Abilene is IPsec (for
  comparison purposes with encryption above layer 4, SSH is 2-4% and
  HTTPS is 0.2-0.6%).  It is desirable to be able to deploy OWAMP on
  as large of a number of different platforms as possible.

* The deployment problems of a protocol dependent on IPsec would be
  especially acute in the case of lightweight embedded devices.
  Ethernet switches, DSL ``modems,'' and other such devices mostly do
  not support IPsec.

* The API for manipulation IPsec from an application is poorly
  understood.  Writing a program that needs to encrypt some packets,
  authenticate some packets, and leave some open---for the same
  destination---would become more of an exercise in IPsec rather than
  IP measurement.

For the enumerated reasons, we decided to use a simple cryptographic
protocol that is different from TLS and IPsec.

Thank you very much for agreeing to review,

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Just my 0.086g of Ag.

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm