draft-ietf-ippm-owdp-reqs-06.txt | rfc3763.txt | |||
---|---|---|---|---|
Network Working Group Stanislav Shalunov | Network Working Group S. Shalunov | |||
Internet Draft Benjamin Teitelbaum | Request for Comments: 3763 B. Teitelbaum | |||
Expiration Date: December 2003 Internet2 | Category: Informational Internet2 | |||
June 2003 | April 2004 | |||
A One-way Active Measurement Protocol Requirements | ||||
<draft-ietf-ippm-owdp-reqs-06.txt> | ||||
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 | One-way Active Measurement Protocol (OWAMP) Requirements | |||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Status of this Memo | |||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | This memo provides information for the Internet community. It does | |||
http://www.ietf.org/ietf/1id-abstracts.txt | not specify an Internet standard of any kind. Distribution of this | |||
memo is unlimited. | ||||
The list of Internet-Draft shadow directories can be accessed at | Copyright Notice | |||
http://www.ietf.org/shadow.html | ||||
This memo provides information for the Internet community. This memo | Copyright (C) The Internet Society (2004). All Rights Reserved. | |||
does not specify an Internet standard of any kind. Distribution of | ||||
this memo is unlimited. | ||||
2. Abstract | Abstract | |||
With growing availability of good time sources to network nodes, it | With growing availability of good time sources to network nodes, it | |||
becomes increasingly possible to measure one-way IP performance | becomes increasingly possible to measure one-way IP performance | |||
metrics with high precision. To do so in an interoperable manner, a | metrics with high precision. To do so in an interoperable manner, a | |||
common protocol for such measurements is required. This document | common protocol for such measurements is required. This document | |||
specifies requirements for a one-way active measurement protocol | specifies requirements for a one-way active measurement protocol | |||
(OWAMP) standard. The protocol can measure one-way delay, as well as | (OWAMP) standard. The protocol can measure one-way delay, as well as | |||
other unidirectional characteristics, such as one-way loss. | other unidirectional characteristics, such as one-way loss. | |||
3. Motivations and Goals | 1. Motivations and Goals | |||
The IETF IP Performance Metrics (IPPM) working group has proposed | The IETF IP Performance Metrics (IPPM) working group has proposed | |||
draft standard metrics for one-way packet delay [RFC2679] and loss | standards track metrics for one-way packet delay [RFC2679] and loss | |||
[RFC 2680] across Internet paths. Although there are now several | [RFC 2680] across Internet paths. Although there are now several | |||
measurement platforms that implement the collection of these metrics | measurement platforms that implement the collection of these metrics | |||
([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a | ([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a | |||
standard for interoperability. This requirements document is aimed | standard for interoperability. This requirements document is aimed | |||
at defining a protocol that allows users to do measurements using | at defining a protocol that allows users to do measurements using | |||
devices from different vendors at both ends and get meaningful | devices from different vendors at both ends and get meaningful | |||
results. | results. | |||
With the increasingly wide availability of affordable global | With the increasingly wide availability of affordable global | |||
positioning system (GPS) and CDMA based time sources, hosts | positioning system (GPS) and CDMA based time sources, hosts | |||
skipping to change at page 2, line 40 | skipping to change at page 2, line 19 | |||
timestamps one can measure characteristics such as loss with quality | timestamps one can measure characteristics such as loss with quality | |||
acceptable for many practical purposes, e.g., network operations. | acceptable for many practical purposes, e.g., network operations. | |||
To support interoperability between alternative OWAMP implementations | To support interoperability between alternative OWAMP implementations | |||
and make possible a world where "one-way ping" could become | and make possible a world where "one-way ping" could become | |||
commonplace, a standard is required that specifies how test streams | commonplace, a standard is required that specifies how test streams | |||
are initiated, how test packets are exchanged, and how test results | are initiated, how test packets are exchanged, and how test results | |||
are retrieved. Detailed functional requirements are given in the | are retrieved. Detailed functional requirements are given in the | |||
subsequent section. | subsequent section. | |||
4. Functional Requirements | 2. Functional Requirements | |||
The protocol(s) should provide the ability to measure, record, and | The protocol(s) should provide the ability to measure, record, and | |||
distribute the results of measurements of one-way singleton network | distribute the results of measurements of one-way singleton network | |||
characteristics such as characteristics defined in [RFC2679] and | characteristics such as characteristics defined in [RFC2679] and | |||
[RFC2680]. Result reporting, sampling, and time stamps are to be | [RFC2680]. Result reporting, sampling, and time stamps are to be | |||
within the framework of [RFC2330]. | within the framework of [RFC2330]. | |||
It should be possible to measure arbitrary one-way singleton | It should be possible to measure arbitrary one-way singleton | |||
characteristics (e.g., loss, median delay, mean delay, jitter, 90th | characteristics (e.g., loss, median delay, mean delay, jitter, 90th | |||
percentile of delay, etc.); this is achieved by keeping all the raw | percentile of delay, etc.); this is achieved by keeping all the raw | |||
data for post-processing by the final data consumer, as specified in | data for post-processing by the final data consumer, as specified in | |||
section 4.1. Since RFC2679 and RFC2680 standardize metrics based on | section 2.1. Since RFC2679 and RFC2680 standardize metrics based on | |||
Poisson sampling processes, Poisson streams must be supported by the | Poisson sampling processes, Poisson streams must be supported by the | |||
protocol(s). | protocol(s). | |||
Non-singleton characteristics (such as those related to trains of | Non-singleton characteristics (such as those related to trains of | |||
packets, back-to-back tuples, and so forth) and application traffic | packets, back-to-back tuples, and so forth) and application traffic | |||
simulation need not be addressed. However, they may be addressed if | simulation need not be addressed. However, they may be addressed if | |||
considered practical and not in contradiction to other design goals. | considered practical and not in contradiction to other design goals. | |||
4.1. Keeping All Data for Post-processing | 2.1. Keeping All Data for Post-processing | |||
To facilitate the broadest possible use of obtained measurement | To facilitate the broadest possible use of obtained measurement | |||
results, the protocol(s) should not necessitate any required post- | results, the protocol(s) should not necessitate any required post- | |||
processing. (This does not apply to implementation details such as | processing. (This does not apply to implementation details such as | |||
converting timestamps from ticks since midnight into a canonical form | converting timestamps from ticks since midnight into a canonical form | |||
or applying calibration constants; such details should naturally be | or applying calibration constants; such details should naturally be | |||
hidden.) All data obtained during a measurement session should be | hidden.) All data obtained during a measurement session should be | |||
available after the session is finished if desired by the data | available after the session is finished if desired by the data | |||
consumer so that various characteristics can be computed from the raw | consumer so that various characteristics can be computed from the raw | |||
data using arbitrary algorithms. | data using arbitrary algorithms. | |||
4.2. Result Distribution | 2.2. Result Distribution | |||
A means to distribute measurement results (between hosts | A means to distribute measurement results (between hosts | |||
participating in a measurement session and beyond) should be | participating in a measurement session and beyond) should be | |||
provided. Since there can exist a wide variety of scenarios as to | provided. Since there can exist a wide variety of scenarios as to | |||
where the final data destination should be, these should be invoked | where the final data destination should be, these should be invoked | |||
separately from measurement requests (e.g., receiver should not have | separately from measurement requests (e.g., receiver should not have | |||
to automatically send measurement results to the sender, since it may | to automatically send measurement results to the sender, since it may | |||
be the receiver or a third host that are the ultimate data | be the receiver or a third host that are the ultimate data | |||
destination). | destination). | |||
At the same time, ability to transfer results directly to their | At the same time, ability to transfer results directly to their | |||
destination (without need for potentially large intermediate | destination (without need for potentially large intermediate | |||
transfers) should be provided. | transfers) should be provided. | |||
4.3. Protocol Separation | 2.3. Protocol Separation | |||
Since measurement session setup and the actual measurement session | Since measurement session setup and the actual measurement session | |||
(i) are different tasks; (ii) require different levels of | (i) are different tasks; (ii) require different levels of | |||
functionality, flexibility, and implementation effort; (iii) may need | functionality, flexibility, and implementation effort; (iii) may need | |||
to run over different transport protocols, there should exist two | to run over different transport protocols, there should exist two | |||
protocols: one for conducting the actual measurement session and | protocols: one for conducting the actual measurement session and | |||
another for session setup/teardown/confirmation/retrieval. These | another for session setup/teardown/confirmation/retrieval. These | |||
protocols are further referred to as OWAMP-Test and OWAMP-Control, | protocols are further referred to as OWAMP-Test and OWAMP-Control, | |||
respectively. | respectively. | |||
It should be possible to use devices that only support OWAMP-Test but | It should be possible to use devices that only support OWAMP-Test but | |||
not OWAMP-Control to conduct measurement sessions (such devices will | not OWAMP-Control to conduct measurement sessions (such devices will | |||
necessarily need to support one form of session setup protocol or the | necessarily need to support one form of session setup protocol or the | |||
other, but it doesn't have to be known to external parties). | other, but it doesn't have to be known to external parties). | |||
OWAMP-Control would thus become a common protocol for different | OWAMP-Control would thus become a common protocol for different | |||
administrative domains, which may or may not use it for session setup | administrative domains, which may or may not use it for session setup | |||
internally. | internally. | |||
4.4. Test Protocol | 2.4. Test Protocol | |||
The test protocol needs to be implemented on all measurement nodes | The test protocol needs to be implemented on all measurement nodes | |||
and should therefore have the following characteristics: | and should therefore have the following characteristics: | |||
+ Be lightweight and easy to implement. | + Be lightweight and easy to implement. | |||
+ Be suitable for implementation on a wide range of measurement | + Be suitable for implementation on a wide range of measurement | |||
nodes. | nodes. | |||
+ Allow UDP as the transport protocol, since the protocol needs to | + Allow UDP as the transport protocol, since the protocol needs to | |||
be able to measure individual packet delivery times and has to run | be able to measure individual packet delivery times and has to run | |||
on various machines (see the section "Support for Measurements | on various machines (see the section "Support for Measurements | |||
with Different Packet Types" below for further discussion). | with Different Packet Types" below for further discussion). | |||
+ Support varying packet sizes and network services (e.g., DSCP | + Support varying packet sizes and network services (e.g., DSCP | |||
marking), as negotiated by OWAMP-Control. | marking). | |||
+ Be as simple as possible, but no simpler than necessary to | + Be as simple as possible, but no simpler than necessary to | |||
implement requirements set forth in this document; the OWAMP-Test | implement requirements set forth in this document; the OWAMP-Test | |||
packet format should include only universally meaningful fields, | packet format should include only universally meaningful fields, | |||
and minimum number of them. | and minimum number of them. | |||
+ If practical, it should be possible to generate OWAMP-Test packets | + If practical, it should be possible to generate OWAMP-Test packets | |||
small enough, so that when encapsulated, each fits inside a single | small enough, so that when encapsulated, each fits inside a single | |||
ATM cell. | ATM cell. | |||
+ Data needed to calculate experimental errors on the final result | + Data needed to calculate experimental errors on the final result | |||
should be included in every OWAMP-Test packet. | should be included in every OWAMP-Test packet. | |||
4.5. Control Protocol | 2.5. Control Protocol | |||
Control protocol needs to provide the capability to: | Control protocol needs to provide the capability to: | |||
+ authenticate peers to each other using a common authentication | + authenticate peers to each other using a common authentication | |||
method that doesn't require building any new authentication | method that doesn't require building any new authentication | |||
infrastructure, such as user ID and a shared secret; | infrastructure, such as user ID and a shared secret; | |||
+ schedule zero or more OWAMP-Test sessions (which do not have to be | + schedule zero or more OWAMP-Test sessions (which do not have to be | |||
between the peers of OWAMP-Control conversation); | between the peers of OWAMP-Control conversation); | |||
skipping to change at page 5, line 29 | skipping to change at page 5, line 5 | |||
+ retrieve OWAMP-Test session results (of OWAMP-Test sessions | + retrieve OWAMP-Test session results (of OWAMP-Test sessions | |||
scheduled in the current and other OWAMP-Control sessions); | scheduled in the current and other OWAMP-Control sessions); | |||
+ confirm graceful completion of sessions and allow either side to | + confirm graceful completion of sessions and allow either side to | |||
abort a session prematurely. | abort a session prematurely. | |||
The OWAMP-Control design should not preclude the ability to record | The OWAMP-Control design should not preclude the ability to record | |||
extended periods of losses. It should always provide peers with the | extended periods of losses. It should always provide peers with the | |||
ability to distinguish between network and peer failures. | ability to distinguish between network and peer failures. | |||
4.6. Support for Measurements with Different Packet Types | 2.6. Support for Measurements with Different Packet Types | |||
Since the notion of a packet of type P from [RFC2330], section 13 | Since the notion of a packet of type P from [RFC2330], section 13 | |||
doesn't always imply precise definition of packet type, some | doesn't always imply precise definition of packet type, some | |||
decisions narrowing the scope of possible packet types need to be | decisions narrowing the scope of possible packet types need to be | |||
made at measurement protocol design stage. Further, measurement with | made at measurement protocol design stage. Further, measurement with | |||
packets of certain types, while feasible in more closed settings than | packets of certain types, while feasible in more closed settings than | |||
those implied by OWAMP, become very hard to perform in an open inter- | those implied by OWAMP, become very hard to perform in an open | |||
domain fashion (e.g., measurements with particular packets with | inter-domain fashion (e.g., measurements with particular packets with | |||
broken IP checksum or particular loose source routing options). | broken IP checksum or particular loose source routing options). | |||
In addition, very general packet type specification could result in | In addition, very general packet type specification could result in | |||
several problems: | several problems: | |||
+ Many OWAMP-Test speakers will be general purpose computers with a | + Many OWAMP-Test speakers will be general purpose computers with a | |||
multitasking operating system that includes a socket interface. | multitasking operating system that includes a socket interface. | |||
These will inevitably have higher losses when listening to raw | These will inevitably have higher losses when listening to raw | |||
network traffic. Raw sockets will induce higher loss rate than | network traffic. Raw sockets will induce higher loss rate than | |||
one would have with UDP measurements. | one would have with UDP measurements. | |||
skipping to change at page 6, line 29 | skipping to change at page 5, line 49 | |||
(scrambling is different for different link-layer technologies). | (scrambling is different for different link-layer technologies). | |||
It appears that allowing one to ask a measurement server to generate | It appears that allowing one to ask a measurement server to generate | |||
arbitrary packets becomes an unmanageable security hole and a | arbitrary packets becomes an unmanageable security hole and a | |||
formidable specification and implementation hurdle. | formidable specification and implementation hurdle. | |||
For these reasons, we only require OWAMP to support a small subspace | For these reasons, we only require OWAMP to support a small subspace | |||
of the whole packet type space. Namely, it should be possible to | of the whole packet type space. Namely, it should be possible to | |||
conduct measurements with a given Differentiated Services Codepoint | conduct measurements with a given Differentiated Services Codepoint | |||
(DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB | (DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB | |||
ID) [RFC2836]. | ID) [RFC3140]. | |||
5. Scalability | 3. Scalability | |||
While some measurement architecture designs have inherent scalability | While some measurement architecture designs have inherent scalability | |||
problems (e.g., a full mesh of always-on measurements among N | problems (e.g., a full mesh of always-on measurements among N | |||
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 | 4. Security Considerations | |||
6.1. Authentication | 4.1. Authentication | |||
It should be possible to authenticate peers to each other using a | It should be possible to authenticate peers to each other using a | |||
user ID and a shared secret. It should be infeasible for any | user ID and a shared secret. It should be infeasible for any | |||
external party without knowledge of the shared secret to obtain any | external party without knowledge of the shared secret to obtain any | |||
information about it by observing, initiating, or modifying protocol | information about it by observing, initiating, or modifying protocol | |||
transactions. | transactions. | |||
It should also be infeasible for such party to use any information | It should also be infeasible for such party to use any information | |||
obtained by observing, modifying or initiating protocol transactions | obtained by observing, modifying or initiating protocol transactions | |||
to impersonate (other) valid users. | to impersonate (other) valid users. | |||
6.2. Authorization | 4.2. Authorization | |||
Authorization shall normally be performed on the basis of the | Authorization shall normally be performed on the basis of the | |||
authenticated identity (such as username) and the specification shall | authenticated identity (such as username) and the specification shall | |||
require all implementations to support such a mode of authorization. | require all implementations to support such a mode of authorization. | |||
Different identities (or classes of identities) can have different | Different identities (or classes of identities) can have different | |||
testing priviliges. The use of authorization for arriving at | testing privileges. The use of authorization for arriving at | |||
specific policy decisions (such as whether to allow a specific test | specific policy decisions (such as whether to allow a specific test | |||
with a specific source and destination and with a given test send | with a specific source and destination and with a given test send | |||
schedule -- which would determine the average network capacity | schedule -- which would determine the average network capacity | |||
utilization -- at a given time) is up to the users. | utilization -- at a given time) is up to the users. | |||
6.3. Being Hard to Interfere with by Applying Special Treatment to | 4.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.4. Secrecy/Confidentiality | 4.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.5. Integrity | 4.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 | |||
modifications of OWAMP-Test messages can be detected. It must be | modifications of OWAMP-Test messages can be detected. It must be | |||
possible to do this in a fashion that does not require timestamps | possible to do this in a fashion that does not require timestamps | |||
themselves to be encrypted; in this case, security properties are | themselves to be encrypted; in this case, security properties are | |||
valid only when an attacker cannot observe valid traffic between the | valid only when an attacker cannot observe valid traffic between the | |||
OWAMP-Test sender and receiver. | OWAMP-Test sender and receiver. | |||
6.6. Replay Attacks | 4.6. Replay Attacks | |||
OWAMP-Control must be resistant to any replay attacks. | OWAMP-Control must be resistant to any replay attacks. | |||
OWAMP-Test, on the other hand, is a protocol for network measurement. | OWAMP-Test, on the other hand, is a protocol for network measurement. | |||
One of the attributes of networks is packet duplication. OWAMP-Test | One of the attributes of networks is packet duplication. OWAMP-Test | |||
has to be suitable for measurement of duplication. This would make | has to be suitable for measurement of duplication. This would make | |||
it vulnerable to attacks that involve replaying a recent packet. For | it vulnerable to attacks that involve replaying a recent packet. For | |||
the recipient of such a packet it is impossible to determine whether | the recipient of such a packet it is impossible to determine whether | |||
the duplication is malicious or naturally occurring. | the duplication is malicious or naturally occurring. | |||
OWAMP-Test should measure all duplication -- malicious or otherwise. | OWAMP-Test should measure all duplication -- malicious or otherwise. | |||
Note that this is similar to delay attacks: an attacker can hold up a | Note that this is similar to delay attacks: an attacker can hold up a | |||
packet for some short period of time and then release it to continue | packet for some short period of time and then release it to continue | |||
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 occurring 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 | 4.7. Modes of Operation | |||
Since the protocol(s) will be used in widely varying circumstances | Since the protocol(s) will be used in widely varying circumstances | |||
using widely varying equipment, it is necessary be able to support | using widely varying equipment, it is necessary to be able to support | |||
varying degrees of security modes of operation. The parameters to be | varying degrees of security modes of operation. The parameters to be | |||
considered include: confidentiality, data origin authentication, | considered include: confidentiality, data origin authentication, | |||
integrity and replay protection. | integrity and replay protection. | |||
It should also be possible to operate in a mode where all security | It should also be possible to operate in a mode where all security | |||
mechanisms are enabled and security objectives are realized to the | mechanisms are enabled and security objectives are realized to the | |||
fullest extent possible. We call this "encrypted mode". | fullest extent possible. We call this "encrypted mode". | |||
Since timestamp encryption takes a certain amount of time, which may | 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 | be hard to predict on some devices (with a time-sharing OS), a mode | |||
skipping to change at page 9, line 34 | skipping to change at page 8, line 43 | |||
timestamps are not encrypted. In this mode, all security properties | timestamps are not encrypted. In this mode, all security properties | |||
of the encrypted mode that can be retained without timestamp | of the encrypted mode that can be retained without timestamp | |||
encryption should be present. We call this "authenticated mode". | encryption should be present. We call this "authenticated mode". | |||
It should be possible to operate in a completely "open" mode, where | It should be possible to operate in a completely "open" mode, where | |||
no cryptographic security mechanisms are used. We call this | no cryptographic security mechanisms are used. We call this | |||
"unauthenticated mode". In this mode, mandatory-to-use mechanisms | "unauthenticated mode". In this mode, mandatory-to-use mechanisms | |||
must be specified that prevent the use of the protocol for network | must be specified that prevent the use of the protocol for network | |||
capacity starvation denial-of-service attacks (e.g., only sending | capacity starvation denial-of-service attacks (e.g., only sending | |||
test data back to the client that requested them to be sent with the | test data back to the client that requested them to be sent with the | |||
request delivered over a TCP connection). | request delivered over a TCP connection), and that prevent a worm | |||
from using the protocol to send test data to a very large number of | ||||
hosts in a short time (e.g., ensuring that open mode requests can | ||||
only be made by humans, rate-limiting the acceptance of open mode | ||||
requests). | ||||
To make implementation more manageable, the number of other options | To make implementation more manageable, the number of other options | |||
and modes should be kept to the absolute practical minimum. Where | and modes should be kept to the absolute practical minimum. Where | |||
choosing a single mechanism for achieving anything related to | choosing a single mechanism for achieving anything related to | |||
security is possible, such choice should be made at specification | security is possible, such choice should be made at specification | |||
phase and be put into the standard. | phase and be put into the standard. | |||
7. IANA Considerations | 5. 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 | 6. References | |||
[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for | 6.1. Normative References | |||
IP Performance Metrics", RFC 2330, May 1998. | ||||
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of | [RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, | |||
the Differentiated Services Field (DS Field) in the IPv4 and | "Framework for IP Performance Metrics", RFC 2330, May | |||
IPv6 Headers", RFC 2474, December 1998. | 1998. | |||
[RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay | [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, | |||
Metric for IPPM", RFC 2679, September 1999. | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, December | ||||
1998. | ||||
[RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet | [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way | |||
Loss Metric for IPPM", RFC 2680, September 1999. | Delay Metric for IPPM", RFC 2679, September 1999. | |||
[RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior | [RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way | |||
Identification Codes", RFC 2836, May 2000. | Packet Loss Metric for IPPM", RFC 2680, September 1999. | |||
9. Informative References | [RFC3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, | |||
"Per Hop Behavior Identification Codes", RFC 3140, June | ||||
2001. | ||||
[BRIX] Brix 1000 Verifier, | 6.2. Informative References | |||
http://www.brixnet.com/products/brix1000.html | ||||
[CQOS] CQOS Home Page, http://www.cqos.com/ | [BRIX] Brix 1000 Verifier, | |||
http://www.brixnet.com/products/brix1000.html | ||||
[RIPE] RIPE NCC Test-Traffic Measurements home, | [CQOS] CQOS Home Page, http://www.cqos.com/ | |||
http://www.ripe.net/test-traffic/ | ||||
[RIPE] RIPE NCC Test-Traffic Measurements home, | ||||
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 | 7. Authors' Addresses | |||
Stanislav Shalunov <shalunov@internet2.edu> | Stanislav Shalunov | |||
Benjamin Teitelbaum <ben@internet2.edu> | EMail: shalunov@internet2.edu | |||
Expiration date: December 2003 | Benjamin Teitelbaum | |||
EMail: ben@internet2.edu | ||||
8. Full Copyright Statement | ||||
Copyright (C) The Internet Society (2004). This document is subject | ||||
to the rights, licenses and restrictions contained in BCP 78, and | ||||
except as set forth therein, the authors retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | ||||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE | ||||
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR | ||||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed | ||||
to pertain to the implementation or use of the technology | ||||
described in this document or the extent to which any license | ||||
under such rights might or might not be available; nor does it | ||||
represent that it has made any independent effort to identify any | ||||
such rights. Information on the procedures with respect to | ||||
rights in RFC documents can be found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use | ||||
of such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository | ||||
at http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention | ||||
any copyrights, patents or patent applications, or other | ||||
proprietary rights that may cover technology that may be required | ||||
to implement this standard. Please address the information to the | ||||
IETF at ietf-ipr@ietf.org. | ||||
Acknowledgement | ||||
Funding for the RFC Editor function is currently provided by the | ||||
Internet Society. | ||||
End of changes. 48 change blocks. | ||||
78 lines changed or deleted | 71 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |