draft-ietf-ippm-owdp-reqs-05.txt   draft-ietf-ippm-owdp-reqs-06.txt 
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum Internet Draft Benjamin Teitelbaum
Expiration Date: August 2003 Internet2 Expiration Date: December 2003 Internet2
February 2003 June 2003
A One-way Active Measurement Protocol Requirements A One-way Active Measurement Protocol Requirements
<draft-ietf-ippm-owdp-reqs-05.txt> <draft-ietf-ippm-owdp-reqs-06.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
measurement nodes requires O(N^2) total resources, such as storage measurement nodes requires O(N^2) total resources, such as storage
space and link capacity), OWAMP itself should not exaggerate the space and link capacity), OWAMP itself should not exaggerate the
problem or make it impossible (where it is in principle possible) to problem or make it impossible (where it is in principle possible) to
design other architectures that are free of scalability deficiencies. design other architectures that are free of scalability deficiencies.
It is the protocol user's responsibility to decide how to use the It is the protocol user's responsibility to decide how to use the
protocol and which measurements to conduct. protocol and which measurements to conduct.
6. Security Considerations 6. Security Considerations
6.1. Modes of Operation 6.1. Authentication
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 be possible to operate in a completely "open" mode, where It should be possible to authenticate peers to each other using a
no cryptographic security mechanisms are used. We call this user ID and a shared secret. It should be infeasible for any
"unauthenticated mode". In this mode, care must be taken to avoid external party without knowledge of the shared secret to obtain any
denial-of-service attacks. information about it by observing, initiating, or modifying protocol
transactions.
It should also be possible to operate in a mode where all security It should also be infeasible for such party to use any information
mechanisms are enabled and security objectives are realized to the obtained by observing, modifying or initiating protocol transactions
fullest extent possible. We call this "encrypted mode". to impersonate (other) valid users.
Since timestamp encryption takes a certain amount of time, which may 6.2. Authorization
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".
To make implementation more manageable, the number of other options Authorization shall normally be performed on the basis of the
and modes should be kept to the absolute practical minimum. Where authenticated identity (such as username) and the specification shall
choosing a single mechanism for achieving anything related to require all implementations to support such a mode of authorization.
security is possible, such choice should be made at specification Different identities (or classes of identities) can have different
phase and be put into the standard. 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 Measurement Packets
The design of the protocol should make it possible to run sessions The design of the protocol should make it possible to run sessions
that would make it very difficult for any intermediate party to make that would make it very difficult for any intermediate party to make
results appear better than they would be if no interference was results appear better than they would be if no interference was
attempted. attempted.
This is different from cryptographic assurance of data integrity, This is different from cryptographic assurance of data integrity,
because one can manipulate the results without changing any data in because one can manipulate the results without changing any data in
the packets. For example, if OWAMP-Test packets are easy to identify 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 (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 party might place OWAMP-Test traffic into a priority queue at a
congested link thus ensuring that the results of the measurement congested link thus ensuring that the results of the measurement
appear better than what would be experienced by other traffic. It appear better than what would be experienced by other traffic. It
should not be easy for intermediate parties to identify OWAMP-Test should not be easy for intermediate parties to identify OWAMP-Test
packets (just as it should not be easy for restaurants to identify packets (just as it should not be easy for restaurants to identify
restaurant critics). restaurant critics).
6.3. Secrecy/Confidentiality 6.4. Secrecy/Confidentiality
It should be possible to make it infeasible for any outside party It should be possible to make it infeasible for any outside party
without knowledge of the shared secret being used to learn what without knowledge of the shared secret being used to learn what
information is exchanged using OWAMP-Control by inspecting an OWAMP- information is exchanged using OWAMP-Control by inspecting an OWAMP-
Control stream or actively modifying it. Control stream or actively modifying it.
(It is recognized that some information will inevitably leak from the (It is recognized that some information will inevitably leak from the
mere fact of communication and from the presence and timing of mere fact of communication and from the presence and timing of
concurrent and subsequent OWAMP-Test traffic.) 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 6.5. Integrity
So that it is possible to detect any interference during a So that it is possible to detect any interference during a
conversation (other than the detention of some messages), facility conversation (other than the detention of some messages), facility
must be provided to authenticate each message of the OWAMP-Control must be provided to authenticate each message of the OWAMP-Control
protocol, its attribution to a given session, and its exact placement protocol, its attribution to a given session, and its exact placement
in the sequence of control protocol exchanges. in the sequence of control protocol exchanges.
It must also be possible to authenticate each message of the test It must also be possible to authenticate each message of the test
protocol and its attribution to a specific session, so that protocol and its attribution to a specific session, so that
skipping to change at page 9, line 29 skipping to change at page 9, line 9
on its way to the recipient. There's no way such delay can be on its way to the recipient. There's no way such delay can be
reliably distinguished from naturally occuring delay by the reliably distinguished from naturally occuring delay by the
recipient. recipient.
OWAMP-Test should measure the network as it was. Note, however, that 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 this does not prevent the data from being sanitized at a later stage
of processing, analysis, or consumption. Some sanity checks (those of processing, analysis, or consumption. Some sanity checks (those
that are deemed reliable and erring on the side of inclusion) should that are deemed reliable and erring on the side of inclusion) should
be performed by OWAMP-Test recipient immediately. 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 7. IANA Considerations
Relevant IANA considerations will be placed into the protocol Relevant IANA considerations will be placed into the protocol
specification document itself, and not into the requirements specification document itself, and not into the requirements
document. document.
8. Normative References 8. Normative References
[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for [RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998. IP Performance Metrics", RFC 2330, May 1998.
skipping to change at page 10, line 26 skipping to change at page 10, line 41
http://www.ripe.net/test-traffic/ http://www.ripe.net/test-traffic/
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/ [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/
10. Authors' Addresses 10. Authors' Addresses
Stanislav Shalunov <shalunov@internet2.edu> Stanislav Shalunov <shalunov@internet2.edu>
Benjamin Teitelbaum <ben@internet2.edu> Benjamin Teitelbaum <ben@internet2.edu>
Expiration date: August 2003 Expiration date: December 2003
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/