| TOC |
|
This note attempts to identify the key protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is who want guidance on how to profile the Internet Protocol Suite. In general, that would mean selecting what they need from the picture presented here.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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.”
This Internet-Draft will expire on January 10, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
2.
The Internet Protocol Suite
2.1.
Internet Protocol Layers
2.1.1.
Application
2.1.2.
Transport
2.1.3.
Network
2.1.3.1.
Internet Protocol
2.1.3.2.
Lower layer networks
2.1.4.
Media layers: Physical and Link
2.2.
Security issues
2.2.1.
Physical security
2.2.2.
Session identification
2.2.3.
Confidentiality
2.3.
Network Infrastructure
2.3.1.
Domain Name System (DNS)
2.3.2.
Network Management Issues
3.
Specific protocols
3.1.
Security solutions
3.1.1.
Session identification, authentication, authorization, and accounting
3.1.2.
IP Security Architecture (IPsec)
3.1.3.
Transport Layer Security (TLS)
3.1.4.
Secure/Multipurpose Internet Mail Extensions (S/MIME)
3.2.
Network Layer
3.2.1.
Internet Protocol Version 4
3.2.1.1.
IPv4 Address Allocation and Assignment
3.2.1.2.
IPv4 Unicast Routing
3.2.1.3.
IPv4 Multicast Forwarding and Routing
3.2.2.
Internet Protocol Version 6
3.2.2.1.
IPv6 Address Allocation and Assignment
3.2.2.2.
IPv6 Routing
3.2.2.3.
IPv6 Multicast Forwarding and Routing
3.2.3.
Adaptation to lower layer networks and link layer protocols
3.3.
Transport Layer
3.3.1.
User Datagram Protocol (UDP)
3.3.2.
Transmission Control Protocol (TCP)
3.3.3.
Stream Control Transmission Protocol (SCTP)
3.3.4.
Datagram Congestion Control Protocol (DCCP)
3.4.
Infrastructure
3.4.1.
Domain Name System
3.4.2.
Dynamic Host Configuration
3.5.
Other Applications
3.5.1.
Network Time
3.5.2.
Session Initiation Protocol
3.5.3.
Calendaring
4.
A simplified view of the business architecture
5.
IANA Considerations
6.
Security Considerations
7.
Acknowledgements
8.
References
8.1.
Normative References
8.2.
Informative References
§
Author's Address
| TOC |
In the discussion of the Smart Grid, a question has arisen as to how best to "profile" the Internet Protocol Suite are. In this note, I will attempt to identify the structure of the Internet Protocol Suite and the key protocols that should be considered as critical in integrating Smart Grid devices into an IP-based infrastructure. In many cases, the protocols are options - one might choose, for example, TCP, SCTP, DCCP, or some other transport, or use expand upon UDP, building the transport into the application itself. In the Transport layer, therefore, one is not limited to exactly one of those, nor is one required to implement them all. One should, however, pick the right one for the purpose one intends. This kind of discussion will be had at every layer.
The set of protocols defined in this document focus on the use of the IP Protocol Suite in end systems, also known as hosts. In the Smart Grid, these end systems will be various devices such as power meters, sensors and actuators. These end systems can leverage infrastructure built on networking components using the IP Protocol Suite, which have well-proven implementations and deployments in the Internet. That said, it also goes on to mention network-only technology including routing protocols and circuit switching models, which may be useful in networks supporting the Smart Grid.
For its own purposes, the IETF has written several documents that describe its expectations regarding implementations of the Internet Protocol Suite. These include:
At this writing, RFC 4294 is in the process of being updated, in [I‑D.ietf‑6man‑node‑req‑bis] (Jankiewicz, E., Loughney, J., and T. Narten, “IPv6 Node Requirements RFC 4294-bis,” March 2010.).
This document will read like an annotated list of RFCs. That is because that is what it is.
| TOC |
Before listing a list of protocols, it would be well to lay out how they relate to each other. In this section, we will discuss the layered architecture of the Internet Protocol Suite and the jobs of the various layers and their protocols.
| TOC |
The Internet Architecture uses the definitions and language of the ISO Open System Interconnect Reference Model, as shown in Figure 1 (The ISO OSI Reference Model). It actually predates that model, and as a result uses some different words - an "end system" is generally called a "host", and an "intermediate system" is more generally called an "internet gateway" or "router". But the fundamental concepts are essentially the same.
+--------------------+ | Application Layer | +--------------------+ | Presentation Layer | +--------------------+ | Session Layer | +--------------------+ | Transport layer | +--------------------+ | Network Layer | +--------------------+ | Data Link Layer | +--------------------+ | Physical Layer | +--------------------+
| Figure 1: The ISO OSI Reference Model |
The structure of the Internet reference Model looks something like Figure 2 (The Internet Reference Model).
+---------------------------------+ |Application | | +---------------------------+ | | | Application Protocol | | | +----------+----------------+ | | | Encoding | Session Control| | | +----------+----------------+ | +---------------------------------+ |Transport | | +---------------------------+ | | | Transport layer | | | +---------------------------+ | +---------------------------------+ |Network | | +---------------------------+ | | | Internet Protocol | | | +---------------------------+ | | | Lower network layers | | | +---------------------------+ | +---------------------------------+ |Media layers | | +---------------------------+ | | | Data Link Layer | | | +---------------------------+ | | | Physical Layer | | | +---------------------------+ | +---------------------------------+
| Figure 2: The Internet Reference Model |
| TOC |
In implementation, the Application, Presentation, and Session layers are generally compressed into a single entity, which the IETF calls "the application". The SNMP protocol, for example, describes an application (a management application or a client that it communicates with) that encodes its data in a profile of ASN.1 (a presentation layer) and engages in a session to manage a network element. In the Internet, therefore, the distinction between these layers exists but is not generally highlighted. Note, in Figure 2 (The Internet Reference Model), that these are not necessarily cleanly layered: the fact that an application protocol encodes its data in some way and that it manages sessions in some way doesn't imply a hierarchy between those processes. Rather, the application views encoding, session management, and a variety of other services as a tool set that it uses while doing its work.
| TOC |
The term "transport" is perhaps among the most confusing words in the communication architecture, because people with various backgrounds use it to refer to "the layer below that which I am interested in, which gets my data to my peer". In these contexts, optical fiber and other physical layers, the Internet Protocol or other networked protocols, and in some cases application layer protocols like HTTP are referred to as "the transport".
In the Internet context, the "transport" is the lowest layer that travels end-to-end unmodified, and is responsible for end-to-end data delivery services. At minimum these include the ability to multiplex several applications on one IP address, and may also include the delivery of data (either as a stream of messages or a stream of bytes) in a stated sequence with stated expectations regarding delivery rate and loss. TCP, for example, will reduce rate to avoid loss, while DCCP accepts some level of loss if necessary to maintain timeliness.
| TOC |
The network layer is nominally that which identifies a remote destination and gets data to it. In connection-oriented networking, such as MPLS or ATM, a path (one of many "little tubes") is set up once, and data is delivered through it. In connectionless ("datagram") networks, which include Ethernet and IP among others, each datagram contains the addresses of both the source and destination devices, and the network is responsible to deliver it.
| TOC |
IPv4 and IPv6, each of which is called the Internet Protocol, are connectionless ("datagram") architectures. They are designed as common elements that interconnect network elements across a network of lower layer networks. In addition to the basic service of identifying a datagram's source and destination, they offer services to fragment and reassemble datagrams when necessary, assist in diagnosis of network failures, and carry additional information necessary in special cases.
The Internet Layer provides a uniform network abstraction or virtual network that hides the differences between different network technologies. This is the layer that allows diverse networks such as Ethernet, 802.15.4, etc. to be combined into a uniform IP network. New network technologies can be introduced into the IP Protocol Suite by defining how IP is carried over those technologies, leaving the other layers of the IP Protocol Suite and applications that use those protocol unchanged.
| TOC |
The network layer is recursively subdivided as needed. For various reasons, IP may be carried in virtual private networks across more public networks using tunneling technologies like IP-in-IP or GRE, traffic engineered in circuit networks such as MPLS, GMPLS, or ATM, and distributed across local wireless (IEEE 802.11, 802.15.4, or 802.16) and switched Ethernet (IEEE 802.3).
| TOC |
At the lowest layer of the architecture, we encode digital data in messages onto appropriate physical media. While the IETF specifies algorithms for carrying IPv4 and IPv6 on such media, it rarely actually defines the media - it happily uses specifications from IEEE, ITU, and other sources.
| TOC |
It is popular to complain about the security of the Internet; that said, solutions exist but are often left unused. As with automobile seat belts, they are of more value when actively used. Security designs attempt to mitigate a set of known threats at a specified cost; addressing security issues requires first a threat analysis and assessment and a set of mitigations appropriate to the threats. Since we have threats at every layer, we should expect to find mitigations at every layer.
| TOC |
At the physical and data link layers, threats involve physical attacks on the network - the effects of backhoes, deterioration of physical media, and various kinds of environmental noise. Radio-based networks are subject to signal fade due to distance, interference, and environmental factors; it is widely noted that IEEE 802.15.4 networks frequently place a metal ground plate between the meter and the device that manages it. Fiber was at one time deployed because it was believed to be untappable; we have since learned to tap it by bending the fiber and collecting incidental light, and we have learned about backhoes. So now some installations encase fiber optic cable in a pressurized sheath, both to quickly identify the location of a cut and to make it more difficult to tap.
While there are protocol behaviors that can detect certain classes of physical faults, such as keep-alive exchanges, physical security is generally not a protocol problem.
| TOC |
At the transport and application layers, and in lower layer networks where dynamic connectivity like ATM SVCs or "dial" connectivity is in use, there tend to be several different classes of authentication/authorization requirements. One must
In other words, there is a need to secure the channel that carries a message, and there is a need to secure the exchanges, both by knowing the source of the information and to have proof of its validity. Three examples suffice to illustrate the challenges.
One common attack is to bombard a transport session (an application's channel) with reset messages. If the attacker is lucky, he might cause the session to fail. Including information in the transport header or a related protocol like IPsec or TLS that identifies the right messages and facilitates speedy discard of the rest can mitigate this.
Another common attack involves unauthorized communication with a router or a service. For example, an unauthorized party might try to join the routing system. One wants the ISP's router, before accepting routing information from a new peer, to
More generally, in securing the channel, one wants to verify that messages putatively received from a peer were in fact received from the peer, and given that they are, to only carry on transactions with peers that one trusts. This is analogous to how one responds to a salesman at the front door - one asks who the salesman represents, seeks a credential as proof, and then asks one self whether one wants to deal with that company. Only if all indications are positive does one carry on a transaction.
Unfortunately, even trusted peers can be the purveyors of incorrect or malicious content; having secured the channel, one also wants to secure the information exchanged through the channel. In electronic mail and other database exchanges, it may be necessary to be able to verify the identity of the sender and the correctness of the content long after the information exchange has occurred - for example, if a contract is exchanged that is secured by digital signatures, one will wish to be able to verify those signatures at least throughout the lifetime of the contract, and probably a long time after that.
The third "A" in "AAA" is Accounting. This service is especially important for Internet Service Providers; the related service of auditing is important for enterprises. RADIUS and DIAMETER are commonly used to realize these services.
| TOC |
At several layers, there is a question of confidentiality. If one is putting one's credit card in a transaction, one wants application layer privacy, which might be supplied by an encrypting application or transport layer protocol. If one is trying to hide one's network structure, one might additionally want to encrypt the network layer header.
| TOC |
While these are not critical to the design of a specific system, they are important to running a network. We therefore bring them up.
| TOC |
While not critical to running a network, certain functions are made a lot easier if numeric addresses can be replaced with mnemonic names. This facilitates renumbering of networks, which happens, and generally improves the manageability and serviceability of the network. DNS has a set of security extensions called DNSSEC, which can be used to provide strong cryptographic authentication to that protocol.
| TOC |
Network management has proven to be a difficult problem; there are many solutions, and each has proponents with solid arguments for their viewpoint. In the IETF, we have two major network management solutions for device operation: SNMP, which is ASN.1-encoded and is primarily used for monitoring of system variables in a polled architecture, and NetConf, which is XML-encoded and primarily used for device configuration.
Another aspect of network management is the initial provisioning and configuration of hosts. Address assignment and other configuration is discussed in Section 3.4.2 (Dynamic Host Configuration). Smart Grid deployments will require additional identity authentication and authorization as well as other provisioning and configuration that may not be within the scope of DHCP and Neighbor Discovery. While the IP Protocol Suite does not have specific solutions for secure provisioning and configuration, these problems have been solved using IP protocols in specifications such as DOCSIS 3.0 (CableLabs, “DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I10-090529,” May 2009.) [SP‑MULPIv3.0].
| TOC |
In this section, having briefly laid out the architecture and some of the problems that the architecture tries to address, we introduce specific protocols that might be appropriate to various use cases. In each place, the options are in the protocols used - one wants to select the right privacy, AAA, transport, and network solutions in each case.
| TOC |
As noted, a key consideration in security solutions is a good threat analysis coupled with appropriate mitigations at each layer.
| TOC |
In the Internet Protocol Suite there are several approaches to AAA issues; generally, one chooses one of them for a purpose. As they have different attack surfaces and protection domains, they require some thought in application. Two important ones are the IP Security Architecture, which protects IP datagrams, and Transport Layer Security, which protects the information that the Transport delivers.
| TOC |
The Security Architecture for the Internet Protocol (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) [RFC4301] is a set of control and data protocols that are implemented between IPv4 and its Transport layer, or in IPv6's Security extension header. It allows transport layer sessions (which underlie applications) to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The architecture is spelled out in a number of additional specifications for specific components: the IP Authentication Header (AH) (Kent, S., “IP Authentication Header,” December 2005.) [RFC4302] Encapsulating Security Payload (ESP) (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) [RFC4303], Internet Key Exchange (IKEv2) (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) [RFC4306], Cryptographic Algorithms (Schiller, J., “Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2),” December 2005.) [RFC4307], Cryptographic Algorithm Implementation Requirements for ESP and AH (Manral, V., “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH),” April 2007.) [RFC4835], and the use of Advanced Encryption Standard (AES) (Housley, R., “Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP),” December 2005.) [RFC4309].
In the transport mode, IPsec ESP encrypts the transport layer and the application data. In the tunnel mode, which is frequently used for Virtual Private Networks, one also encrypts the Internet Protocol, and encapsulates the encrypted data inside a second IP header directed to the intended decryptor.
| TOC |
Transport Layer Security (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] and Datagram Transport Layer Security (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” April 2006.) [RFC4347][I‑D.ietf‑tls‑rfc4347‑bis] (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security version 1.2,” October 2009.) are mechanisms that travel within the transport layer PDU, meaning that they readily traverse network address translators and secure the information exchanges without securing the datagrams exchanged or the transport layer itself. Each allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
| TOC |
The S/MIME (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) [RFC2045] [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [RFC2047] (Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text,” November 1996.) [RFC4289] (Freed, N. and J. Klensin, “Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures,” December 2005.) [RFC2049] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples,” November 1996.) [RFC3850] (Ramsdell, B., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling,” July 2004.) [RFC3851] (Ramsdell, B., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification,” July 2004.) [RFC4262] (Santesson, S., “X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities,” December 2005.) specification was originally specified as an extension to SMTP Mail to provide evidence that the putative sender of an email message in fact sent it, and that the content received was in fact the content that was sent. As its name suggests, by extension this is a way of securing any object that can be exchanged, by any means, and has become one of the most common ways to secure an object.
Other approaches also exist, such as the use of digital signatures on XML-encoded files, as jointly standardized by W3C and the IETF [RFC3275] (Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” March 2002.).
| TOC |
Here we mention both IPv4 and IPv6. The reader is warned: IPv4 is running out of address space, and IPv6 has positive reasons that one might choose it apart from the IPv6 space such as the address autoconfiguration facility and its ability to support an arbitrarily large number of hosts in a subnet. As such, the IETF recommends that one always choose IPv6 support, and additionally choose IPv4 support in the near term.
| TOC |
IPv4 (Postel, J., “Internet Protocol,” September 1981.) [RFC0791], with the Internet Control Message Protocol (Postel, J., “Internet Control Message Protocol,” September 1981.) [RFC0792], constitutes the traditional protocol implemented throughout the Internet. IPv4 provides for transmission of datagrams from source to destination hosts, which are identified by fixed length addresses.
IPv4 also provides for fragmentation and reassembly of long datagrams, if necessary, for transmission through "small packet" networks. ICMP, which is a separate protocol implemented along with IPv4, enables the network to report errors and other issues to hosts that originate problematic datagrams.
IPv4 originally supported an experimental type of service field that identified eight levels of operational precedence styled after the requirements of military telephony, plus three and later four bit flags that IS-IS and OSPF interpreted as affecting traffic routing for datagrams requiring lower delay or higher throughput. These turned out to be less useful than the designers had hoped. They were replaced by the Differentiated Services Architecture (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.) [RFC2474][RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.), which contains a six bit code point used to select an algorithm (a "per-hop behavior") to be applied to the datagram.
| TOC |
IPv4 addresses are administratively assigned, usually using automated methods, and assigned using the Dynamic Host Configuration Protocol (DHCP) (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131]. On most interface types, neighboring equipment identify each other's addresses using Address Resolution Protocol (ARP) (Plummer, D., “Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware,” November 1982.) [RFC0826].
| TOC |
Routing for the IPv4 Internet is done by routing applications that exchange connectivity information and build semi-static destination routing databases. If a datagram is directed to a given destination address, the address is looked up in the routing database, and the most specific ("longest") prefix found that contains it is used to identify the next hop router, or the end system it will be delivered to. This is not generally implemented on hosts, although it can be; generally, a host sends datagrams to a router on its local network, and the router carries out the intent.
IETF specified routing protocols include RIP Version 2 (Malkin, G., “RIP Version 2,” November 1998.) [RFC2453], OSI IS-IS for IPv4 (Callon, R., “Use of OSI IS-IS for routing in TCP/IP and dual environments,” December 1990.) [RFC1195], OSPF Version 2 (Moy, J., “OSPF Version 2,” April 1998.) [RFC2328], and BGP-4 (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) [RFC4271]. Active research exists in mobile ad hoc routing and other routing paradigms; these result in new protocols and modified forwarding paradigms.
| TOC |
IPv4 was originally specified as a unicast (point to point) protocol, and was extended to support multicast in [RFC1112] (Deering, S., “Host extensions for IP multicasting,” August 1989.). This uses the Internet Group Management Protocol (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) [RFC3376][RFC4604] (Holbrook, H., Cain, B., and B. Haberman, “Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast,” August 2006.) to enable applications to join multicast groups, and for most applications uses Source-Specific Multicast (Holbrook, H. and B. Cain, “Source-Specific Multicast for IP,” August 2006.) [RFC4607] for routing and delivery of multicast messages.
An experiment carried out in IPv4 that is not core to the architecture but may be of interest in the Smart Grid is the development of so-called "Reliable Multicast". This is "so-called" because it is not "reliable" in the strict sense of the word - it is perhaps better described as "enhanced reliability". A best effort network by definition can lose traffic, duplicate it, or reorder it, something as true for multicast as for unicast. Research in "Reliable Multicast" technology intends to improve the probability of delivery of multicast traffic.
In that research, the IETF imposed guidelines (Mankin, A., Romanov, A., Bradner, S., and V. Paxson, “IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols,” June 1998.) [RFC2357] on the research community regarding what was desirable. Important results from that research include a number of papers and several proprietary protocols including some that have been used in support of business operations. RFCs in the area include The Use of Forward Error Correction (FEC) in Reliable Multicast (Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, “The Use of Forward Error Correction (FEC) in Reliable Multicast,” December 2002.) [RFC3453], the Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol (Adamson, B., Bormann, C., Handley, M., and J. Macker, “Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol,” November 2004.) [RFC3940], and the Selectively Reliable Multicast Protocol (SRMP) (Pullen, M., Zhao, F., and D. Cohen, “Selectively Reliable Multicast Protocol (SRMP),” February 2006.) [RFC4410]. These are considered experimental.
| TOC |
IPv6 (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [RFC2460], with the Internet Control Message Protocol "v6" (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.) [RFC4443], constitutes the next generation protocol for the Internet. IPv6 provides for transmission of datagrams from source to destination hosts, which are identified by fixed length addresses.
IPv6 also provides for fragmentation and reassembly of long datagrams by the originating host, if necessary, for transmission through "small packet" networks. ICMPv6, which is a separate protocol implemented along with IPv6, enables the network to report errors and other issues to hosts that originate problematic datagrams.
IPv6 adopted the Differentiated Services Architecture (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.) [RFC2474][RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.), which contains a six bit code point used to select an algorithm (a "per-hop behavior") to be applied to the datagram.
The IPv6 over Low-Power Wireless Personal Area Networks (Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” August 2007.) [RFC4919] RFC and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks (Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks,” April 2010.) [I‑D.ietf‑6lowpan‑hc] addresses IPv6 header compression and subnet architecture in at least some sensor networks, and may be appropriate to the Smart Grid AMI or other sensor domains.
| TOC |
An IPv6 Address (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.) [RFC4291] may be administratively assigned using DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315] in a manner similar to the way IPv4 addresses are, but may also be autoconfigured, facilitating network management. Autoconfiguration procedures are defined in [RFC4862] (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.) and [RFC4941] (Narten, T., Draves, R., and S. Krishnan, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” September 2007.). IPv6 neighbors identify each other's addresses using either Neighbor Discovery (ND) (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.) [RFC4861] or SEcure Neighbor Discovery (SEND) (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [RFC3971].
| TOC |
Routing for the IPv6 Internet is done by routing applications that exchange connectivity information and build semi-static destination routing databases. If a datagram is directed to a given destination address, the address is looked up in the routing database, and the most specific ("longest") prefix found that contains it is used to identify the next hop router, or the end system it will be delivered to. This is not generally implemented on hosts, although it can be; generally, a host sends datagrams to a router on its local network, and the router carries out the intent.
IETF specified routing protocols include RIP for IPv6 (Malkin, G. and R. Minnear, “RIPng for IPv6,” January 1997.) [RFC2080], IS-IS for IPv6 (Hopps, C., “Routing IPv6 with IS-IS,” October 2008.) [RFC5308], OSPF for IPv6 (Coltun, R., Ferguson, D., Moy, J., and A. Lindem, “OSPF for IPv6,” July 2008.) [RFC5340], and BGP-4 for IPv6 (Marques, P. and F. Dupont, “Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing,” March 1999.) [RFC2545]. Active research exists in mobile ad hoc routing, routing in low power networks (sensors and smart grids) and other routing paradigms; these result in new protocols and modified forwarding paradigms.
| TOC |
From its initial design, IPv6 has specified both unicast and multicast datagram exchange. This uses the Multicast Listener Discovery Protocol (MLDv2) (Deering, S., Fenner, W., and B. Haberman, “Multicast Listener Discovery (MLD) for IPv6,” October 1999.) [RFC2710] [RFC3590] (Haberman, B., “Source Address Selection for the Multicast Listener Discovery (MLD) Protocol,” September 2003.) [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) [RFC4604] (Holbrook, H., Cain, B., and B. Haberman, “Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast,” August 2006.) to enable applications to join multicast groups, and for most applications uses Source-Specific Multicast (Holbrook, H. and B. Cain, “Source-Specific Multicast for IP,” August 2006.) [RFC4607] for routing and delivery of multicast messages.
The mechanisms experimentally developed for reliable multicast in IPv4, discussed in Section 3.2.1.3 (IPv4 Multicast Forwarding and Routing), can be used in IPv6 as well.
| TOC |
In general, the layered architecture enables the Internet Protocol Suite to run over any appropriate layer 2 architecture; with tongue in cheek, specifications have been written and demonstrated to work for the carriage of IP by Carrier Pigeon (Waitzman, D., “Standard for the transmission of IP datagrams on avian carriers,” April 1990.) [RFC1149][RFC2549] (Waitzman, D., “IP over Avian Carriers with Quality of Service,” April 1999.) (perhaps the most common carrier known to man) and on barbed wire (Chapman, E., “Ethernet over Barbed Wire, Arcnet, 100MB Token Ring, 100Base-VGAnylan and iSCSI ...,” 2007.) [Chapman]. The ability to change the link or physical layer without having to rethink the network layer, transports, or applications has been a great benefit in the Internet.
Examples of link layer adaptation technology include:
- Ethernet/IEEE 802.3:
- IPv4 has run on each link layer environment that uses the Ethernet header (which is to say 10 and 100 MBPS wired Ethernet, 1 and 10 GBPS wired Ethernet, and the various versions of IEEE 802.11) using [RFC0894] (Hornig, C., “Standard for the transmission of IP datagrams over Ethernet networks,” April 1984.). IPv6 does the same using [RFC2464] (Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks,” December 1998.).
- PPP:
- The IETF has defined a serial line protocol, the Point-to-Point Protocol (PPP) (Simpson, W., “The Point-to-Point Protocol (PPP),” July 1994.) [RFC1661], that uses HDLC (bit-synchronous or byte synchronous) framing. The IPv4 adaptation specification is [RFC1332] (McGregor, G., “The PPP Internet Protocol Control Protocol (IPCP),” May 1992.), and the IPv6 adaptation specification is [RFC5072] (S.Varada, Haskins, D., and E. Allen, “IP Version 6 over PPP,” September 2007.). Current use of this protocol is in traditional serial lines, authentication exchanges in DSL networks using PPP Over Ethernet (PPPoE) (Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, “A Method for Transmitting PPP Over Ethernet (PPPoE),” February 1999.) [RFC2516], and in the Digital Signaling Hierarchy (generally referred to as Packet-on-SONET/SDH) using PPP over SONET/SDH (Malis, A. and W. Simpson, “PPP over SONET/SDH,” June 1999.) [RFC2615].
- IEEE 802.15.4:
- The adaptation specification for IPv6 transmission over IEEE 802.15.4 Networks is [RFC4944] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.).
Numerous other adaptation specifications exist, including ATM, Frame Relay, X.25, other standardized and proprietary LAN technologies, and others.
| TOC |
In this we list several transports: UDP, TCP, SCTP, and DCCP. Of these, UDP and TCP are best known and most widely used, due to history. SCTP and DCCP were built for specific purposes more recently and bear consideration at least for those purposes.
Note that if it is appropriate, other transports can also be built. This is largely a question of requirements.
| TOC |
The User Datagram Protocol (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768] and the Lightweight User Datagram Protocol (Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, “The Lightweight User Datagram Protocol (UDP-Lite),” July 2004.) [RFC3828] are properly not "transport" protocols in the sense of "a set of rules governing the exchange or transmission of data electronically between devices". They are labels that provide for multiplexing of applications directly on the IP layer, with transport functionality embedded in the application.
From a historical perspective, one should note that many simplistic exchange designs have been built using UDP, and many of them have not worked all that well. The use of UDP really should be treated as designing a new transport. More generally, advice on the use of UDP in new applications has been compiled in the Unicast UDP Usage Guidelines for Application Designers (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.) [RFC5405].
Datagram Transport Layer Security (Phelan, T., “Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP),” May 2008.) [RFC5238] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, UDP can run over IPsec.
| TOC |
TCP (Postel, J., “Transmission Control Protocol,” September 1981.) [RFC0793] is the predominant transport protocol in use in the Internet, with a long history. It is "reliable", as the term is used in protocol design: it delivers data to its peer and provides acknowledgement to the sender, or it dies trying. It has extensions for Congestion Control (Allman, M., Paxson, V., and W. Stevens, “TCP Congestion Control,” April 1999.) [RFC2581] and Explicit Congestion Notification (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.) [RFC3168].
The user interface for TCP is a byte stream interface - an application using TCP might "write" to it several times only to have the data compacted into a common segment and delivered as such to its peer. For message-stream interfaces, we generally use the ISO Transport Service on TCP (Rose, M. and D. Cass, “ISO transport services on top of the TCP: Version 3,” May 1987.) [RFC1006][RFC2126] (Pouffary, Y. and A. Young, “ISO Transport Service on top of TCP (ITOT),” March 1997.) in the application.
Transport Layer Security (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, TCP can run over IPsec. Additionally, [RFC4987] (Eddy, W., “TCP SYN Flooding Attacks and Common Mitigations,” August 2007.) discusses mechanisms similar to SCTP and DCCP's "cookie" approach that may be used to secure TCP sessions against flooding attacks.
TCP has supported ongoing research since it was written. As a result, the End to End research group has published a Roadmap for TCP Specification Documents (Duke, M., Braden, R., Eddy, W., and E. Blanton, “A Roadmap for Transmission Control Protocol (TCP) Specification Documents,” September 2006.) [RFC4614] which will guide expectations in that area.
| TOC |
SCTP (Stewart, R., “Stream Control Transmission Protocol,” September 2007.) [RFC4960] is a more recent reliable transport protocol that can be imagined as a TCP-like context containing multiple separate and independent message streams (as opposed to TCP's byte streams). The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. As it uses a message stream interface as opposed to TCP's byte stream interface, it may also be more appropriate for the ISO Transport Service than RFC 1006/2126.
SCTP offers several delivery options. The basic service is sequential non-duplicated delivery of messages within a stream, for each stream in use. Since streams are independent, one stream may pause due to head of line blocking while another stream in the same session continues to deliver data. In addition, SCTP provides a mechanism for bypassing the sequenced delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received.
SCTP implements a simple "cookie" mechanism intended to limit the effectiveness of flooding attacks by mutual authentication. This demonstrates that the application is connected to the same peer, but does not identify the peer. Mechanisms also exist for Dynamic Address Reconfiguration (Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, “Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration,” September 2007.) [RFC5061], enabling peers to change addresses during the session and yet retain connectivity. Transport Layer Security (Jungmaier, A., Rescorla, E., and M. Tuexen, “Transport Layer Security over Stream Control Transmission Protocol,” December 2002.) [RFC3436] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, SCTP can run over IPsec.
| TOC |
DCCP (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.) [RFC4340] is an "unreliable" transport protocol (e.g., one that does not guarantee message delivery) that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.
DCCP implements a simple "cookie" mechanism intended to limit the effectiveness of flooding attacks by mutual authentication. This demonstrates that the application is connected to the same peer, but does not identify the peer. Datagram Transport Layer Security (Phelan, T., “Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP),” May 2008.) [RFC5238] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, DCCP can run over IPsec.
| TOC |
| TOC |
To facilitate network management and operations, the Internet Community has defined the Domain Name System (DNS) (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) [RFC1034][RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.). Names are hierarchical: a name like example.com is found registered with a .com registrar, and within the associated network other names like baldur.cincinatti.example.com can be defined, with obvious hierarchy. Security extensions, which all a registry to sign the records it contains and as a result demonstrate their authenticity, are defined by the DNS Security Extensions [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.)[RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.)[RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.).
Similarly unrequired but useful is the ability for a device to update its own DNS record. One could imagine a sensor, for example, that is using Stateless Address Autoconfiguration (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.) [RFC4862] to create an address to associate it with a name using DNS Dynamic Update (Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE),” April 1997.) [RFC2136] or DNS Secure Dynamic Update (Wellington, B., “Secure Domain Name System (DNS) Dynamic Update,” November 2000.) [RFC3007].
| TOC |
As discussed in Section 3.2.1 (Internet Protocol Version 4) and Section 3.2.2 (Internet Protocol Version 6), IPv6 address assignment can be accomplished using autoconfiguration but can also be accomplished using DHCP (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131] or DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315]. The best argument for the use of autoconfiguration is a large number of systems that require little more than a random number as an address; the argument for DHCP is administrative control.
There are other parameters that may need to be allocated to hosts, and these do require administrative configuration; examples include the address of one's DNS server, keys if Secure DNS is in use, and others.
| TOC |
There are several applications that are widely used but are not properly thought of as infrastructure.
| TOC |
The Network Time Protocol was originally designed by Dave Mills of the University of Delaware and CSNET, for the purpose of implementing a temporal metric in the Fuzzball Routing Protocol and generally coordinating time experiments. The current versions of the time protocol are the Network Time Protocol (Mills, D., “Network Time Protocol (Version 3) Specification, Implementation,” March 1992.) [RFC1305], which is designed for synchronization to within a few microseconds, and the Simple Network Time Protocol (Mills, D., “Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI,” January 2006.) [RFC4330] which is used to set real time clocks to within a few milliseconds. The former is more precise, but relies on frequent exchanges; the latter is less precise and lower overhead.
NTP is currently being updated in [I‑D.ietf‑ntp‑ntpv4‑proto] (Kasch, W., Mills, D., and J. Burbank, “Network Time Protocol Version 4 Protocol And Algorithms Specification,” October 2009.).
| TOC |
The Session Initiation Protocol (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261][RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.)[RFC3853] (Peterson, J., “S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP),” July 2004.)[RFC4320] (Sparks, R., “Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction,” January 2006.)[RFC4916] (Elwell, J., “Connected Identity in the Session Initiation Protocol (SIP),” June 2007.)[RFC5393] (Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, “Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies,” December 2008.)[RFC5621] (Camarillo, G., “Message Body Handling in the Session Initiation Protocol (SIP),” September 2009.) is an application layer control (signaling) protocol for creating, modifying and terminating multimedia sessions on the Internet, meant to be more scalable than H.323. Multimedia sessions can be voice, video, instant messaging, shared data, and/or subscriptions of events. SIP can run on top of TCP, UDP, SCTP, or TLS over TCP. SIP is independent of the transport layer, and independent of the underlying IPv4/v6 version. In fact, the transport protocol used can change as the SIP message traverses SIP entities from source to destination.
SIP itself does not choose whether a session is voice or video, the SDP: Session Description Protocol (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] is intended for that purpose and to identify the actual endpoints' IP addresses. Within the SDP, which is transported by SIP, codecs are offered and accepted (or not), the port number and IP address is decided for where each endpoint wants to receive their RTP (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [RFC3550] packets. This part is critical to understand because of the affect on NATs. Unless a NAT (with or without a Firewall) is designed to be SDP aware (i.e., looking into each packet far enough to discover what the IP address and port number is for this particular session - and resetting it based on the Session Traversal Utilities for NAT (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.) [RFC5389], the session established by SIP will not result in RTP packets being sent to the proper endpoint (in SIP called a user agent, or UA). It should be noted that SIP messaging has no issues with NATs, it is just the UA's inability to generally learn about the presence of the NATs that prevent the RTP packets from being received by the UA establishing the session.
| TOC |
Internet calendaring, as implemented in Apple iCal, Microsoft Outlook and Entourage, and Google Calendar, is specified in Internet Calendaring and Scheduling Core Object Specification (iCalendar) (Desruisseaux, B., “Internet Calendaring and Scheduling Core Object Specification (iCalendar),” September 2009.) [RFC5545] and is in the process of being updated to an XML schema in iCalendar XML Representation (Daboo, C., Douglass, M., and S. Lees, “xCal: The XML format for iCalendar,” May 2010.) [I‑D.daboo‑et‑al‑icalendar‑in‑xml] Several protocols exist to carry calendar events, including Transport-Independent Interoperability Protocol (iTIP) (Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, “iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries,” November 1998.) [RFC2446], (which has recently been updated in [I‑D.ietf‑calsify‑2446bis] (Daboo, C., “iCalendar Transport-Independent Interoperability Protocol (iTIP),” October 2009.)) , the Message-Based Interoperability Protocol (iMIP) (Dawson, F., Mansour, S., and S. Silverberg, “iCalendar Message-Based Interoperability Protocol (iMIP),” November 1998.) [RFC2447] , and open source work on the Atom Publishing Protocol (Gregorio, J. and B. de hOra, “The Atom Publishing Protocol,” October 2007.) [RFC5023].
| TOC |
The Internet was originally structured in such a way that any host could directly connect to any other host for which it could determine an IP address. That was very quickly found to have issues, and folks found ways to change that. To understand the implications, one must understand, at a high level, the business structure of the Internet.
The Internet, whose name implies that it is a network of networks, may be understood as a number of interconnected and independently operated networks. Understanding "business" in an extended sense (a legal entity, capable of entering into a contract, which includes wide variety of entities including those narrowly termed "businesses"), this can be thought of as a "business structure" for the Internet. Central to its business structure are the networks that provide connectivity to other networks, called "Transit Providers". These networks sell bulk bandwidth and routing services to each other and to other networks as customers. Around the periphery of these networks, one finds companies, schools, and other networks that provide services directly to individuals. These might generally be divided into "Enterprise Networks" and "Access Networks"; Enterprise networks provide "free" connectivity to their own employees or members, and also provide them a set of services including electronic mail, web services, and so on. Access Networks sell broadband connectivity (DSL, Cable Modem, 802.11 wireless or 3GPP wireless), or "dial" services including PSTN dial-up and ISDN, to subscribers. The subscribers are typically either residential or small office/home office (SOHO) customers. Residential customers are generally entirely dependent on their access provider for all services, while a SOHO buys some services from the access provider and may provide others for itself. Networks that sell transit services to nobody else - SOHO, residential, and enterprise networks - are generally refereed to as "edge networks"; Transit Networks are considered to be part of the "core" of the Internet, and access networks are between the two. This general structure is depicted in Figure 3 (Conceptual model of Internet businesses).
------ ------
/ \ / \
/--\ / \ / \
|SOHO|---+ Access | |Enterprise|
\--/ | Service | | Network |
/--\ | Provider| | |
|Home|---+ | ------ | |
\--/ \ +---+ +---+ /
\ / / \ \ /
------ | Transit | ------
| Service |
| Provider |
| |
\ /
\ /
------
| Figure 3: Conceptual model of Internet businesses |
A specific example is shown in a traceroute from the author's home to a school he can see nearby. Internet connectivity in Figure 4 (Traceroute from residential customer to educational institution) passes through
<stealth-10-32-244-218:> fred% traceroute www.ucsb.edu
traceroute to web.ucsb.edu (128.111.24.41),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms
2 wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms ...
3 68.6.13.101 ...
4 68.6.13.129 ...
5 langbbr01-as0.r2.la.cox.net ...
6 calren46-cust.lsanca01.transitrail.net ...
7 dc-lax-core1--lax-peer1-ge.cenic.net ...
8 dc-lax-agg1--lax-core1-ge.cenic.net ...
9 dc-ucsb--dc-lax-dc2.cenic.net ...
10 r2--r1--1.commserv.ucsb.edu ...
11 574-c--r2--2.commserv.ucsb.edu ...
12 * * *
| Figure 4: Traceroute from residential customer to educational institution |
Another specific example could be shown in a traceroute from the author's home to his employer. Internet connectivity in that case uses a Virtual Private Network (VPN tunnel) from the author's home, crossing Cox Cable (an Access Network) and Pacific Bell (a Transit Network), and terminating in Cisco Systems (an Enterprise Network); a traceroute of the path doesn't show that as it is invisible within the VPN and the contents of the VPN are invisible, due to encryption, to the networks on the path. Instead, the traceroute in Figure 5 (Traceroute across VPN) is entirely within Cisco's internal network.
<stealth-10-32-244-218:~> fred% traceroute irp-view13
traceroute to irp-view13.cisco.com (171.70.120.60),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms
<tunneled path through Cox and Pacific Bell>
2 ****
3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms...
4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ...
5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ...
6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ...
7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ...
8 sjc12-dc5-gw2-ten3-1 ...
9 sjc5-dc4-gw1-ten8-1 ...
10 irp-view13 ...
| Figure 5: Traceroute across VPN |
In both cases, it will be observed that the author's home internally uses address space from the Address Allocation for Private Internets (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) [RFC1918], and other networks generally use public address space. It will also be observed that on entry to UCSB, the traceroute in Figure 4 (Traceroute from residential customer to educational institution) terminates before arriving at the target.
Three middleware technologies are in obvious use here. These are the use of a firewall, a Network Address Translator (NAT), and a Virtual Private Network (VPN).
Firewalls are generally sold as, and considered, a security technology. A firewall imposes a border between two administrative domains, which are usually a residential, SOHO, or enterprise network and its access or transit provider. In its essence, a firewall is a data diode, imposing a policy on what sessions may pass between a protected domain and the rest of the Internet. Simple policies generally permit sessions to be originated from the protected network but not from the outside; more complex policies may permit additional sessions from the outside, as electronic mail to a mail server or a web session to a web server, and may prevent certain applications from global access even though they are originated from the inside. Firewalls are controversial in the Internet community; network managers often insist on them simply because they impose a boundary; others point out that their value as a security solution is debatable, as most attacks come from behind the firewall and application layer attacks such as viruses carried in email or Active X are invisible to them. In general, as a security solution, they are justified as a defense in depth; while the end system must in the end be responsible for its own security, a firewall can inhibit or prevent certain kinds of attacks from certain quarters such as the consumption of CPU time on a critical server. Key documents describing firewall technology and the issues it poses include:
Network Address Translation is a technology that was developed in response to ISP behaviors in the mid-1990's; when [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) was published, many ISPs started handing out single or small numbers of addresses, and edge networks were forced to translate. In time, this became considered a good thing, or at least not a bad thing; it amplified the public address space, and it was sold as if it were a firewall. It of course is not; while traditional dynamic NATs only translate between internal and external session address/aport tuples during the detected duration of the session, that session state may exist in the network much longer than it exists on the end system, and as a result constitutes an attack vector. The design, value, and limitations of network address translation are described in:
Virtual Private Networks come in many forms; what they have in common is that they are generally tunneled over the internet backbone, so that as in Figure 5 (Traceroute across VPN), connectivity appears to be entirely within the edge network although it is in fact across a service provider's network. Examples include IPsec tunnel-mode encrypted tunnels, IP-in-IP or Generic Routing Encapsulation (GRE) (Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.) [RFC2784] tunnels, and MPLS LSPs (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” January 2001.) [RFC3031][RFC3032] (Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding,” January 2001.). .
| TOC |
This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the author"s perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion.
| TOC |
Security is addressed in some detail in Section 2.2 (Security issues) and Section 3.1 (Security solutions).
| TOC |
Review comments were made by Andrew Yourtchenko, Ashok Narayanan, Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Hemant Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, Ralph Droms, Russ White, Sheila Frankel, and Toerless Eckert. Dave McGrew, Vint Cerf, and Ralph Droms suggested text.
| TOC |
| TOC |
| [RFC1122] | Braden, R., “Requirements for Internet Hosts - Communication Layers,” STD 3, RFC 1122, October 1989 (TXT). |
| [RFC1123] | Braden, R., “Requirements for Internet Hosts - Application and Support,” STD 3, RFC 1123, October 1989 (TXT). |
| [RFC1812] | Baker, F., “Requirements for IP Version 4 Routers,” RFC 1812, June 1995 (TXT). |
| [RFC4294] | Loughney, J., “IPv6 Node Requirements,” RFC 4294, April 2006 (TXT). |
| TOC |
| TOC |
| Fred Baker | |
| Cisco Systems | |
| Santa Barbara, California 93117 | |
| USA | |
| Email: | fred@cisco.com |