Network Working Group F. Baker
Internet-Draft Cisco Systems
Intended status: Informational September 15, 2009
Expires: March 19, 2010
Core Protocols in the Internet Protocol Suite
draft-baker-ietf-core-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 19, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This note attempts to identify the core of the Internet Protocol
Suite. The target audience is NIST, in the Smart Grid discussion, as
they have requested guidance on how to profile the Internet Protocol
Baker Expires March 19, 2010 [Page 1]
Internet-Draft Core Protocols September 2009
Suite. In general, that would mean selecting what they need from the
picture presented here.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 5
2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 5
2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3.1. Internet Layer . . . . . . . . . . . . . . . . . . 6
2.1.3.2. Lower layer networks . . . . . . . . . . . . . . . 7
2.1.4. Physical and Link layers . . . . . . . . . . . . . . . 7
2.2. Security issues . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Physical security . . . . . . . . . . . . . . . . . . 7
2.2.2. Session identification, authentication,
authorization, and accounting . . . . . . . . . . . . 8
2.2.3. Confidentiality . . . . . . . . . . . . . . . . . . . 9
2.3. Critical Network Infrastructure . . . . . . . . . . . . . 9
2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 9
2.3.2. Network Management Issues . . . . . . . . . . . . . . 10
3. Specific protocols . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Security solutions . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Session identification, authentication,
authorization, and accounting . . . . . . . . . . . . 10
3.1.2. IP Security Architecture (IPsec) . . . . . . . . . . . 11
3.1.3. Transport Layer Security (TLS) . . . . . . . . . . . . 11
3.1.4. Secure/Multipurpose Internet Mail Extensions
(S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Internet Protocol Version 4 . . . . . . . . . . . . . 12
3.2.2. Internet Protocol Version 6 . . . . . . . . . . . . . 12
3.2.3. Adaptation to lower layer networks and link layer
protocols . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 14
3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 14
3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 15
3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 15
3.4. Critical Infrastructure . . . . . . . . . . . . . . . . . 15
3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 15
3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 16
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Baker Expires March 19, 2010 [Page 2]
Internet-Draft Core Protocols September 2009
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Baker Expires March 19, 2010 [Page 3]
Internet-Draft Core Protocols September 2009
1. Introduction
In the discussion of the Smart Grid, a question has arisen as to what
the "core" protocols of 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
UDP as a label and build 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.
IETF participants in the Smart Grid discussion have been wary of the
desire to write a "profile", repeatedly expressed. The IETF is all
about interoperability, and in our experience attempts to "profile"
protocols and architectures has resulted in a failure to
interoperate. Examples of such failures abound. In IETF experience,
writing a conforming and interoperable implementation of the right
set of protocols works. Selecting some options and deselecting
others within a defined protocol, however, is a dangerous course of
action. So while this document is clearly a step in the direction of
writing a "Smart Grid Profile", such a profile should in our opinion
be a selected set of protocols, not of protocol subsets.
For its own purposes, the IETF has written several documents that
describe its expectations regarding implementations of the Internet
Protocol Suite. These include:
o Requirements for Internet Hosts - Communication Layers [RFC1122],
o Requirements for Internet Hosts - Application and Support
[RFC1123],
o Requirements for IP Version 4 Routers [RFC1812], and
o IPv6 Node Requirements [RFC4294],
At this writing, RFC 4294 is in the process of being updated, in
Baker Expires March 19, 2010 [Page 4]
Internet-Draft Core Protocols September 2009
[I-D.ietf-6man-node-req-bis].
This document will read like an annotated list of RFCs. That is
because that is what it is.
2. The Internet Protocol Suite
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.
2.1. Internet Protocol Layers
The Internet Architecture uses the definitions and language of the
ISO Open System Interconnect Reference Model, as shown in Figure 1.
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
2.1.1. Application
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
Baker Expires March 19, 2010 [Page 5]
Internet-Draft Core Protocols September 2009
element. In the Internet, therefore, the distinction between these
layers exists but is not generally highlighted.
2.1.2. Transport
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.
2.1.3. Network
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.
2.1.3.1. Internet Layer
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.
Baker Expires March 19, 2010 [Page 6]
Internet-Draft Core Protocols September 2009
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.
2.1.3.2. Lower layer networks
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).
2.1.4. Physical and Link layers
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.
2.2. Security issues
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.
2.2.1. Physical security
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.
Baker Expires March 19, 2010 [Page 7]
Internet-Draft Core Protocols September 2009
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.
2.2.2. Session identification, authentication, authorization, and
accounting
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
1. Verify that the peers one exchanges data with are appropriate
partners; this generally means knowing "who" they are and that
they have a "need to know" or are trusted sources.
2. Verify that information that appears to be from a trusted peer is
in fact from that peer.
3. Validate the content of the data exchanged; it must conform to
the rules of the exchange.
4. One must also defend the channel against denial of service
attacks.
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
o demand identification from the new peer,
o verify that the peer is in fact who it claims to be, and
o verify that it is authorized to carry on the exchange.
Baker Expires March 19, 2010 [Page 8]
Internet-Draft Core Protocols September 2009
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.
2.2.3. Confidentiality
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.
2.3. Critical Network Infrastructure
While these are not critical to the design of a specific system, they
are important to running a network. We therefore bring them up.
2.3.1. Domain Name System (DNS)
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, which can be used to
provide strong cryptographic authentication to that protocol.
Baker Expires March 19, 2010 [Page 9]
Internet-Draft Core Protocols September 2009
2.3.2. Network Management Issues
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. 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 [SP-MULPIv3.0].
3. Specific protocols
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.
3.1. Security solutions
As noted, a key consideration in security solutions is a good threat
analysis coupled with appropriate mitigations at each layer.
3.1.1. Session identification, authentication, authorization, and
accounting
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.
Baker Expires March 19, 2010 [Page 10]
Internet-Draft Core Protocols September 2009
3.1.2. IP Security Architecture (IPsec)
The Security Architecture for the Internet Protocol [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
Encapsulating Security Payload (ESP) [RFC4303], the Internet Security
Association and Key Management Protocol (ISAKMP) [RFC4304], Internet
Key Exchange (IKEv2) [RFC4306], Cryptographic Algorithms [RFC4307],
and the use of Advanced Encryption Standard (AES) [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.
3.1.3. Transport Layer Security (TLS)
Transport Layer Security [RFC5246] and Datagram Transport Layer
Security [RFC4347][I-D.ietf-tls-rfc4347-bis] 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.
3.1.4. Secure/Multipurpose Internet Mail Extensions (S/MIME)
The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049]
[RFC3850] [RFC3853] [RFC4262] 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].
Baker Expires March 19, 2010 [Page 11]
Internet-Draft Core Protocols September 2009
3.2. Network Layer
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.
3.2.1. Internet Protocol Version 4
IPv4 [RFC0791], with the Internet Control Message Protocol [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.
Those addresses are administratively assigned, usually using
automated methods such as the Dynamic Host Configuration Protocol
(DHCP) [RFC2131]. On most interface types, neighboring equipment
identify each other's addresses using Address Resolution Protocol
(ARP) [RFC0826].
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 was originally specified as a unicast (point to point) protocol,
and was extended to support multicast in [RFC1112]. This uses the
Internet Group Management Protocol [RFC3376][RFC4604] to enable
applications to join multicast groups, and for most applications uses
Source-Specific Multicast [RFC4607] for routing and delivery of
multicast messages.
3.2.2. Internet Protocol Version 6
IPv6 [RFC2460], with the Internet Control Message Protocol "v6"
[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.
Baker Expires March 19, 2010 [Page 12]
Internet-Draft Core Protocols September 2009
An IPv6 Address [RFC4291] may be administratively assigned using
DHCPv6 [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] and [RFC4941].
IPv6 neighbors identify each other's addresses using either Neighbor
Discovery (ND) [RFC4861] or SEcure Neighbor Discovery (SEND)
[RFC3971].
IPv6 specifies both unicast and multicast datagram exchange. This
uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710]
[RFC3590] [RFC3810] [RFC4604] to enable applications to join
multicast groups, and for most applications uses Source-Specific
Multicast [RFC4607] for routing and delivery of multicast messages.
The IPv6 over Low-Power Wireless Personal Area Networks [RFC4919] RFC
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.
3.2.3. Adaptation to lower layer networks and link layer protocols
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 [RFC1149][RFC2549] (perhaps
the most common carrier known to man) and on barbed wire [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]. IPv6 does the same
using [RFC2464].
PPP: The IETF has defined a serial line protocol, the Point-to-Point
Protocol (PPP) [RFC1661], that uses HDLC (bit-synchronous or byte
synchronous) framing. The IPv4 adaptation specification is
[RFC1332], and the IPv6 adaptation specification is [RFC5072].
Current use of this protocol is in traditional serial lines,
authentication exchanges in DSL networks using PPP Over Ethernet
(PPPoE) [RFC2516], and in the Digital Signaling Hierarchy
(generally referred to as Packet-on-SONET/SDH) using PPP over
SONET/SDH [RFC2615].
Baker Expires March 19, 2010 [Page 13]
Internet-Draft Core Protocols September 2009
IEEE 802.15.4: The adaptation specification for IPv6 transmission
over IEEE 802.15.4 Networks is [RFC4944].
Numerous other adaptation specifications exist, including ATM, Frame
Relay, X.25, other standardized and proprietary LAN technologies, and
others.
3.3. Transport Layer
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.
3.3.1. User Datagram Protocol (UDP)
The User Datagram Protocol [RFC0768] and the Lightweight User
Datagram Protocol [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.
Datagram Transport Layer Security [RFC5238] can be used to prevent
eavesdropping, tampering, or message forgery. Alternatively, UDP can
run over IPsec.
3.3.2. Transmission Control Protocol (TCP)
TCP [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 [RFC2581] and Explicit Congestion Notification
[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 add [RFC1006] in
Baker Expires March 19, 2010 [Page 14]
Internet-Draft Core Protocols September 2009
the application.
Transport Layer Security [RFC5246] can be used to prevent
eavesdropping, tampering, or message forgery. Alternatively, TCP can
run over IPsec.
3.3.3. Stream Control Transmission Protocol (SCTP)
SCTP [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.
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.
Transport Layer Security [RFC3436] can be used to prevent
eavesdropping, tampering, or message forgery. Alternatively, SCTP
can run over IPsec.
3.3.4. Datagram Congestion Control Protocol (DCCP)
DCCP [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.
Datagram Transport Layer Security [RFC5238] can be used to prevent
eavesdropping, tampering, or message forgery. Alternatively, DCCP
can run over IPsec.
3.4. Critical Infrastructure
3.4.1. Domain Name System
To facilitate network management and operations, the Internet
Community has defined the Domain Name System (DNS)
[RFC1034][RFC1035]. Names are hierarchical: a name like example.com
is found registered with a .com registrar, and within the associated
Baker Expires March 19, 2010 [Page 15]
Internet-Draft Core Protocols September 2009
network other names like baldur.cincinatti.example.com can be
defined, with obvious hierarchy.
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 [RFC4862] to create an
address to associate it with a name using DNS Dynamic Update
[RFC2136] or DNS Secure Dynamic Update [RFC3007].
3.4.2. Dynamic Host Configuration
As discussed in Section 3.2.1 and Section 3.2.2, IPv6 address
assignment can be accomplished using autoconfiguration but can also
be accomplished using DHCP [RFC2131] or DHCPv6 [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.
4. IANA Considerations
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.
5. Security Considerations
Security is addressed in some detail in Section 2.2 and Section 3.1.
6. Acknowledgements
Review comments were made by Andrew Yourtchenko, Ashok Narayanan,
Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, Hemant Singh,
John Meylor, Joseph Salowey, Julien Abeille, Kerry Lynn, Murtaza
Chiba, Paul Duffy, Ralph Droms, Russ White, and Toerless Eckert.
Dave McGrew and Ralph Droms suggested text.
Baker Expires March 19, 2010 [Page 16]
Internet-Draft Core Protocols September 2009
7. References
7.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
7.2. Informative References
[Chapman] Chapman, E., "Ethernet over Barbed Wire, Arcnet, 100MB
Token Ring, 100Base-VGAnylan and iSCSI ...", 2007.
[I-D.ietf-6man-node-req-bis]
Loughney, J. and T. Narten, "IPv6 Node Requirements RFC
4294-bis", draft-ietf-6man-node-req-bis-03 (work in
progress), July 2009.
[I-D.ietf-tls-rfc4347-bis]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis-02 (work
in progress), March 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0826] Plummer, D., "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.
Baker Expires March 19, 2010 [Page 17]
Internet-Draft Core Protocols September 2009
[RFC0894] Hornig, C., "Standard for the transmission of IP datagrams
over Ethernet networks", STD 41, RFC 894, April 1984.
[RFC1006] Rose, M. and D. Cass, "ISO transport services on top of
the TCP: Version 3", STD 35, RFC 1006, May 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1149] Waitzman, D., "Standard for the transmission of IP
datagrams on avian carriers", RFC 1149, April 1990.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Baker Expires March 19, 2010 [Page 18]
Internet-Draft Core Protocols September 2009
(IPv6) Specification", RFC 2460, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of
Service", RFC 2549, April 1999.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590,
September 2003.
Baker Expires March 19, 2010 [Page 19]
Internet-Draft Core Protocols September 2009
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, July 2004.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/
Multipurpose Internet Mail Extensions (S/MIME)
Capabilities", RFC 4262, December 2005.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, December 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to
IPsec Domain of Interpretation (DOI) for Internet Security
Association and Key Management Protocol (ISAKMP)",
RFC 4304, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Baker Expires March 19, 2010 [Page 20]
Internet-Draft Core Protocols September 2009
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[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", RFC 4604, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
Baker Expires March 19, 2010 [Page 21]
Internet-Draft Core Protocols September 2009
the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SP-MULPIv3.0]
CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols
Interface Specification, CM-SP-MULPIv3.0-I10-090529",
May 2009.
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Baker Expires March 19, 2010 [Page 22]
