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