Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3819

Advice for Internet Subnetwork Designers

Pages: 60
Best Current Practice: 89
Errata
Part 3 of 3 – Pages 36 to 60
First   Prev   None

Top   ToC   RFC3819 - Page 36   prevText

15. Packet Reordering

The Internet architecture does not guarantee that packets will arrive in the same order in which they were originally transmitted; transport protocols like TCP must take this into account. However, reordering does come at a cost with TCP as it is currently defined. Because TCP returns a cumulative acknowledgment (ACK) indicating the last in-order segment that has arrived, out-of-order segments cause a TCP receiver to transmit a duplicate acknowledgment. When the TCP sender notices three duplicate acknowledgments, it assumes that a segment was dropped by the network and uses the fast retransmit algorithm [Jac90] [RFC2581] to resend the segment. In addition, the congestion window is reduced by half, effectively halving TCP's sending rate. If a subnetwork reorders segments significantly such that three duplicate ACKs are generated, the TCP sender needlessly reduces the congestion window and performance suffers. Packet reordering frequently occurs in parts of the Internet, and it seems to be difficult or impossible to eliminate [BPS99]. For this reason, research on improving TCP's behavior in the face of packet reordering [LK00] [BA02] has begun.
Top   ToC   RFC3819 - Page 37
   [BPS99] cites reasons why it may even be undesirable to eliminate
   reordering.  There are situations where average packet latency can be
   reduced, link efficiency can be increased, and/or reliability can be
   improved if reordering is permitted.  Examples include certain high
   speed switches within the Internet backbone and the parallel links
   used over many Internet paths for load splitting and redundancy.

   This suggests that subnetwork implementers should try to avoid packet
   reordering whenever possible, but not if doing so compromises
   efficiency, impairs reliability, or increases average packet delay.

   Note that every header compression scheme currently standardized for
   the Internet requires in-order packet delivery on the link between
   compressor and decompressor.  PPP is frequently used to carry
   compressed TCP/IP packets; since it was originally designed for
   point-to-point and dialup links, it is assumed to provide in-order
   delivery.  For this reason, subnetwork implementers who provide PPP
   interfaces to VPNs and other more complex subnetworks, must also
   maintain in-order delivery of PPP frames.

16. Mobility

Internet users are increasingly mobile. Not only are many Internet nodes laptop computers, but pocket organizers and mobile embedded systems are also becoming nodes on the Internet. These nodes may connect to many different access points on the Internet over time, and they expect this to be largely transparent to their activities. Except when they are not connected to the Internet at all, and for performance differences when they are connected, they expect that everything will "just work" regardless of their current Internet attachment point or local subnetwork technology. Changing a host's Internet attachment point involves one or more of the following steps. First, if use of the local subnetwork is restricted, the user's credentials must be verified and access granted. There are many ways to do this. A trivial example would be an "Internet cafe" that grants physical access to the subnetwork for a fee. Subnetworks may implement technical access controls of their own; one example is IEEE 802.11 Wireless Equivalent Privacy [IEEE80211]. It is common practice for both cellular telephone and Internet service providers (ISPs) to agree to serve one anothers' users; RADIUS [RFC2865] is the standard method for ISPs to exchange authorization information. Second, the host may have to be reconfigured with IP parameters appropriate for the local subnetwork. This usually includes setting an IP address, default router, and domain name system (DNS) servers.
Top   ToC   RFC3819 - Page 38
   On multiple-access networks, the Dynamic Host Configuration Protocol
   (DHCP) [RFC2131] is almost universally used for this purpose.  On PPP
   links, these functions are performed by the IP Control Protocol
   (IPCP) [RFC1332].

   Third, traffic destined for the mobile host must be routed to its
   current location.  This roaming function is the most common meaning
   of the term "Internet mobility".

   Internet mobility can be provided at any of several layers in the
   Internet protocol stack, and there is ongoing debate as to which is
   the most appropriate and efficient.  Mobility is already a feature of
   certain application layer protocols; the Post Office Protocol (POP)
   [RFC1939] and the Internet Message Access Protocol (IMAP) [RFC3501]
   were created specifically to provide mobility in the receipt of
   electronic mail.

   Mobility can also be provided at the IP layer [RFC3344].  This
   mechanism provides greater transparency, viz., IP addresses that
   remain fixed as the nodes move, but at the cost of potentially
   significant network overhead and increased delay because of the sub-
   optimal network routing and tunneling involved.

   Some subnetworks may provide internal mobility, transparent to IP, as
   a feature of their own internal routing mechanisms.  To the extent
   that these simplify routing at the IP layer, reduce the need for
   mechanisms like Mobile IP, or exploit mechanisms unique to the
   subnetwork, this is generally desirable.  This is especially true
   when the subnetwork covers a relatively small geographic area and the
   users move rapidly between the attachment points within that area.
   Examples of internal mobility schemes include Ethernet switching and
   intra-system handoff in cellular telephony.

   However, if the subnetwork is physically large and connects to other
   parts of the Internet at multiple geographic points, care should be
   taken to optimize the wide-area routing of packets between nodes on
   the external Internet and nodes on the subnet.  This is generally
   done with "nearest exit" routing strategies.  Because a given
   subnetwork may be unaware of the actual physical location of a
   destination on another subnetwork, it simply routes packets bound for
   the other subnetwork to the nearest router between the two.  This
   implies some awareness of IP addressing and routing within the
   subnetwork.  The subnetwork may wish to use IP routing internally for
   wide area routing and restrict subnetwork-specific routing to
   constrained geographic areas where the effects of suboptimal routing
   are minimized.
Top   ToC   RFC3819 - Page 39

