[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00
Internet Engineering Task Force S. Floyd
INTERNET DRAFT K. K. Ramakrishnan
draft-ietf-tsvwg-ecn-tunnels-00.txt D. Black
October 2000
ECN Interactions with IP Tunnels
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.
Internet-Drafts are draft documents valid for a maximum of six months
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The encapsulation of IP packet headers in tunnels is used in many
places, including IPsec and IP in IP [RFC2003]. Explicit Congestion
Notification (ECN) is an experimental addition to the IP architecture
that uses the ECN field in the IP header to provide an indication of
the onset of congestion to applications. ECN provides this
congestion indication to enable end-node adaptation to network
conditions without the use of dropped packets [RFC 2481]. Currently,
the ECN specification does not accommodate the constraints imposed by
some of these pre-existing specifications for tunnels. This document
considers issues related to interactions between ECN and IP tunnels,
and proposes two alternative solutions.
Floyd, Ramakrishnan, Black [Page 1]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
A different set of issues are raised, relative to ECN, when IP
packets are encapsulated in tunnels with non-IP packet headers. This
occurs with MPLS [MPLS], GRE [GRE], L2TP [L2TP], and PPTP [PPTP].
For these protocols, there is no conflict with ECN; it is just that
ECN cannot be used within the tunnel unless an ECN codepoint can be
specified for the header of the encapsulating protocol. [RFD99]
presents a proposal for incorporating ECN into MPLS, and proposals
for incorporating ECN into GRE, L2TP, or PPTP will be considered as
the need arises.
1. Introduction.
Some IP tunnel modes are based on adding a new "outer" IP header that
encapsulates the original, or "inner" IP header and its associated
packet. In many cases, the new "outer" IP header may be added and
removed at intermediate points along a connection, enabling the
network to establish a tunnel without requiring endpoint
participation. We denote tunnels that specify that the outer header
be discarded at tunnel egress as ``simple tunnels''.
Explicit Congestion Notification (ECN) is an experimental addition to
the IP architecture that provides congestion indication to end-nodes
to enable them to adapt to network conditions without requiring the
packet to be dropped [RFC 2481]. An ECN-capable router uses the ECN
mechanism to signal congestion to connection endpoints by setting a
bit in the IP header. These endpoints then react, in terms of
congestion control, as if a packet had been dropped (e.g., TCP halves
its congestion window). This ability to avoid dropping packets in
response to congestion is supported by the use of active queue
management mechanisms (e.g., RED) in routers; such mechanisms begin
to mark or drop packets as a consequence of congestion before the
congested router queue is completely full. ECN is defined to be used
as an optimization -- routers are not required to support ECN, and
even an ECN-capable router may drop packets from ECN-capable
connections when necessary. The advantage to a router of not
dropping such packets is that ECN can provide a more timely
indication of congestion to the end nodes than indications based on
packet drops being detected by duplicate ACKs or timeout. As a
result, the queues at the router are better managed.
Currently, the ECN specification does not interact appropriately with
simple IP tunnels. Current use of ECN over simple IP tunnels results
in routers attempting to use the outer IP header to signal congestion
to endpoints, but those congestion warnings never arrive because the
outer header is discarded at the tunnel egress point. It is
desirable for the tunnel egress point to recognize the use of ECN on
the inner IP header. This problem was encountered with ECN and IPsec
in tunnel mode, and RFC 2481 recommends that ECN not be used with the
Floyd, Ramakrishnan, Black [Page 2]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
older simple IPsec tunnels in order to avoid this behavior and its
consequences.
This document considers issues related to interactions between ECN
and IP tunnels and proposes solutions. From a security point of
view, the use of ECN in the outer header of an IP tunnel might raise
security concerns because an adversary could tamper with the ECN
information that propagates beyond the tunnel endpoint. Based on an
analysis of these concerns and the resultant risks [IPsecECN], our
overall approach is to make support for ECN an option for IP tunnels,
so that an IP tunnel can be specified or configured either to use ECN
or not to use ECN in the outer header of the tunnel. Thus, in
environments or tunneling protocols where the risks of using ECN are
judged to outweigh its benefits, the tunnel can simply not use ECN in
the outer header. Then the only indication of congestion experienced
at routers within the tunnel would be through packet loss.
The result is that there are two viable options for the behavior of
ECN-capable connections over an IP tunnel, especially IPSec tunnels:
- A limited-functionality option in which ECN is preserved in the
inner header, but disabled in the outer header. The only
mechanism available for signaling congestion occurring within the
tunnel in this case is dropped packets.
- A full functionality option that supports ECN in both the inner
and outer headers, and propagates congestion warnings from nodes
within the tunnel to endpoints.
Support for these options requires varying amounts of changes to IP
header processing at tunnel ingress and egress. A small subset of
these changes sufficient to support only the limited-functionality
option would be sufficient to eliminate any incompatibility between
ECN and IP tunnels.
One goal of this document is to give guidance about the tradeoffs
between the limited-functionality and full-functionality options. A
full discussion of the potential effects of an adversary's
modifications of the CE and ECT bits is given in [IPsecECN]. This
document draws heavily on [IPsecECN], both in terms of the approach
and the text itself.
2. Architecture.
ECN uses two bits in the IP header, the ECT bit (ECN-Capable
Transport) and the CE bit (Congestion Experienced), for signaling
between routers and connection endpoints, and uses two flags in the
TCP header, the ECN-Echo bit (to Echo the ECN bit in IP header) and
the CWR bit (Congestion Window Reduced) for TCP-endpoint to TCP-
endpoint signaling. For a TCP connection, a typical sequence of
events in an ECN-based reaction to congestion is as follows:
Floyd, Ramakrishnan, Black [Page 3]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
- The ECT bit is set in packets transmitted by the sender to
indicate that ECN is supported on this TCP connection.
- An ECN-capable router detects impending congestion and detects
that the ECT bit is set in the packet it is about to drop.
Instead of dropping the packet, the router sets the CE bit and
forwards the packet.
- The receiver receives the packet with CE set, and sets the ECN-
Echo flag in its next TCP ACK sent to the sender.
- The sender receives the TCP ACK with ECN-Echo set, and reacts to
the congestion as if a packet had been dropped.
- The sender sets the CWR flag in the TCP header of the next
packet sent to the receiver to acknowledge its receipt of and
reaction to the ECN-Echo flag.
Further details on ECN functionality, including negotiation of ECN-
capability as part of TCP connection setup as well as the
responsibilities and requirements of ECN-capable routers and
transports, can be found in [RFC2481].
ECN interacts with IP tunnels because the two ECN bits are in the DS
field octet in the IP header [RFC2474] (also referred to as the IPv4
TOS octet or IPv6 Traffic Class octet). The DS field octet is
generally copied or mapped from the inner IP header to the outer IP
header at IP tunnel ingress, and in simple IP tunnels the outer
header's copy of this field is discarded at IP tunnel egress. If an
ECN-capable router were to set the CE (Congestion Experienced) bit
within a packet in a simple IP tunnel, this indication would be
discarded at tunnel egress, losing the indication of congestion. As
a consequence of this behavior, ECN usage within a simple IP tunnels
(with no changes at the ingress and egress) is not recommended.
The limited-functionality option for ECN encapsulation in IP tunnels
is for the ECT bit in the outside (encapsulating) header to be off
(i.e., set to 0), regardless of the value of the ECT bit in the
inside (encapsulated) header. With this option, the ECN field in the
inner header is not altered upon de-capsulation. The disadvantage of
this approach is that the flow does not have ECN support for that
part of the path that is using IP tunneling, even if the encapsulated
packet is ECN-Capable. That is, if the encapsulated packet arrives
at a congested router that is ECN-capable, and the router can decide
to drop or mark the packet as an indication of congestion to the end
nodes, the router will not be permitted to set the CE bit in the
packet header, but instead will have to drop the packet.
The IP full-functionality option for ECN encapsulation follows the
description in Section 10.1 of RFC 2481 of tunneling with ECN. This
option is to copy the ECT bit of the inside header to the outside
header on encapsulation, and to OR the CE bit from the outer header
Floyd, Ramakrishnan, Black [Page 4]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
with the CE bit of the inside header on decapsulation. With the
full-functionality option, a flow can take advantage of ECN for those
parts of the path that might use IP tunneling. The disadvantage of
the full-functionality option from a security perspective is that the
IP tunnel cannot protect the flow from certain modifications to the
ECN bits in the IP header within the tunnel. The potential dangers
from modifications to the ECN bits in the IP header are described in
detail in [IPsecECN].
This document proposes either the limited-functionality or full-
functionality option for IP tunnels in order to enable ECN
experimentation over IP tunnels, and avoid losing congestion
indications in the case that an ECN-capable router or routers are
traversed by an IP tunnel carrying ECN-capable connections. In
summary, two changes are proposed to IP tunnel functionality:
(1) Modify the handling of the DS field octet at IP tunnel
endpoints by implementing either the limited-functionality or the
full-functionality option.
(2) Optionally, enable the endpoints of an IP tunnel to negotiate
the choice between the limited-functionality and the full-
functionality option for ECN in the tunnel.
The minimum required to make ECN usable with IP tunnels is the
limited-functionality option, which prevents ECN from being enabled
in the outer header of an IPsec tunnel. Full support for ECN
requires the use of the full-functionality option. Optional
mechanisms to negotiate a choice between the tunnel endpoints of
either the limited-functionality or full-functionality option are not
discussed in this document. We assume that there is a pre-existing
agreement between the tunnel endpoints about whether to support the
limited-functionality or the full-functionality ECN option.
The two ECN bits in the IP header, ECT and CE, occupy bits 6 and 7 of
the DS Field octet [RFC2481]. For full ECN support the encapsulation
and decapsulation processing for the DS field octet involves the
following: At tunnel ingress, the full-functionality option copies
the value of ECT (bit 6) in the inner header to the outer header. CE
(bit 7) is set to 0 in the outer header. At tunnel egress, the full-
functionality option sets CE to 1 in the inner header if the value of
ECT (bit 6) in the inner header is 1, and the value of CE (bit 7) in
the outer header is 1. Otherwise, no change is made to this field of
the inner header.
For the limited-functionality option, at tunnel ingress bits 6 and 7
(ECT and CE) of the DS field in the outer header are set to zero, and
at tunnel egress no change is made to the DS field in the inner
header.
Floyd, Ramakrishnan, Black [Page 5]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
In addition, it is RECOMMENDED that packets with ECN and CE both set
to 1 in the outer header be dropped if they arrive on an tunnel
egress for a tunnel that uses the limited-functionality option, or
for a tunnel that uses the full-functionality option but for which
the ECT bit in the inner header is set to zero. This is motivated by
backwards compatibility and to ensure that no unauthorized
modifications of the ECN field takes place and is discussed further
in Section 6.
4. Possible Changes to the ECN Field
This section considers the issues when a router is operating,
possibly maliciously, to modify either of the bits in the ECN field.
In this section we represent the ECN field in the IP header by the
tuple (ECT bit, CE bit). The ECT bit, when set to 1, indicates an
ECN-Capable Transport. The CE bit, when set to 1, indicates that
Congestion was Experienced in the path.
By tampering with the bits in the ECN field, an adversary (or a
broken router) could do one or more of the following: falsely report
congestion, disable ECN-Capability for an individual packet, erase
the ECN congestion indication, or falsely indicate ECN-Capability.
[IPsecECN] systematically examines the various cases by which the ECN
field could be modified. The important criterion considered in
determining the consequences of such modifications is whether it is
likely to lead to poorer behavior in any dimension (throughput,
delay, fairness or functionality) than if a router were to drop a
packet.
The first two possible changes, falsely report congestion or
disabling ECN-Capability for an individual packet, are no worse than
if the router were to simply drop the packet. However, as discussed
in Section 5 below, a router that erases the ECN congestion
indication or falsely indicates ECN-Capability could potentially do
more damage to the flow that if it has simply dropped the packet.
5. Implications of Subverting End-to-End Congestion Control
This section considers the potential repercussions of subverting end-
to-end congestion control by either falsely indicating ECN-
Capability, or by erasing the congestion indication in ECN (the CE-
bit). Subverting end-to-end congestion control by either of these
two methods can have consequences both for the application and for
the network.
The first method to subvert end-to-end congestion control, falsely
indicating ECN-Capability, effectively subverts end-to-end congestion
control only if the packet would later encounter congestion that
Floyd, Ramakrishnan, Black [Page 6]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
results in the setting of the CE bit. In this case, the transport
protocol (which itself was not ECN capable) does not react
appropriately to the indication of congestion from these downstream
congested routers. It would have been better for these downstream
congested routers to drop the packet instead.
The second method to subvert end-to-end congestion control, `erasing'
the (set) CE bit in a packet, effectively subverts end-to-end
congestion control only when the CE bit in the packet was set earlier
by a congested router. In this case, the transport protocol does not
receive the indication of congestion from the upstream congested
routers.
Either of these two methods of subverting end-to-end congestion
control can potentially introduce more damage to the network (and
possibly to the flow itself) than if the adversary had simply dropped
packets from that flow. However, as we discuss in the subsequent
sections, this potential damage is limited. This is also discussed
extensively in [IPsecECN].
6. Changes to the ECN Field within an IP Tunnel.
The presence of a copy of the ECN field in the inner header of an IP
tunnel mode packet provides an opportunity for detection of
unauthorized modifications to the ECT bit in the outer header.
Comparison of the ECT bits in the inner and outer headers falls into
two categories for implementations that conform to this document:
(a) If the IP tunnel uses the full-functionality option, then the
values of the ECT bits in the inner and outer headers should be
identical.
(b) If the tunnel uses the limited-functionality option, then the
ECT bit in the outer header should be 0.
Receipt of a packet not satisfying the appropriate condition could be
a cause of concern.
Consider the case of an IP tunnel where the tunnel ingress point has
not been updated to this document's requirements, while the tunnel
egress point has been updated to support ECN. In this case, the IP
tunnel is not explicitly configured to support the full-functionality
ECN option. However, the tunnel ingress point is behaving identically
to a tunnel ingress point that supports the full-functionality
option. If packets from an ECN-capable connection use this tunnel,
ECT will be set to 1 in the outer header at the tunnel ingress point.
Congestion within the tunnel may then result in ECN-capable routers
setting CE in the outer header. Because the tunnel has not been
explicitly configured to support the full-functionality option, the
tunnel egress point expects the ECT bit in the outer header to be 0.
Floyd, Ramakrishnan, Black [Page 7]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
When an ECN-capable tunnel egress point receives a packet with the
ECT bit in the outer header set to 1, in a tunnel that has not been
configured to support the full-functionality option, that packet
should be processed, according to whether CE bit was set, as follows.
It is RECOMMENDED that such packets, with the ECT bit set to 1 on a
tunnel that has not been configured to support the full-functionality
option, be dropped at the egress point if CE is set to 1 in the outer
header but 0 in the inner header, and forwarded otherwise.
An IP tunnel cannot provide protection against erasure of congestion
indications based on resetting the value of the CE bit in packets for
which ECT is set in the outer header. The erasure of congestion
indications may impact the network and other flows in ways that would
not be possible in the absence of ECN. It is important to note that
erasure of congestion indications can only be performed to congestion
indications placed by nodes within the tunnel; the copy of the CE bit
in the inner header preserves congestion notifications from nodes
upstream of the tunnel ingress. If erasure of congestion
notifications is judged to be a security risk that exceeds the
congestion management benefits of ECN, then tunnels could be
specified or configured to use the limited-functionality option.
7. Issues Raised by Monitoring and Policing Devices
One possibility is that monitoring and policing devices (or more
informally, ``penalty boxes'') will be installed in the network to
monitor whether best-effort flows are appropriately responding to
congestion, and to preferentially drop packets from flows determined
not to be using adequate end-to-end congestion control procedures.
This is discussed in more detail in [IPsecECN]
For an ECN-capable flow, an `ideal' penalty box at a router would be
a device that, when it detected that a flow was not responding to ECN
indications, would switch to dropping, instead of marking, those
packets of a flow that would otherwise have been chosen to carry
indications of congestion. In this way, these congestion indications
could not be `erased' later in the network, and at the same time
there would be no change in the router's treatment of packets of
other flows. If a router determines that a flow is still not
responding to congestion indications when the congestion indications
consist of packet drops, then the router could take whatever further
action it deems appropriate for that flow.
We recommend that any ``penalty box'' that detects a flow or an
aggregate of flows that is not responding to end-to-end congestion
control first change from marking to dropping packets from that flow,
before taking any additional action to restrict the bandwidth
available to that flow. Thus, initially, the router may drop packets
Floyd, Ramakrishnan, Black [Page 8]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
in which the router would otherwise would have set the CE bit. This
could include dropping those arriving packets for that flow that are
ECN-Capable and that already have the CE bit set. In this way, any
congestion indications seen by that router for that flow will be
guaranteed to also be seen by the end nodes, even in the presence of
malicious or broken routers elsewhere in the path. If we assume that
the first action taken at any ``penalty box'' for an ECN-capable flow
will be to drop packets instead of marking them, then there is no way
that an adversary that subverts ECN-based end-to-end congestion
control can cause a flow to be characterized as being non-cooperative
and placed into a more severe action within the ``penalty box''.
If there were serious operational problems with routers
inappropriately erasing the CE bit in packet headers, one potential
fix would be to include a one-bit ECN nonce in packet headers, and
for routers to erase the nonce when they set the CE bit [SCWA99].
Routers would be unable to consistently reconstruct the nonce when
they erased the CE bit, and thus the repeated erasure of the CE bit
would be detected by the end-nodes. (This could in fact be done
without adding any extra bits for ECN in the IP header, by using the
ECN codepoints (ECT=1, CE=0) and (ECT=0, CE=1) as the two values for
the nonce, and by defining the codepoint (ECT=0, CE=1) to mean
exactly the same as the codepoint (ECT=1, CE=0).) However, at this
point the potential danger does not seem of sufficient concern to
warrant this additional complication of adding an ECN nonce to
protect against the erasure of the CE bit.
7.1. Complications Introduced by Split Paths
If a router or other network element has access to all of the packets
of a flow, then that router could do no more damage to a flow by
altering the ECN field than it could by simply dropping all of the
packets from that flow. However, in some cases, a malicious or
broken router might have access to only a subset of the packets from
a flow. The question is as follows: can this router, by altering
the ECN field in this subset of the packets, do more damage to that
flow than if it has simply dropped that set of the packets?
This is also discussed in detail in [IPsecECN], which concludes as
follows: It is true that the adversary that has access only to the A
packets might, by subverting ECN-based congestion control, be able to
deny the benefits of ECN to the other packets in the A&B aggregate.
While this is undesireable, this is not a sufficient concern to
result in disabling ECN within an IP tunnel.
Floyd, Ramakrishnan, Black [Page 9]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
8. Conclusions.
When ECN (Explicit Congestion Notification [RFC2481]) is used, it is
desirable that congestion indications generated within an IP tunnel
not be lost at the tunnel egress. We propose a minor modification to
the IP protocol's handling of the ECN field during encapsulation and
de-capsulation to allow flows that will undergo IP tunneling to use
ECN.
Two options were proposed:
1) A preferred alternative, which is the full-functionality option as
described in RFC 2481. This copies the ECT bit of the inner header to
the encapsulating header. At decapsulation, if the ECT bit is set in
the inner header, the CE bit on the outer header is ORed with the CE
bit of the inner header to update the CE bit of the packet.
2) A limited-functionality option that does not use ECN inside the IP
tunnel, by turning the ECT bit in the outer header off, and not
altering the inner header at the time of decapsulation.
In [IPsecECN] we examined the consequence of modifications of the ECN
field within the tunnel, analyzing all the opportunities for an
adversary to change the ECN field. In many cases, the change to the
ECN field is no worse than dropping a packet. However, we noted that
some changes have the more serious consequence of subverting end-to-
end congestion control. However, we point out that even then the
potential damage is limited, and is similar to the threat posed by an
end-system intentionally failing to cooperate with end-to-end
congestion control. We therefore believe that with these changes it
is reasonable to use ECN with IP tunnels, as described in RFC 2481.
Floyd, Ramakrishnan, Black [Page 10]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
9. Acknowledgements
We thank Tabassum Bint Haque from Dhaka, Bangladesh, for feedback on
an earlier version of this draft.
Floyd, Ramakrishnan, Black [Page 11]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
10. References
[FF98] Floyd, S., and Fall, K., Promoting the Use of End-to-End
Congestion Control in the Internet, IEEE/ACM Transactions on
Networking, August 1999. URL "http://www-
nrg.ee.lbl.gov/floyd/end2end-paper.html".
[GRE] S. Hanks, T. Li, D. Farinacci, and P. Traina, Generic Routing
Encapsulation (GRE), RFC 1701, October 1994. URL
"http://www.ietf.cnri.reston.va.us/rfc/rfc1701.txt".
[L2TP] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and B.
Palter Layer Two Tunneling Protocol "L2TP", RFC 2661, August 1999.
URL "ftp://ftp.isi.edu/in-notes/rfc2661.txt".
[MPLS] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
Requirements for Traffic Engineering Over MPLS, RFC 2702, September
1999. URL "ftp://ftp.isi.edu/in-notes/rfc2702.txt".
[PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
July 1999. URL "ftp://ftp.isi.edu/in-notes/rfc2637.txt".
[RFD99] Ramakrishnan, Floyd, S., and Davie, B., A Proposal to
Incorporate ECN in MPLS, work in progress, June 1999. URL
"http://www.aciri.org/floyd/papers/draft-ietf-mpls-ecn-00.txt".
[RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003, October
1996. URL "http://www.ietf.cnri.reston.va.us/rfc/rfc2003.txt".
[RFC 2401] S. Kent, R. Atkinson, Security Architecture for the
Internet Protocol, RFC 2401, November 1998.
[RFC2407] D. Piper, The Internet IP Security Domain of Interpretation
for ISAKMP, RFC 2407, November 1998.
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers, RFC 2474, December 1998.
[RFC2481] K. Ramakrishnan, S. Floyd, A Proposal to add Explicit
Congestion Notification (ECN) to IP, RFC 2481, January 1999.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, Generic
Routing Encapsulation (GRE), RFC 1701, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, Generic
Routing Encapsulation over IPv4 networks, RFC 1702, October 1994.
Floyd, Ramakrishnan, Black [Page 12]
draft-ietf-tsvwg-ecn-tunnel ECN and Tunnels October 2000
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom
Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM
Computer Communications Review, October 1999.
11. Security Considerations
Security considerations have been addressed in the main body of the
document.
AUTHORS' ADDRESSES
Sally Floyd
AT&T Center for Internet Research at ICSI (ACIRI)
Phone: +1 (510) 666-2989
Email: floyd@aciri.org
URL: http://www-nrg.ee.lbl.gov/floyd/
K. K. Ramakrishnan
TeraOptic Networks
Phone: +1 (408) 666-8650
Email: kk@teraoptic.com
David L. Black
EMC Corporation
42 South St.
Hopkinton, MA 01748
Phone: +1 (508) 435-1000 x75140
Email: black_david@emc.com
This draft was created in October 2000.
It expires April 2001.
Floyd, Ramakrishnan, Black [Page 13]
Html markup produced by rfcmarkup 1.126, available from
https://tools.ietf.org/tools/rfcmarkup/