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/ |