17. Routing

Subnetworks connecting more than two systems must provide their own internal Layer-2 forwarding mechanisms, either implicitly (e.g., broadcast) or explicitly (e.g., switched). Since routing is the major function of the Internet layer, the question naturally arises as to the interaction between routing at the Internet layer and routing in the subnet, and proper division of function between the two. Layer-2 subnetworks can be point-to-point, connecting two systems, or multipoint. Multipoint subnetworks can be broadcast (e.g., shared media or emulated) or non-broadcast. Generally, IP considers multipoint subnetworks as broadcast, with shared-medium Ethernet as the canonical (and historical) example, and point-to-point subnetworks as a degenerate case. Non-broadcast subnetworks may require additional mechanisms, e.g., above IP at the routing layer [RFC2328]. IP is ignorant of the topology of the subnetwork layer. In particular, reconfiguration of subnetwork paths is not tracked by the IP layer. IP is only affected by whether it can send/receive packets sent to the remotely connected systems via the subnetwork interface (i.e., the reachability from one router to another). IP further considers that subnetworks are largely static -- that both their membership and existence are stable at routing timescales (tens of seconds); changes to these are considered re-provisioning, rather than routing. Routing functionality in a subnetwork is related to addressing in that subnetwork. Resolution of addresses on subnetwork links is required for forwarding IP packets across links (e.g., ARP for IPv4, or ND for IPv6). There is unlikely to be direct interaction between subnetwork routing and IP routing. Where broadcast is provided or explicitly emulated, address resolution can be used directly; where not provided, the link layer routing may interface to a protocol for resolution, e.g., to the Next-Hop Resolution Protocol [RFC2322] to provide context-dependent address resolution capabilities. Subnetwork routing can either complement or compete with IP routing. It complements IP when a subnetwork encapsulates its internal routing, and where the effects of that routing are not visible at the IP layer. However, if different paths in the subnetwork have characteristics that affect IP routing, it can affect or even inhibit the convergence of IP routing.
Top   ToC   RFC3819 - Page 40
   Routing protocols generally consider Layer-2 subnetworks, i.e., with
   subnet masks and no intermediate IP hops, to have uniform routing
   metrics to all members.  Routing can break when a link's
   characteristics do not match the routing metric, in this case, e.g.,
   when some member pairs have different path characteristics.  Consider
   a virtual Ethernet subnetwork that includes both nearby (sub-
   millisecond latency) and remote (100's of milliseconds away) systems.
   Presenting that group as a single subnetwork means that some routing
   protocols will assume that all pairs have the same delay, and that
   that delay is small.  Because this is not the case, the routing
   tables constructed may be suboptimal or may even fail to converge.

   When a subnetwork is used for transit between a set of routers, it
   conventionally provides the equivalent of a full mesh of point-to-
   point links.  Simplicity of the internal subnet structure can be used
   (e.g., via NHRP [RFC2332]) to reduce the size of address resolution
   tables, but routing exchanges will continue to reflect the full mesh
   they emulate.  In general, subnetworks should not be used as a
   transit among a set of routers where routing protocols would break if
   a full mesh of equivalent point-to-point links were used.

   Some subnetworks have special features that allow the use of more
   effective or responsive routing mechanisms that cannot be implemented
   in IP because of its need for generality.  One example is the self-
   learning bridge algorithm widely used in Ethernet networks.  Learning
   bridges perform Layer-2 subnetwork forwarding, avoiding the need for
   dynamic routing at each subnetwork hop.  Another is the "handoff"
   mechanism in cellular telephone networks, particularly the "soft
   handoff" scheme in IS-95 CDMA.

   Subnetworks that cover large geographic areas or include links of
   widely-varying capabilities should be avoided.  IP routing generally
   considers all multipoint subnets equivalent to a local, shared-medium
   link with uniform metrics between any pair of systems, and ignores
   internal subnetwork topology.  Where a subnetwork diverges from that
   assumption, it is the obligation of subnetwork designers to provide
   compensating mechanisms.  Not doing so can affect the scalability and
   convergence of IP routing, as noted above.

   The subnetwork designer who decides to implement internal routing
   should consider whether a custom routing algorithm is warranted, or
   if an existing Internet routing algorithm or protocol may suffice.
   The designer should consider whether this decision is to reduce the
   address resolution table size (possible, but with additional protocol
   support required), or is trying to reduce routing table complexity.
   The latter may be better achieved by partitioning the subnetwork,
   either physically or logically, and using network-layer protocols to
   support partitioning (e.g., AS's in BGP).  Protocols and routing
Top   ToC   RFC3819 - Page 41
   algorithms can be notoriously subtle, complex, and difficult to
   implement correctly.  Much work can be avoided if existing protocols
   or implementations can be readily reused.

18. Security Considerations

Security has become a high priority in the design and operation of the Internet. The Internet is vast, and countless organizations and individuals own and operate its various components. A consensus has emerged for what might be called a "security placement principle": a security mechanism is most effective when it is placed as close as possible to, and under the direct control of the owner of the asset that it protects. A corollary of this principle is that end-to-end security (e.g., confidentiality, authentication, integrity, and access control) cannot be ensured with subnetwork security mechanisms. Not only are end-to-end security mechanisms much more closely associated with the end-user assets they protect, they are also much more comprehensive. For example, end-to-end security mechanisms cover gaps that can appear when otherwise good subnetwork mechanisms are concatenated. This is an important application of the end-to-end principle [SRC81]. Several security mechanisms that can be used end-to-end have already been deployed in the Internet and are enjoying increasing use. The most important are the Secure Sockets Layer (SSL) [SSL2] [SSL3] and TLS [RFC2246] primarily used to protect web commerce, Pretty Good Privacy (PGP) [RFC1991] and S/MIME [RFCs-2630-2634], primarily used to protect and authenticate email and software distributions, the Secure Shell (SSH), used for secure remote access and file transfer, and IPsec [RFC2401], a general purpose encryption and authentication mechanism that sits just above IP and can be used by any IP application. (IPsec can actually be used either on an end-to-end basis or between security gateways that do not include either or both end systems.) Nonetheless, end-to-end security mechanisms are not used as widely as might be desired. However, the group could not reach consensus on whether subnetwork designers should be actively encouraged to implement mechanisms to protect user data. The clear consensus of the working group held that subnetwork security mechanisms, especially when weak or incorrectly implemented [BGW01], may actually be counterproductive. The argument is that subnetwork security mechanisms can lull end users into a false sense of security, diminish the incentive to deploy effective end-to-end
Top   ToC   RFC3819 - Page 42
   mechanisms, and encourage "risky" uses of the Internet that would not
   be made if users understood the inherent limits of subnetwork
   security mechanisms.

   The other point of view encourages subnetwork security on the
   principle that it is better than the default situation, which all too
   often is no security at all.  Users of especially vulnerable subnets
   (such as consumers who have wireless home networks and/or shared
   media Internet access) often have control over at most one endpoint
   -- usually a client -- and therefore cannot enforce the use of end-
   to-end mechanisms.  However, subnet security can be entirely adequate
   for protecting low-valued assets against the most likely threats.  In
   any event, subnet mechanisms do not preclude the use of end-to-end
   mechanisms, which are typically used to protect highly-valued assets.
   This viewpoint recognizes that many security policies implicitly
   assume that the entire end-to-end path is composed of a series of
   concatenated links that are nominally physically secured.  That is,
   these policies assume that all endpoints of all links are trusted,
   and that access to the physical medium by attackers is difficult.  To
   meet the assumptions of such policies, explicit mechanisms are needed
   for links (especially shared medium links) that lack physical
   protection.  This, for example, is the rationale that underlies Wired
   Equivalent Privacy (WEP) in the IEEE 802.11 [IEEE80211] wireless LAN
   standard, and the Baseline Privacy Interface in the DOCSIS [DOCSIS1]
   [DOCSIS2] data over cable television networks standards.

   We therefore recommend that subnetwork designers who choose to
   implement security mechanisms to protect user data be as candid as
   possible with the details of such security mechanisms and the
   inherent limits of even the most secure mechanisms when implemented
   in a subnetwork rather than on an end-to-end basis.

   In keeping with the "placement principle", a clear consensus exists
   for another subnetwork security role: the protection of the
   subnetwork itself.  Possible threats to subnetwork assets include
   theft of service and denial of service; shared media subnets tend to
   be especially vulnerable to such attacks.  In some cases, mechanisms
   that protect subnet assets can also improve (but cannot ensure) end-
   to-end security.

   One security service can be provided by the subnetwork that will aid
   in the solution of an overall Internet problem: subnetwork security
   should provide a mechanism to authenticate the source of a subnetwork
   frame.  This function is missing in some current protocols, e.g., the
   use of ARP [RFC826] to associate an IPv4 address with a MAC address.
   The IPv6 Neighbor Discovery (ND) [RFC2461] performs a similar
   function.
Top   ToC   RFC3819 - Page 43
   There are well-known security flaws with this address resolution
   mechanism [Wilbur89].  However, the inclusion of subnetwork frame
   source authentication will permit a secure subnetwork address.

   Another potential role for subnetwork security is to protect users
   against traffic analysis, i.e., identifying the communicating parties
   and determining their communication patterns and volumes even when
   their actual contents are protected by strong end-to-end security
   mechanisms.  Lower-layer security can be more effective against
   traffic analysis due to its inherent ability to aggregate the
   communications of multiple parties sharing the same physical
   facilities while obscuring higher-layer protocol information that
   indicates specific end points, such as IP addresses and TCP/UDP port
   numbers.

   However, traffic analysis is a notoriously subtle and difficult
   threat to understand and defeat, far more so than threats to
   confidentiality and integrity.  We therefore urge extreme care in the
   design of subnetwork security mechanisms specifically intended to
   thwart traffic analysis.

   Subnetwork designers must keep in mind that design and implementation
   for security is difficult [Schneier00].  [Schneier95] describes
   protocols and algorithms which are considered well-understood and
   believed to be sound.

   Poor design process, subtle design errors and flawed implementation
   can result in gaping vulnerabilities.  In recent years, a number of
   subnet standards have had problems exposed.  The following are
   examples of mistakes that have been made:

   1.  Use of weak and untested algorithms [Crypto9912] [BGW01].  For a
       variety of reasons, algorithms were chosen which had subtle
       flaws, making them vulnerable to a variety of attacks.

   2.  Use of "security by obscurity" [Schneier00] [Crypto9912].  One
       common mistake is to assume that keeping cryptographic algorithms
       secret makes them more secure.  This is intuitive, but wrong.
       Full public disclosure early in the design process attracts peer
       review by knowledgeable cryptographers.  Exposure of flaws by
       this review far outweighs any imagined benefit from forcing
       attackers to reverse engineer security algorithms.

   3.  Inclusion of trapdoors [Schneier00] [Crypto9912].  Trapdoors are
       flaws surreptitiously left in an algorithm to allow it to be
       broken.  This might be done to recover lost keys or to permit
       surreptitious access by governmental agencies.  Trapdoors can be
       discovered and exploited by malicious attackers.
Top   ToC   RFC3819 - Page 44
   4.  Sending passwords or other identifying information as clear text.
       For many years, analog cellular telephones could be cloned and
       used to steal service.  The cloners merely eavesdropped on the
       registration protocols that exchanged everything in clear text.

   5.  Keys which are common to all systems on a subnet [BGW01].

   6.  Incorrect use of a sound mechanism.  For example [BGW01], one
       subnet standard includes an initialization vector which is poorly
       designed and poorly specified.  A determined attacker can easily
       recover multiple ciphertexts encrypted with the same key stream
       and perform statistical attacks to decipher them.

   7.  Identifying information sent in clear text that can be resolved
       to an individual, identifiable device.  This creates a
       vulnerability to attacks targeted to that device (or its owner).

   8.  Inability to renew and revoke shared secret information.

   9.  Insufficient key length.

   10. Failure to address "man-in-the-middle" attacks, e.g., with mutual
       authentication.

   11. Failure to provide a form of replay detection, e.g., to prevent a
       receiver from accepting packets from an attacker that simply
       resends previously captured network traffic.

   12. Failure to provide integrity mechanisms when providing
       confidentiality schemes [Bel98].

   This list is by no means comprehensive.  Design problems are
   difficult to avoid, but expert review is generally invaluable in
   avoiding problems.

   In addition, well-designed security protocols can be compromised by
   implementation defects.  Examples of such defects include use of
   predictable pseudo-random numbers [RFC1750], vulnerability to buffer
   overflow attacks due to unsafe use of certain I/O system calls
   [WFBA2000], and inadvertent exposure of secret data.

19. Contributors

This document represents a consensus of the members of the IETF Performance Implications of Link Characteristics (PILC) working group.
Top   ToC   RFC3819 - Page 45
   This document would not have been possible without the contributions
   of a great number of people in the Performance Implications of Link
   Characteristics Working Group.  In particular, the following people
   provided major contributions of text, editing, and advice on this
   document: Mark Allman provided the final editing to complete this
   document.  Carsten Bormann provided text on robust header
   compression.  Gorry Fairhurst provided text on broadcast and
   multicast issues, routing,  and many valuable comments on the entire
   document.  Aaron Falk provided text on bandwidth on demand.  Dan
   Grossman provided text on many facets of the document.  Reiner Ludwig
   provided thorough document review and text on TCP vs. Link-Layer
   Retransmission.  Jamshid Mahdavi provided text on TCP performance
   calculations.  Saverio Mascolo provided feedback on the document.
   Gabriel Montenegro provided feedback on the document.  Marie-Jose
   Montpetit provided text on bandwidth on demand.  Joe Touch provided
   text on multicast, broadcast, and routing, and Lloyd Wood provided
   many valuable comments on versions of the document.

20. Informative References

References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at www.rfc-editor.org. [802.1D] Information Technology Telecommunications and information exchange between systems Local and metropolitan area networks, Common specifications Media access control (MAC) bridges, IEEE 802.1D, 1998. ISO 15802-3. [802.1p] IEEE, 802.1p, Standard for Local and Metropolitan Area Networks - Supplement to Media Access Control (MAC) Bridges: Traffic Class Expediting and Multicast. [AP99] Allman, M. and V. Paxson, On Estimating End-to-End Network Path Properties, In Proceedings of ACM SIGCOMM 99. [AR02] Acar, G. and C. Rosenberg, Weighted Fair Bandwidth-on- Demand (WFBoD) for Geo-Stationary Satellite Networks with On-Board Processing, Computer Networks, 39(1), 2002. [ATMFTM] The ATM Forum, "Traffic Management Specification, Version 4.0", April 1996, document af-tm-0056.000. http://www.atmforum.com/
Top   ToC   RFC3819 - Page 46
   [BA02]        Blanton, E. and M. Allman, On Making TCP More Robust to
                 Packet Reordering. ACM Computer Communication Review,
                 32(1), January 2002.

   [Bel98]       Bellovin, S., "Cryptography and the Internet", in
                 Proceedings of CRYPTO '98, August 1998.
                 http://www.research.att.com/~smb/papers/inet-crypto.pdf

   [BGW01]       Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
                 Mobile Communications: The Insecurity of 802.11," In
                 Proceedings of ACM MobiCom, July 2001.

   [BPK98]       Balakrishnan, H., Padmanabhan, V. and R. Katz.  "The
                 Effects of Asymmetry on TCP Performance."  ACM Mobile
                 Networks and Applications (MONET), 1998.

   [BPS99]       Bennet,, J.C.R., Partridge, C. and N. Shectman, "Packet
                 Reordering is Not Pathological Network Behavior",
                 IEEE/ACM Transactions on Networking, Vol. 7, No. 6,
                 December 1999.

   [CGMP]        Farinacci D., Tweedly A. and T. Speakman, "Cisco Group
                 Management Protocol (CGMP)", 1996/1997.
                 ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt

   [Crypto9912]  Schneier, B., "European Cellular Encryption Algorithms"
                 Crypto-Gram, December 15, 1999.
                 http://www.counterpane.com

   [DIX82]       Digital Equipment Corp, Intel Corp, Xerox Corp,
                 Ethernet Local Area Network Specification Version 2.0,
                 November 1982.

   [DOCSIS1]     Data-Over-Cable Service Interface Specifications, Radio
                 Frequency Interface Specification 1.0, SP-RFI-I05-
                 991105, November 1999, Cable Television Laboratories,
                 Inc.

   [DOCSIS2]     Data-Over-Cable Service Interface Specifications, Radio
                 Frequency Interface Specification 1.1, SP-RFIv1.1-I05-
                 000714, July 2000, Cable Television Laboratories, Inc.

   [DOCSIS3]     Lai, W.S., "DOCSIS-Based Cable Networks: Impact of
                 Large Data Packets on Upstream Capacity", 14th ITC
                 Specialists Seminar on Access Networks and Systems,
                 Barcelona, Spain, April 25-27, 2001.
Top   ToC   RFC3819 - Page 47
   [EN301192]    ETSI, European Broadcasting Union, Digital Video
                 Broadcasting (DVB); DVB Specification for Data
                 Broadcasting, European Standard (Telecommunications
                 Series)  EN 301 192 v1.2.1(1999-06).

   [ES00]        Eckhardt, D. and P. Steenkiste, "Effort-limited Fair
                 (ELF) Scheduling for Wireless Networks, Proceedings of
                 IEEE Infocom 2000.

   [FB00]        Firoiu V. and M. Borden, "A Study of Active Queue
                 Management for Congestion Control" to appear in Infocom
                 2000.

   [GM02]        Grieco1, L. and S. Mascolo, "TCP Westwood and Easy RED
                 to Improve Fairness in High-Speed Networks",
                 Proceedings of the 7th International Workshop on
                 Protocols for High-Speed Networks, April 2002.

   [IEEE8023]    IEEE 802.3 CSMA/CD Access Method.
                 http://standards.ieee.org/

   [IEEE80211]   IEEE 802.11 Wireless LAN standard.
                 http://standards.ieee.org/

   [ISO3309]     ISO/IEC 3309:1991(E), "Information Technology -
                 Telecommunications and information exchange between
                 systems - High-level data link control (HDLC)
                 procedures - Frame structure", International
                 Organization For Standardization, Fourth edition 1991-
                 06-01.

   [ISO13818]    ISO/IEC, ISO/IEC 13818-1:2000(E)  Information
                 Technology - Generic coding of moving pictures and
                 associated audio information:  Systems, Second edition,
                 2000-12-01 International Organization for
                 Standardization and International Electrotechnical
                 Commission.

   [ITU-I363]    ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification
                 Type AAL5, International Standards Organisation (ISO),
                 1996.

   [Jac90]       Jacobson, V., Modified TCP Congestion Avoidance
                 Algorithm.  Email to the end2end-interest mailing list,
                 April 1990.
                 ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
Top   ToC   RFC3819 - Page 48
   [KY02]        Khafizov, F. and M. Yavuz, Running TCP Over IS-2000,
                 Proceedings of IEEE ICC, 2002.

   [LK00]        Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making
                 TCP Robust Against Spurious Retransmissions", ACM
                 Computer Communication Review, Vol. 30, No. 1, January
                 2000.

   [LKJK02]      Ludwig, R., Konrad, A., Joseph, A. D. and R. H. Katz,
                 "Optimizing the End-to-End Performance of Reliable
                 Flows over Wireless Links", Kluwer/ACM Wireless
                 Networks Journal, Vol. 8, Nos. 2/3, pp. 289-299,
                 March-May 2002.

   [LRKOJ99]     Ludwig, R., Rathonyi, B., Konrad, A., Oden, K. and A.
                 Joseph, Multi-Layer Tracing of TCP over a Reliable
                 Wireless Link, pp. 144-154, In Proceedings of ACM
                 SIGMETRICS 99.

   [LS00]        Ludwig, R. and K. Sklower, The Eifel Retransmission
                 Timer, ACM Computer Communication Review, Vol. 30, No.
                 3, July 2000.

   [MAGMA-PROXY] Fenner, B., He, H., Haberman, B. and H. Sandick,
                 "IGMP/MLD-based Multicast Forwarding ("IGMP/MLD
                 Proxying")", Work in Progress.

   [MAGMA-SNOOP] Christensen, M., Kimball, K. and F. Solensky,
                 "Considerations for IGMP and MLD Snooping Switches",
                 Work in Progress.

   [MBB00]       May, M., Bonald, T. and J-C. Bolot, "Analytic
                 Evaluation of RED Performance", INFOCOM 2000.

   [MBDL99]      May, M., Bolot, J., Diot, C. and B. Lyles, "Reasons not
                 to deploy RED", Proc. of 7th. International Workshop on
                 Quality of Service (IWQoS'99), June 1999.

   [MSMO97]      Mathis, M., Semke, J., Mahdavi, J. and T. Ott, "The
                 Macroscopic Behavior of the TCP Congestion Avoidance
                 Algorithm", Computer Communication Review, Vol. 27,
                 number 3, July 1997.

   [MYR95]       Boden, N., Cohen, D., Felderman, R., Kulawik, A.,
                 Seitz, C., et al.  MYRINET: A Gigabit per Second Local
                 Area Network, IEEE-Micro, Vol. 15, No.1, February 1995,
                 pp. 29-36.
Top   ToC   RFC3819 - Page 49
   [PFTK98]      Padhye, J., Firoiu, V., Towsley, D. and J. Kurose,
                 "Modeling TCP Throughput: a Simple Model and its
                 Empirical Validation", UMASS CMPSCI Tech Report TR98-
                 008, Feb. 1998.

   [RED93]       Floyd, S. and V. Jacobson, "Random Early Detection
                 gateways for Congestion Avoidance", IEEE/ACM
                 Transactions in Networking, Vol. 1 No. 4, August 1993.
                 http://www.aciri.org/floyd/papers/red/red.html

   [RF95]        Romanow, A. and S. Floyd, "Dynamics of TCP Traffic over
                 ATM Networks".  IEEE Journal of Selected Areas in
                 Communication, Vol.13 No.  4, May 1995, p. 633-641.

   [RFC791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
                 September 1981.

   [RFC793]      Postel, J., "Transmission Control Protocol", STD 7, RFC
                 793, September 1981.

   [RFC768]      Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                 August 1980.

   [RFC826]      Plummer, D.C., "Ethernet Address Resolution Protocol:
                 Or converting network protocol addresses to 48-bit
                 Ethernet address for transmission on Ethernet
                 hardware", STD 37, RFC 826, November 1982.

   [RFC1071]     Braden, R., Borman, D. and C. Partridge, "Computing the
                 Internet checksum", RFC 1071, September 1988.

   [RFC1112]     Deering, S., "Host Extensions for IP Multicasting", STD
                 5, RFC 1112, August 1989.

   [RFC1144]     Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
                 Serial Links", RFC 1144, February 1990.

   [RFC1191]     Mogul, J. and S. Deering, "Path MTU Discovery", RFC
                 1191, November 1990.

   [RFC1332]     McGregor, C., "The PPP Internet Protocol Control
                 Protocol (IPCP)", RFC 1332, May 1992.

   [RFC1435]     Knowles, S., "IESG Advice from Experience with Path MTU
                 Discovery", RFC 1435, March 1993.
Top   ToC   RFC3819 - Page 50
   [RFC1633]     Braden, R., Clark, D. and S. Shenker, "Integrated
                 Services in the Internet Architecture: an Overview",
                 RFC 1633, June 1994.

   [RFC1661]     Simpson, W., "The Point-to-Point Protocol (PPP)", STD
                 51, RFC 1661, July 1994.

   [RFC1662]     Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51,
                 RFC 1662, July 1994.

   [RFC1750]     Eastlake 3rd, D., Crocker, S. and J. Schiller,
                 "Randomness Recommendations for Security", RFC 1750,
                 December 1994.

   [RFC1812]     Baker, F., Ed., "Requirements for IP Version 4
                 Routers", RFC 1812, June 1995.

   [RFC1939]     Myers, J. and M. Rose, "Post Office Protocol - Version
                 3", STD 53, RFC 1939, May 1996.

   [RFC1981]     McCann, J., Deering, S. and J. Mogul, "Path MTU
                 Discovery for IP version 6", RFC 1981, August 1996.

   [RFC1991]     Atkins, D., Stallings, W. and P. Zimmermann, "PGP
                 Message Exchange Formats", RFC 1991, August 1996.

   [RFC2018]     Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
                 Selective Acknowledgement Options", RFC 2018, October
                 1996.

   [RFC2131]     Droms, R., "Dynamic Host Configuration Protocol", RFC
                 2131, March 1997.

   [RFC2205]     Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and
                 S. Jamin, "Resource ReSerVation Protocol (RSVP) --
                 Version 1 Functional Specification", RFC 2205,
                 September 1997.

   [RFC2208]     Mankin, A., Baker, F., Braden, B., Bradner, S., O`Dell,
                 M., Romanow, A., Weinrib, A. and L. Zhang, "Resource
                 ReSerVation Protocol (RSVP) -- Version 1 Applicability
                 Statement Some Guidelines on Deployment", RFC 2208,
                 September 1997.

   [RFC2210]     Wroclawski, J., "The Use of RSVP with IETF Integrated
                 Services", RFC 2210, September 1997.
Top   ToC   RFC3819 - Page 51
   [RFC2211]     Wroclawski, J., "Specification of the Controlled-Load
                 Network Element Service", RFC 2211, September 1997.

   [RFC2212]     Shenker, S., Partridge, C. and R. Guerin,
                 "Specification of Guaranteed Quality of Service", RFC
                 2212, September 1997.

   [RFC2246]     Dierks, T. and C. Allen, "The TLS Protocol Version
                 1.0", RFC 2246, January 1999.

   [RFC2309]     Braden, B., Clark, D., Crowcroft, J., Davie, B.,
                 Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
                 Minshall, G., Partridge, C., Peterson, L.,
                 Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
                 Zhang, "Recommendations on Queue Management and
                 Congestion Avoidance in the Internet", RFC 2309, April
                 1998.

   [RFC2322]     van den Hout, K., Koopal, A. and R. van Mook,
                 "Management of IP numbers by peg-dhcp", RFC 2322, 1
                 April 1998.

   [RFC2328]     Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
                 1998.

   [RFC2332]     Luciani, J., Katz, D., Piscitello, D., Cole, B. and N.
                 Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)",
                 RFC 2332, April 1998.

   [RFC2364]     Gross, G., Kaycee, M., Li, A., Malis, A. and J.
                 Stephens, "PPP Over AAL5", RFC 2364, July 1998.

   [RFC2394]     Pereira, R., "IP Payload Compression Using DEFLATE",
                 RFC 2394, December 1998.

   [RFC2395]     Friend, R. and R. Monsour, "IP Payload Compression
                 Using LZS", RFC 2395, December 1998.

   [RFC2401]     Kent, S. and R. Atkinson, "Security Architecture for
                 the Internet Protocol", RFC 2401, November 1998.

   [RFC2406]     Kent, S. and R. Atkinson, "IP Encapsulating Security
                 Payload (ESP)", RFC 2406, November 1998.

   [RFC2440]     Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
                 "OpenPGP Message Format", RFC 2440, November 1998.
Top   ToC   RFC3819 - Page 52
   [RFC2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
                 6 (IPv6) Specification", RFC 2460, December 1998.

   [RFC2461]     Narten, T., Nordmark, E. and W. Simpson, "Neighbor
                 Discovery for IP Version 6 (IPv6)", RFC 2461, December
                 1998.

   [RFC2474]     Nichols, K., Blake, S., Baker, F. and D. Black,
                 "Definition of the Differentiated Services Field (DS
                 Field) in the IPv4 and IPv6 Headers", RFC 2474,
                 December 1998.

   [RFC2475]     Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
                 and W. Weiss, "An Architecture for Differentiated
                 Services", RFC 2475, December 1998.

   [RFC2507]     Degermark, M., Nordgren, B. and S. Pink, "IP Header
                 Compression", RFC 2507, February 1999.

   [RFC2508]     Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
                 Headers for Low-Speed Serial Links", RFC 2508, February
                 1999.

   [RFC2581]     Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
                 Control", RFC 2581, April 1999.

   [RFC2582]     Floyd, S. and T. Henderson, "The NewReno Modification
                 to TCP's Fast Recovery Algorithm", RFC 2582, April
                 1999.

   [RFC2597]     Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
                 "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2630]     Housley, R., "Cryptographic Message Syntax", RFC 2630,
                 June 1999.

   [RFC2631]     Rescorla, E., "Diffie-Hellman Key Agreement Method",
                 RFC 2631, June 1999.

   [RFC2632]     Ramsdell, B., Ed., "S/MIME Version 3 Certificate
                 Handling", RFC 2632, June 1999.
Top   ToC   RFC3819 - Page 53
   [RFC2633]     Ramsdell, B., "S/MIME Version 3 Message Specification",
                 RFC 2633, June 1999.

   [RFC2634]     Hoffman, P., "Enhanced Security Services for S/MIME",
                 RFC 2634, June 1999.

   [RFC2684]     Grossman, D. and J. Heinanen, "Multiprotocol
                 Encapsulation over ATM Adaptation Layer 5", RFC 2684,
                 September 1999.

   [RFC2686]     Bormann, C., "The Multi-Class Extension to Multi-Link
                 PPP", RFC 2686, September 1999.

   [RFC2687]     Bormann, C., "PPP in a Real-time Oriented HDLC-like
                 Framing", RFC 2687, September 1999.

   [RFC2689]     Bormann, C., "Providing Integrated Services over Low-
                 bitrate Links", RFC 2689, September 1999.

   [RFC2710]     Deering, S., Fenner, W. and B. Haberman, "Multicast
                 Listener Discovery (MLD) for IPv6", RFC 2710, October
                 1999.

   [RFC2784]     Farinacci, D., Li, T., Hanks, S., Meyer, D. and P.
                 Traina, "Generic Routing Encapsulation (GRE)", RFC
                 2784, March 2000.

   [RFC2865]     Rigney, C., Willens, S., Rubens, A. and W. Simpson,
                 "Remote Authentication Dial In User Service (RADIUS)",
                 RFC 2865, June 2000.

   [RFC2914]     Floyd, S., "Congestion Control Principles", BCP 41, RFC
                 2914, September 2000.

   [RFC2923]     Lahey, K., "TCP Problems with Path MTU Discovery", RFC
                 2923, September 2000.

   [RFC2988]     Paxson, V. and M. Allman, "Computing TCP's
                 Retransmission Timer", RFC 2988, November 2000.

   [RFC2990]     Huston, G., "Next Steps for the IP QoS Architecture",
                 RFC 2990, November 2000.

   [RFC3048]     Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
                 Floyd, S. and M. Luby, "Reliable Multicast Transport
                 Building Blocks for One-to-Many Bulk-Data Transfer",
                 RFC 3048, January 2001.
Top   ToC   RFC3819 - Page 54
   [RFC3095]     Bormann, C., Ed., Burmeister, C., Degermark, M.,
                 Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R.,
                 Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki,
                 A., Svanbro, K., Wiebke, T., Yoshimura, T. and H.
                 Zheng, "RObust Header Compression (ROHC):  Framework
                 and four profiles: RTP, UDP, ESP, and uncompressed",
                 RFC 3095, July 2001.

   [RFC3096]     Degermark, M., Ed., "Requirements for robust IP/UDP/RTP
                 header compression", RFC 3096, July 2001.

   [RFC3150]     Dawkins, S., Montenegro, G., Kojo, M. and V. Magret,
                 "End-to-end Performance Implications of Slow Links",
                 BCP 48, RFC 3150, July 2001.

   [RFC3155]     Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and
                 N. Vaidya, "End-to-end Performance Implications of
                 Links with Errors", BCP 50, RFC 3155, August 2001.

   [RFC3168]     Ramakrishnan, K., Floyd, S. and D. Black, "The Addition
                 of Explicit Congestion Notification (ECN) to IP", RFC
                 3168, September 2001.

   [RFC3173]     Shacham, A., Monsour, B., Pereira, R. and M. Thomas,
                 "IP Payload Compression Protocol (IPComp)", RFC 3173,
                 September 2001.

   [RFC3246]     Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
                 Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and
                 D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
                 Behavior)", RFC 3246, March 2002.

   [RFC3248]     Armitage, G., Carpenter, B., Casati, A., Crowcroft, J.,
                 Halpern, J., Kumar, B. and J. Schnizlein, "A Delay
                 Bound alternative revision of RFC 2598", RFC 3248,
                 March 2002.

   [RFC3344]     Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
                 3344, August 2002.

   [RFC3366]     Fairhurst, G. and L. Wood, "Advice to link designers on
                 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
                 August 2002.
Top   ToC   RFC3819 - Page 55
   [RFC3376]     Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
                 Thyagarajan, "Internet Group Management Protocol,
                 Version 3", RFC 3376, October 2002.

   [RFC3449]     Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
                 Sooriyabandara, "TCP Performance Implications of
                 Network Path Asymmetry", BCP 69, RFC 3449, December
                 2002.

   [RFC3450]     Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J.
                 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
                 Instantiation", RFC 3450, December 2002.

   [RFC3451]     Luby, M., Gemmell, J., Vicisano, L., Rizzo, L.,
                 Handley, M. and J. Crowcroft, "Layered Coding Transport
                 (LCT) Building Block", RFC 3451, December 2002.

   [RFC3452]     Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
                 Handley, M. and J. Crowcroft, "Forward Error Correction
                 (FEC) Building Block", RFC 3452, December 2002.

   [RFC3453]     Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
                 Handley, M. and J. Crowcroft, "The Use of Forward Error
                 Correction (FEC) in Reliable Multicast", RFC 3453,
                 December 2002.

   [RFC3488]     Wu, I. and T. Eckert, "Cisco Systems Router-port Group
                 Management Protocol (RGMP)", RFC 3488, February 2003.

   [RFC3501]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
                 VERSION 4rev1", RFC 3501, March 2003.

   [RFC3828]     Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
                 Ed. and G. Fairhurst, Ed., "The User Datagram Protocol
                 (UDP)-Lite Protocol", RFC 3828, June 2004.

   [Schneier95]  Schneier, B., Applied Cryptography: Protocols,
                 Algorithms and Source Code in C (John Wiley and Sons,
                 October 1995).

   [Schneier00]  Schneier, B., Secrets and Lies: Digital Security in a
                 Networked World (John Wiley and Sons, August 2000).

   [SP2000]      Stone, J. and C. Partridge, "When the CRC and TCP
                 Checksum Disagree", ACM SIGCOMM, September 2000.
                 http://www.acm.org/sigcomm/sigcomm2000/conf/
                 paper/sigcomm2000-9-1.pdf
Top   ToC   RFC3819 - Page 56
   [SRC81]       Saltzer, J., Reed D. and D. Clark, "End-to-End
                 Arguments in System Design".  Second International
                 Conference on Distributed Computing Systems (April,
                 1981) pages 509-512. Published with minor changes in
                 ACM Transactions in Computer Systems 2, 4, November,
                 1984, pages 277-288. Reprinted in Craig Partridge,
                 editor Innovations in internetworking. Artech House,
                 Norwood, MA, 1988, pages 195-206. ISBN 0-89006-337-0.

   [SSL2]        Hickman, K., "The SSL Protocol", Netscape
                 Communications Corp., Feb 9, 1995.

   [SSL3]        Frier, A., Karlton, P. and P. Kocher, "The SSL 3.0
                 Protocol", Netscape Communications Corp., Nov 18, 1996.

   [TCPF98]      Lin, D. and H.T. Kung, "TCP Fast Recovery Strategies:
                 Analysis and Improvements", IEEE Infocom, March 1998.
                 http://www.eecs.harvard.edu/networking/papers/infocom-
                 tcp-final-198.pdf

   [WFBA2000]    Wagner, D., Foster, J., Brewer, E. and A. Aiken, "A
                 First Step Toward Automated Detection of Buffer Overrun
                 Vulnerabilities", Proceedings of NDSS2000.
                 http://www.isoc.org/isoc/conferences/ndss/
                 2000/proceedings/039.pdf

   [Wilbur89]    Wilbur, Steve R., Jon Crowcroft, and Yuko Murayama.
                 "MAC layer Security Measures in Local Area Networks",
                 Local Area Network Security, Workshop LANSEC '89
                 Proceedings, Springer-Verlag, April 1989, pp. 53-64.
Top   ToC   RFC3819 - Page 57

21. Contributors' Addresses

Aaron Falk USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey, CA 90292 Phone: 310-448-9327 EMail: falk@isi.edu Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica, Politecnico di Bari Via Orabona 4, 70125 Bari, Italy Phone: +39 080 596 3621 EMail: mascolo@poliba.it URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html Marie-Jose Montpetit MJMontpetit.com EMail: marie@mjmontpetit.com
Top   ToC   RFC3819 - Page 58

22. Authors' Addresses

Phil Karn, Editor Qualcomm 5775 Morehouse Drive San Diego CA 92121 Phone: 858 587 1121 EMail: karn@qualcomm.com Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany Phone: +49 421 218 7024 Fax: +49 421 218 7000 EMail: cabo@tzi.org Godred (Gorry) Fairhurst Department of Engineering, University of Aberdeen, Aberdeen, AB24 3UE, United Kingdom EMail: gorry@erg.abdn.ac.uk URL: http://www.erg.abdn.ac.uk/users/gorry Dan Grossman Motorola, Inc. 111 Locke Drive Marlboro, MA 01752 EMail: Dan.Grossman@motorola.com Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany Phone: +49 2407 575 719 EMail: Reiner.Ludwig@ericsson.com
Top   ToC   RFC3819 - Page 59
   Jamshid Mahdavi
   Novell, Inc.

   EMail: jmahdavi@earthlink.net


   Gabriel Montenegro
   Sun Microsystems Laboratories, Europe
   180, Avenue de l'Europe
   38334 Saint Ismier CEDEX
   France

   EMail: gab@sun.com


   Joe Touch
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey CA 90292

   Phone: 310 448 9151
   EMail: touch@isi.edu
   URL: http://www.isi.edu/touch


   Lloyd Wood
   Cisco Systems
   9 New Square Park, Bedfont Lakes
   Feltham TW14 8HA
   United Kingdom

   Phone: +44 (0)20 8824 4236
   EMail: lwood@cisco.com
   URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
Top   ToC   RFC3819 - Page 60

23. 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.