--- 1/draft-ietf-ippm-owdp-reqs-05.txt 2006-02-04 23:46:09.000000000 +0100 +++ 2/draft-ietf-ippm-owdp-reqs-06.txt 2006-02-04 23:46:09.000000000 +0100 @@ -1,18 +1,18 @@ Network Working Group Stanislav Shalunov Internet Draft Benjamin Teitelbaum -Expiration Date: August 2003 Internet2 - February 2003 +Expiration Date: December 2003 Internet2 + June 2003 A One-way Active Measurement Protocol Requirements - + 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -252,92 +252,74 @@ measurement nodes requires O(N^2) total resources, such as storage space and link capacity), OWAMP itself should not exaggerate the problem or make it impossible (where it is in principle possible) to design other architectures that are free of scalability deficiencies. It is the protocol user's responsibility to decide how to use the protocol and which measurements to conduct. 6. Security Considerations -6.1. Modes of Operation - - Since the protocol(s) will be used in widely varying circumstances - using widely varying equipment, it is necessary be able to support - varying degrees of security modes of operation. The parameters to be - considered include: confidentiality, data origin authentication, - integrity and replay protection. +6.1. Authentication - It should be possible to operate in a completely "open" mode, where - no cryptographic security mechanisms are used. We call this - "unauthenticated mode". In this mode, care must be taken to avoid - denial-of-service attacks. + It should be possible to authenticate peers to each other using a + user ID and a shared secret. It should be infeasible for any + external party without knowledge of the shared secret to obtain any + information about it by observing, initiating, or modifying protocol + transactions. - It should also be possible to operate in a mode where all security - mechanisms are enabled and security objectives are realized to the - fullest extent possible. We call this "encrypted mode". + It should also be infeasible for such party to use any information + obtained by observing, modifying or initiating protocol transactions + to impersonate (other) valid users. - Since timestamp encryption takes a certain amount of time, which may - be hard to predict on some devices (with a time-sharing OS), a mode - should be provided that is similar to encrypted mode, but in which - timestamps are not encrypted. In this mode, all security properties - of the encrypted mode that can be retained without timestamp - encryption should be present. We call this "authenticated mode". +6.2. Authorization - To make implementation more manageable, the number of other options - and modes should be kept to the absolute practical minimum. Where - choosing a single mechanism for achieving anything related to - security is possible, such choice should be made at specification - phase and be put into the standard. + Authorization shall normally be performed on the basis of the + authenticated identity (such as username) and the specification shall + require all implementations to support such a mode of authorization. + Different identities (or classes of identities) can have different + testing priviliges. The use of authorization for arriving at + specific policy decisions (such as whether to allow a specific test + with a specific source and destination and with a given test send + schedule -- which would determine the average network capacity + utilization -- at a given time) is up to the users. -6.2. Being Hard to Interfere with by Applying Special Treatment to +6.3. Being Hard to Interfere with by Applying Special Treatment to Measurement Packets The design of the protocol should make it possible to run sessions that would make it very difficult for any intermediate party to make results appear better than they would be if no interference was attempted. This is different from cryptographic assurance of data integrity, because one can manipulate the results without changing any data in the packets. For example, if OWAMP-Test packets are easy to identify (e.g., they all come to a well-known port number), an intermediate party might place OWAMP-Test traffic into a priority queue at a congested link thus ensuring that the results of the measurement appear better than what would be experienced by other traffic. It should not be easy for intermediate parties to identify OWAMP-Test packets (just as it should not be easy for restaurants to identify restaurant critics). -6.3. Secrecy/Confidentiality +6.4. Secrecy/Confidentiality It should be possible to make it infeasible for any outside party without knowledge of the shared secret being used to learn what information is exchanged using OWAMP-Control by inspecting an OWAMP- Control stream or actively modifying it. (It is recognized that some information will inevitably leak from the mere fact of communication and from the presence and timing of concurrent and subsequent OWAMP-Test traffic.) -6.4. Authentication - - It should be possible to authenticate peers to each other using a - user ID and a shared secret. It should be infeasible for any - external party without knowledge of the shared secret to obtain any - information about it by observing, initiating, or modifying protocol - transactions. - - It should also be infeasible for such party to use any information - obtained by observing, modifying or initiating protocol transactions - to impersonate (other) valid users. - 6.5. Integrity So that it is possible to detect any interference during a conversation (other than the detention of some messages), facility must be provided to authenticate each message of the OWAMP-Control protocol, its attribution to a given session, and its exact placement in the sequence of control protocol exchanges. It must also be possible to authenticate each message of the test protocol and its attribution to a specific session, so that @@ -364,20 +346,53 @@ on its way to the recipient. There's no way such delay can be reliably distinguished from naturally occuring delay by the recipient. OWAMP-Test should measure the network as it was. Note, however, that this does not prevent the data from being sanitized at a later stage of processing, analysis, or consumption. Some sanity checks (those that are deemed reliable and erring on the side of inclusion) should be performed by OWAMP-Test recipient immediately. +6.7. Modes of Operation + + Since the protocol(s) will be used in widely varying circumstances + using widely varying equipment, it is necessary be able to support + varying degrees of security modes of operation. The parameters to be + considered include: confidentiality, data origin authentication, + integrity and replay protection. + + It should also be possible to operate in a mode where all security + mechanisms are enabled and security objectives are realized to the + fullest extent possible. We call this "encrypted mode". + + Since timestamp encryption takes a certain amount of time, which may + be hard to predict on some devices (with a time-sharing OS), a mode + should be provided that is similar to encrypted mode, but in which + timestamps are not encrypted. In this mode, all security properties + of the encrypted mode that can be retained without timestamp + encryption should be present. We call this "authenticated mode". + + It should be possible to operate in a completely "open" mode, where + no cryptographic security mechanisms are used. We call this + "unauthenticated mode". In this mode, mandatory-to-use mechanisms + must be specified that prevent the use of the protocol for network + capacity starvation denial-of-service attacks (e.g., only sending + test data back to the client that requested them to be sent with the + request delivered over a TCP connection). + + To make implementation more manageable, the number of other options + and modes should be kept to the absolute practical minimum. Where + choosing a single mechanism for achieving anything related to + security is possible, such choice should be made at specification + phase and be put into the standard. + 7. IANA Considerations Relevant IANA considerations will be placed into the protocol specification document itself, and not into the requirements document. 8. Normative References [RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. @@ -406,11 +421,11 @@ http://www.ripe.net/test-traffic/ [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/ 10. Authors' Addresses Stanislav Shalunov Benjamin Teitelbaum - Expiration date: August 2003 + Expiration date: December 2003