idnits 2.17.1 draft-baker-ietf-core-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 11 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2009) is 5296 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4294 (Obsoleted by RFC 6434) == Outdated reference: A later version (-11) exists of draft-daboo-et-al-icalendar-in-xml-00 == Outdated reference: A later version (-11) exists of draft-ietf-6man-node-req-bis-03 == Outdated reference: A later version (-10) exists of draft-ietf-calsify-2446bis-09 == Outdated reference: A later version (-13) exists of draft-ietf-ntp-ntpv4-proto-11 == Outdated reference: A later version (-06) exists of draft-ietf-tls-rfc4347-bis-03 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2446 (Obsoleted by RFC 5546) -- Obsolete informational reference (is this intentional?): RFC 2447 (Obsoleted by RFC 6047) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3511 (Obsoleted by RFC 9411) -- Obsolete informational reference (is this intentional?): RFC 3850 (Obsoleted by RFC 5750) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3940 (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational October 23, 2009 5 Expires: April 26, 2010 7 Core Protocols in the Internet Protocol Suite 8 draft-baker-ietf-core-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 26, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This note attempts to identify the core of the Internet Protocol 47 Suite. The target audience is NIST, in the Smart Grid discussion, as 48 they have requested guidance on how to profile the Internet Protocol 49 Suite. In general, that would mean selecting what they need from the 50 picture presented here. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 5 56 2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 5 57 2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 6 58 2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 7 59 2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 7 61 2.1.3.2. Lower layer networks . . . . . . . . . . . . . . . 8 62 2.1.4. Media layers: Physical and Link . . . . . . . . . . . 8 63 2.2. Security issues . . . . . . . . . . . . . . . . . . . . . 8 64 2.2.1. Physical security . . . . . . . . . . . . . . . . . . 8 65 2.2.2. Session identification . . . . . . . . . . . . . . . . 9 66 2.2.3. Confidentiality . . . . . . . . . . . . . . . . . . . 10 67 2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 10 68 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 10 69 2.3.2. Network Management Issues . . . . . . . . . . . . . . 10 70 3. Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11 71 3.1. Security solutions . . . . . . . . . . . . . . . . . . . . 11 72 3.1.1. Session identification, authentication, 73 authorization, and accounting . . . . . . . . . . . . 11 74 3.1.2. IP Security Architecture (IPsec) . . . . . . . . . . . 11 75 3.1.3. Transport Layer Security (TLS) . . . . . . . . . . . . 12 76 3.1.4. Secure/Multipurpose Internet Mail Extensions 77 (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 12 79 3.2.1. Internet Protocol Version 4 . . . . . . . . . . . . . 13 80 3.2.1.1. IPv4 Address Allocation and Assignment . . . . . . 13 81 3.2.1.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 13 82 3.2.1.3. IPv4 Multicast Forwarding and Routing . . . . . . 14 83 3.2.2. Internet Protocol Version 6 . . . . . . . . . . . . . 14 84 3.2.2.1. IPv6 Address Allocation and Assignment . . . . . . 15 85 3.2.2.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 15 86 3.2.2.3. IPv6 Multicast Forwarding and Routing . . . . . . 15 87 3.2.3. Adaptation to lower layer networks and link layer 88 protocols . . . . . . . . . . . . . . . . . . . . . . 16 89 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 16 90 3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 17 91 3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 17 92 3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 18 93 3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 18 94 3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 19 95 3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 19 96 3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 19 97 3.5. Other Applications . . . . . . . . . . . . . . . . . . . . 19 98 3.5.1. Network Time . . . . . . . . . . . . . . . . . . . . . 19 99 3.5.2. Session Initiation Protocol . . . . . . . . . . . . . 20 100 3.5.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 20 101 4. A simplied view of the business architecture . . . . . . . . . 21 102 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 104 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 106 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 107 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 110 1. Introduction 112 In the discussion of the Smart Grid, a question has arisen as to what 113 the "core" protocols of the Internet Protocol Suite are. In this 114 note, I will attempt to identify the structure of the Internet 115 Protocol Suite and the key protocols that should be considered as 116 critical in integrating Smart Grid devices into an IP-based 117 infrastructure. In many cases, the protocols are options - one might 118 choose, for example, TCP, SCTP, DCCP, or some other transport, or use 119 UDP as a label and build the transport into the application itself. 120 In the Transport layer, therefore, one is not limited to exactly one 121 of those, nor is one required to implement them all. One should, 122 however, pick the right one for the purpose one intends. This kind 123 of discussion will be had at every layer. 125 The set of protocols defined in this document focus on the use of the 126 IP Protocol Suite in end systems, also known as hosts. In the Smart 127 Grid, these end systems will be various devices such as power meters, 128 sensors and actuators. These end systems can leverage infrastructure 129 built on networking components using the IP Protocol Suite, which 130 have well-proven implementations and deployments in the Internet. 132 IETF participants in the Smart Grid discussion have been wary of the 133 desire to write a "profile", repeatedly expressed. The IETF is all 134 about interoperability, and in our experience attempts to "profile" 135 protocols and architectures has resulted in a failure to 136 interoperate. Examples of such failures abound. In IETF experience, 137 writing a conforming and interoperable implementation of the right 138 set of protocols works. Selecting some options and deselecting 139 others within a defined protocol, however, is a dangerous course of 140 action. So while this document is clearly a step in the direction of 141 writing a "Smart Grid Profile", such a profile should in our opinion 142 be a selected set of protocols, not of protocol subsets. 144 For its own purposes, the IETF has written several documents that 145 describe its expectations regarding implementations of the Internet 146 Protocol Suite. These include: 148 o Requirements for Internet Hosts - Communication Layers [RFC1122], 150 o Requirements for Internet Hosts - Application and Support 151 [RFC1123], 153 o Requirements for IP Version 4 Routers [RFC1812], and 155 o IPv6 Node Requirements [RFC4294], 157 At this writing, RFC 4294 is in the process of being updated, in 159 [I-D.ietf-6man-node-req-bis]. 161 This document will read like an annotated list of RFCs. That is 162 because that is what it is. 164 2. The Internet Protocol Suite 166 Before listing a list of protocols, it would be well to lay out how 167 they relate to each other. In this section, we will discuss the 168 layered architecture of the Internet Protocol Suite and the jobs of 169 the various layers and their protocols. 171 2.1. Internet Protocol Layers 173 The Internet Architecture uses the definitions and language of the 174 ISO Open System Interconnect Reference Model, as shown in Figure 1. 175 It actually predates that model, and as a result uses some different 176 words - an "end system" is generally called a "host", and an 177 "intermediate system" is more generally called an "internet gateway" 178 or "router". But the fundamental concepts are essentially the same. 180 +--------------------+ 181 | Application Layer | 182 +--------------------+ 183 | Presentation Layer | 184 +--------------------+ 185 | Session Layer | 186 +--------------------+ 187 | Transport layer | 188 +--------------------+ 189 | Network Layer | 190 +--------------------+ 191 | Data Link Layer | 192 +--------------------+ 193 | Physical Layer | 194 +--------------------+ 196 Figure 1: The ISO OSI Reference Model 198 The structure of the Internet reference Model looks something like 199 Figure 2. 201 +---------------------------------+ 202 |Application | 203 | +---------------------------+ | 204 | | Application Protocol | | 205 | +----------+----------------+ | 206 | | Encoding | Session Control| | 207 | +----------+----------------+ | 208 +---------------------------------+ 209 |Transport | 210 | +---------------------------+ | 211 | | Transport layer | | 212 | +---------------------------+ | 213 +---------------------------------+ 214 |Network | 215 | +---------------------------+ | 216 | | Internet Protocol | | 217 | +---------------------------+ | 218 | | Lower network layers | | 219 | +---------------------------+ | 220 +---------------------------------+ 221 |Media layers | 222 | +---------------------------+ | 223 | | Data Link Layer | | 224 | +---------------------------+ | 225 | | Physical Layer | | 226 | +---------------------------+ | 227 +---------------------------------+ 229 Figure 2: The Internet Reference Model 231 2.1.1. Application 233 In implementation, the Application, Presentation, and Session layers 234 are generally compressed into a single entity, which the IETF calls 235 "the application". The SNMP protocol, for example, describes an 236 application (a management application or a client that it 237 communicates with) that encodes its data in a profile of ASN.1 (a 238 presentation layer) and engages in a session to manage a network 239 element. In the Internet, therefore, the distinction between these 240 layers exists but is not generally highlighted. Note, in Figure 2, 241 that these are not necessarily cleanly layered: the fact that an 242 application protocol encodes its data in some way and that it manages 243 sessions in some way doesn't imply a hierarchy between those 244 processes. Rather, the application views encoding, session 245 management, and a variety of other services as a tool set that it 246 uses while doing its work. 248 2.1.2. Transport 250 The term "transport" is perhaps among the most confusing words in the 251 communication architecture, because people with various backgrounds 252 use it to refer to "the layer below that which I am interested in, 253 which gets my data to my peer". In these contexts, optical fiber and 254 other physical layers, the Internet Protocol or other networked 255 protocols, and in some cases application layer protocols like HTTP 256 are referred to as "the transport". 258 In the Internet context, the "transport" is the lowest layer that 259 travels end-to-end unmodified, and is responsible for end-to-end data 260 delivery services. At minimum these include the ability to multiplex 261 several applications on one IP address, and may also include the 262 delivery of data (either as a stream of messages or a stream of 263 bytes) in a stated sequence with stated expectations regarding 264 delivery rate and loss. TCP, for example, will reduce rate to avoid 265 loss, while DCCP accepts some level of loss if necessary to maintain 266 timeliness. 268 2.1.3. Network 270 The network layer is nominally that which identifies a remote 271 destination and gets data to it. In connection-oriented networking, 272 such as MPLS or ATM, a path (one of many "little tubes") is set up 273 once, and data is delivered through it. In connectionless 274 ("datagram") networks, which include Ethernet and IP among others, 275 each datagram contains the addresses of both the source and 276 destination devices, and the network is responsible to deliver it. 278 2.1.3.1. Internet Protocol 280 IPv4 and IPv6, each of which is called the Internet Protocol, are 281 connectionless ("datagram") architectures. They are designed as 282 common elements that interconnect network elements across a network 283 of lower layer networks. In addition to the basic service of 284 identifying a datagram's source and destination, they offer services 285 to fragment and reassemble datagrams when necessary, assist in 286 diagnosis of network failures, and carry additional information 287 necessary in special cases. 289 The Internet Layer provides a uniform network abstraction or virtual 290 network that hides the differences between different network 291 technologies. This is the layer that allows diverse networks such as 292 Ethernet, 802.15.4, etc. to be combined into a uniform IP network. 293 New network technologies can be introduced into the IP Protocol Suite 294 by defining how IP is carried over those technologies, leaving the 295 other layers of the IP Protocol Suite and applications that use those 296 protocol unchanged. 298 2.1.3.2. Lower layer networks 300 The network layer is recursively subdivided as needed. For various 301 reasons, IP may be carried in virtual private networks across more 302 public networks using tunneling technologies like IP-in-IP or GRE, 303 traffic engineered in circuit networks such as MPLS, GMPLS, or ATM, 304 and distributed across local wireless (IEEE 802.11, 802.15.4, or 305 802.16) and switched Ethernet (IEEE 802.3). 307 2.1.4. Media layers: Physical and Link 309 At the lowest layer of the architecture, we encode digital data in 310 messages onto appropriate physical media. While the IETF specifies 311 algorithms for carrying IPv4 and IPv6 on such media, it rarely 312 actually defines the media - it happily uses specifications from 313 IEEE, ITU, and other sources. 315 2.2. Security issues 317 It is popular to complain about the security of the Internet; that 318 said, solutions exist but are often left unused. As with automobile 319 seat belts, they are of more value when actively used. Security 320 designs attempt to mitigate a set of known threats at a specified 321 cost; addressing security issues requires first a threat analysis and 322 assessment and a set of mitigations appropriate to the threats. 323 Since we have threats at every layer, we should expect to find 324 mitigations at every layer. 326 2.2.1. Physical security 328 At the physical and data link layers, threats involve physical 329 attacks on the network - the effects of backhoes, deterioration of 330 physical media, and various kinds of environmental noise. Radio- 331 based networks are subject to signal fade due to distance, 332 interference, and environmental factors; it is widely noted that IEEE 333 802.15.4 networks frequently place a metal ground plate between the 334 meter and the device that manages it. Fiber was at one time deployed 335 because it was believed to be untappable; we have since learned to 336 tap it by bending the fiber and collecting incidental light, and we 337 have learned about backhoes. So now some installations encase fiber 338 optic cable in a pressurized sheath, both to quickly identify the 339 location of a cut and to make it more difficult to tap. 341 While there are protocol behaviors that can detect certain classes of 342 physical faults, such as keep-alive exchanges, physical security is 343 generally not a protocol problem. 345 2.2.2. Session identification 347 At the transport and application layers, and in lower layer networks 348 where dynamic connectivity like ATM SVCs or "dial" connectivity is in 349 use, there tend to be several different classes of authentication/ 350 authorization requirements. One must 352 1. Verify that the peers one exchanges data with are appropriate 353 partners; this generally means knowing "who" they are and that 354 they have a "need to know" or are trusted sources. 356 2. Verify that information that appears to be from a trusted peer is 357 in fact from that peer. 359 3. Validate the content of the data exchanged; it must conform to 360 the rules of the exchange. 362 4. One must also defend the channel against denial of service 363 attacks. 365 In other words, there is a need to secure the channel that carries a 366 message, and there is a need to secure the exchanges, both by knowing 367 the source of the information and to have proof of its validity. 368 Three examples suffice to illustrate the challenges. 370 One common attack is to bombard a transport session (an application's 371 channel) with reset messages. If the attacker is lucky, he might 372 cause the session to fail. Including information in the transport 373 header or a related protocol like IPsec or TLS that identifies the 374 right messages and facilitates speedy discard of the rest can 375 mitigate this. 377 Another common attack involves unauthorized communication with a 378 router or a service. For example, an unauthorized party might try to 379 join the routing system. One wants the ISP's router, before 380 accepting routing information from a new peer, to 382 o demand identification from the new peer, 384 o verify that the peer is in fact who it claims to be, and 386 o verify that it is authorized to carry on the exchange. 388 More generally, in securing the channel, one wants to verify that 389 messages putatively received from a peer were in fact received from 390 the peer, and given that they are, to only carry on transactions with 391 peers that one trusts. This is analogous to how one responds to a 392 salesman at the front door - one asks who the salesman represents, 393 seeks a credential as proof, and then asks one self whether one wants 394 to deal with that company. Only if all indications are positive does 395 one carry on a transaction. 397 Unfortunately, even trusted peers can be the purveyors of incorrect 398 or malicious content; having secured the channel, one also wants to 399 secure the information exchanged through the channel. In electronic 400 mail and other database exchanges, it may be necessary to be able to 401 verify the identity of the sender and the correctness of the content 402 long after the information exchange has occurred - for example, if a 403 contract is exchanged that is secured by digital signatures, one will 404 wish to be able to verify those signatures at least throughout the 405 lifetime of the contract, and probably a long time after that. 407 The third "A" in "AAA" is Accounting. This service is especially 408 important for Internet Service Providers; the related service of 409 auditing is important for enterprises. RADIUS and DIAMETER are 410 commonly used to realize these services. 412 2.2.3. Confidentiality 414 At several layers, there is a question of confidentiality. If one is 415 putting one's credit card in a transaction, one wants application 416 layer privacy, which might be supplied by an encrypting application 417 or transport layer protocol. If one is trying to hide one's network 418 structure, one might additionally want to encrypt the network layer 419 header. 421 2.3. Network Infrastructure 423 While these are not critical to the design of a specific system, they 424 are important to running a network. We therefore bring them up. 426 2.3.1. Domain Name System (DNS) 428 While not critical to running a network, certain functions are made a 429 lot easier if numeric addresses can be replaced with mnemonic names. 430 This facilitates renumbering of networks, which happens, and 431 generally improves the manageability and serviceability of the 432 network. DNS has a set of security extensions called DNSSEC, which 433 can be used to provide strong cryptographic authentication to that 434 protocol. 436 2.3.2. Network Management Issues 438 Network management has proven to be a difficult problem; there are 439 many solutions, and each has proponents with solid arguments for 440 their viewpoint. In the IETF, we have two major network management 441 solutions for device operation: SNMP, which is ASN.1-encoded and is 442 primarily used for monitoring of system variables in a polled 443 architecture, and NetConf, which is XML-encoded and primarily used 444 for device configuration. 446 Another aspect of network management is the initial provisioning and 447 configuration of hosts. Address assignment and other configuration 448 is discussed in Section 3.4.2. Smart Grid deployments will require 449 additional identity authentication and authorization as well as other 450 provisioning and configuration that may not be within the scope of 451 DHCP and Neighbor Discovery. While the IP Protocol Suite does not 452 have specific solutions for secure provisioning and configuration, 453 these problems have been solved using IP protocols in specifications 454 such as DOCSIS 3.0 [SP-MULPIv3.0]. 456 3. Specific protocols 458 In this section, having briefly laid out the architecture and some of 459 the problems that the architecture tries to address, we introduce 460 specific protocols that might be appropriate to various use cases. 461 In each place, the options are in the protocols used - one wants to 462 select the right privacy, AAA, transport, and network solutions in 463 each case. 465 3.1. Security solutions 467 As noted, a key consideration in security solutions is a good threat 468 analysis coupled with appropriate mitigations at each layer. 470 3.1.1. Session identification, authentication, authorization, and 471 accounting 473 In the Internet Protocol Suite there are several approaches to AAA 474 issues; generally, one chooses one of them for a purpose. As they 475 have different attack surfaces and protection domains, they require 476 some thought in application. Two important ones are the IP Security 477 Architecture, which protects IP datagrams, and Transport Layer 478 Security, which protects the information that the Transport delivers. 480 3.1.2. IP Security Architecture (IPsec) 482 The Security Architecture for the Internet Protocol [RFC4301] is a 483 set of control and data protocols that are implemented between IPv4 484 and its Transport layer, or in IPv6's Security extension header. It 485 allows transport layer sessions (which underlie applications) to 486 communicate in a way that is designed to prevent eavesdropping, 487 tampering, or message forgery. The architecture is spelled out in a 488 number of additional specifications for specific components: the IP 489 Authentication Header [RFC4302] Encapsulating Security Payload (ESP) 490 [RFC4303], Internet Key Exchange (IKEv2) [RFC4306], Cryptographic 491 Algorithms [RFC4307], Cryptographic Algorithm Implementation 492 Requirements for ESP and AH [RFC4835], and the use of Advanced 493 Encryption Standard (AES) [RFC4309]. 495 In the transport mode, IPsec ESP encrypts the transport layer and the 496 application data. In the tunnel mode, which is frequently used for 497 Virtual Private Networks, one also encrypts the Internet Protocol, 498 and encapsulates the encrypted data inside a second IP header 499 directed to the intended decryptor. 501 3.1.3. Transport Layer Security (TLS) 503 Transport Layer Security [RFC5246] and Datagram Transport Layer 504 Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that 505 travel within the transport layer PDU, meaning that they readily 506 traverse network address translators and secure the information 507 exchanges without securing the datagrams exchanged or the transport 508 layer itself. Each allows client/server applications to communicate 509 in a way that is designed to prevent eavesdropping, tampering, or 510 message forgery. 512 3.1.4. Secure/Multipurpose Internet Mail Extensions (S/MIME) 514 The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049] 515 [RFC3850] [RFC3851] [RFC4262] specification was originally specified 516 as an extension to SMTP Mail to provide evidence that the putative 517 sender of an email message in fact sent it, and that the content 518 received was in fact the content that was sent. As its name 519 suggests, by extension this is a way of securing any object that can 520 be exchanged, by any means, and has become one of the most common 521 ways to secure an object. 523 Other approaches also exist, such as the use of digital signatures on 524 XML-encoded files, as jointly standardized by W3C and the IETF 525 [RFC3275]. 527 3.2. Network Layer 529 Here we mention both IPv4 and IPv6. The reader is warned: IPv4 is 530 running out of address space, and IPv6 has positive reasons that one 531 might choose it apart from the IPv6 space such as the address 532 autoconfiguration facility and its ability to support an arbitrarily 533 large number of hosts in a subnet. As such, the IETF recommends that 534 one always choose IPv6 support, and additionally choose IPv4 support 535 in the near term. 537 3.2.1. Internet Protocol Version 4 539 IPv4 [RFC0791], with the Internet Control Message Protocol [RFC0792], 540 constitutes the traditional protocol implemented throughout the 541 Internet. IPv4 provides for transmission of datagrams from source to 542 destination hosts, which are identified by fixed length addresses. 544 IPv4 also provides for fragmentation and reassembly of long 545 datagrams, if necessary, for transmission through "small packet" 546 networks. ICMP, which is a separate protocol implemented along with 547 IPv4, enables the network to report errors and other issues to hosts 548 that originate problematic datagrams. 550 IPv4 originally supported an experimental type of service field that 551 identified eight levels of operational precedence styled after the 552 requirements of military telephony, plus three and later four bit 553 flags that IS-IS and OSPF interpreted as affecting traffic routing 554 for datagrams requiring lower delay or higher throughput. These 555 turned out to be less useful than the designers had hoped. They were 556 replaced by the Differentiated Services Architecture 557 [RFC2474][RFC2475], which contains a six bit code point used to 558 select an algorithm (a "per-hop behavior") to be applied to the 559 datagram. 561 3.2.1.1. IPv4 Address Allocation and Assignment 563 IPv4 addresses are administratively assigned, usually using automated 564 methods, and assigned using the Dynamic Host Configuration Protocol 565 (DHCP) [RFC2131]. On most interface types, neighboring equipment 566 identify each other's addresses using Address Resolution Protocol 567 (ARP) [RFC0826]. 569 3.2.1.2. IPv4 Unicast Routing 571 Routing for the IPv4 Internet is done by routing applications that 572 exchange connectivity information and build semi-static destination 573 routing databases. If a datagram is directed to a given destination 574 address, the address is looked up in the routing database, and the 575 most specific ("longest") prefix found that contains it is used to 576 identify the next hop router, or the end system it will be delivered 577 to. This is not generally implemented on hosts, although it can be; 578 generally, a host sends datagrams to a router on its local network, 579 and the router carries out the intent. 581 IETF specified routing protocols include RIP Version 2 [RFC2453], OSI 582 IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4 583 [RFC4271]. Active research exists in mobile ad hoc routing and other 584 routing paradigms; these result in new protocols and modified 585 forwarding paradigms. 587 3.2.1.3. IPv4 Multicast Forwarding and Routing 589 IPv4 was originally specified as a unicast (point to point) protocol, 590 and was extended to support multicast in [RFC1112]. This uses the 591 Internet Group Management Protocol [RFC3376][RFC4604] to enable 592 applications to join multicast groups, and for most applications uses 593 Source-Specific Multicast [RFC4607] for routing and delivery of 594 multicast messages. 596 An experiment carried out in IPv4 that is not core to the 597 architecture but may be of interest in the Smart Grid is the 598 development of so-called "Reliable Multicast". This is "so-called" 599 because it is not "reliable" in the strict sense of the word - it is 600 perhaps better described as "enhanced reliability". A best effort 601 network by definition can lose traffic, duplicate it, or reorder it, 602 something as true for multicast as for unicast. Research in 603 "Reliable Multicast" technology intends to improve the probability of 604 delivery of multicast traffic. 606 In that research, the IETF imposed guidelines [RFC2357] on the 607 research community regarding what was desirable. Important results 608 from that research include a number of papers and several proprietary 609 protocols including some that have been used in support of business 610 operations. RFCs in the area include The Use of Forward Error 611 Correction (FEC) in Reliable Multicast [RFC3453], the Negative- 612 acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol 613 [RFC3940], and the Selectively Reliable Multicast Protocol (SRMP) 614 [RFC4410]. These are considered experimental. 616 3.2.2. Internet Protocol Version 6 618 IPv6 [RFC2460], with the Internet Control Message Protocol "v6" 619 [RFC4443], constitutes the next generation protocol for the Internet. 620 IPv6 provides for transmission of datagrams from source to 621 destination hosts, which are identified by fixed length addresses. 623 IPv6 also provides for fragmentation and reassembly of long datagrams 624 by the originating host, if necessary, for transmission through 625 "small packet" networks. ICMPv6, which is a separate protocol 626 implemented along with IPv6, enables the network to report errors and 627 other issues to hosts that originate problematic datagrams. 629 IPv6 adopted the Differentiated Services Architecture 630 [RFC2474][RFC2475], which contains a six bit code point used to 631 select an algorithm (a "per-hop behavior") to be applied to the 632 datagram. 634 3.2.2.1. IPv6 Address Allocation and Assignment 636 An IPv6 Address [RFC4291] may be administratively assigned using 637 DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are, 638 but may also be autoconfigured, facilitating network management. 639 Autoconfiguration procedures are defined in [RFC4862] and [RFC4941]. 640 IPv6 neighbors identify each other's addresses using either Neighbor 641 Discovery (ND) [RFC4861] or SEcure Neighbor Discovery (SEND) 642 [RFC3971]. 644 3.2.2.2. IPv6 Routing 646 Routing for the IPv6 Internet is done by routing applications that 647 exchange connectivity information and build semi-static destination 648 routing databases. If a datagram is directed to a given destination 649 address, the address is looked up in the routing database, and the 650 most specific ("longest") prefix found that contains it is used to 651 identify the next hop router, or the end system it will be delivered 652 to. This is not generally implemented on hosts, although it can be; 653 generally, a host sends datagrams to a router on its local network, 654 and the router carries out the intent. 656 IETF specified routing protocols include RIP for IPv6 [RFC2080], 657 IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6 658 [RFC2545]. Active research exists in mobile ad hoc routing, routing 659 in low power networks (sensors and smart grids) and other routing 660 paradigms; these result in new protocols and modified forwarding 661 paradigms. 663 3.2.2.3. IPv6 Multicast Forwarding and Routing 665 From its initial design, IPv6 has specified both unicast and 666 multicast datagram exchange. This uses the Multicast Listener 667 Discovery Protocol (MLDv2) [RFC2710] [RFC3590] [RFC3810] [RFC4604] to 668 enable applications to join multicast groups, and for most 669 applications uses Source-Specific Multicast [RFC4607] for routing and 670 delivery of multicast messages. 672 The IPv6 over Low-Power Wireless Personal Area Networks [RFC4919] RFC 673 addresses IPv6 header compression and subnet architecture in at least 674 some sensor networks, and may be appropriate to the Smart Grid AMI or 675 other sensor domains. 677 The mechanisms experimentally developed for reliable multicast in 678 IPv4, discussed in Section 3.2.1.3, can be used in IPv6 as well. 680 3.2.3. Adaptation to lower layer networks and link layer protocols 682 In general, the layered architecture enables the Internet Protocol 683 Suite to run over any appropriate layer 2 architecture; with tongue 684 in cheek, specifications have been written and demonstrated to work 685 for the carriage of IP by Carrier Pigeon [RFC1149][RFC2549] (perhaps 686 the most common carrier known to man) and on barbed wire [Chapman]. 687 The ability to change the link or physical layer without having to 688 rethink the network layer, transports, or applications has been a 689 great benefit in the Internet. 691 Examples of link layer adaptation technology include: 693 Ethernet/IEEE 802.3: IPv4 has run on each link layer environment 694 that uses the Ethernet header (which is to say 10 and 100 MBPS 695 wired Ethernet, 1 and 10 GBPS wired Ethernet, and the various 696 versions of IEEE 802.11) using [RFC0894]. IPv6 does the same 697 using [RFC2464]. 699 PPP: The IETF has defined a serial line protocol, the Point-to-Point 700 Protocol (PPP) [RFC1661], that uses HDLC (bit-synchronous or byte 701 synchronous) framing. The IPv4 adaptation specification is 702 [RFC1332], and the IPv6 adaptation specification is [RFC5072]. 703 Current use of this protocol is in traditional serial lines, 704 authentication exchanges in DSL networks using PPP Over Ethernet 705 (PPPoE) [RFC2516], and in the Digital Signaling Hierarchy 706 (generally referred to as Packet-on-SONET/SDH) using PPP over 707 SONET/SDH [RFC2615]. 709 IEEE 802.15.4: The adaptation specification for IPv6 transmission 710 over IEEE 802.15.4 Networks is [RFC4944]. 712 Numerous other adaptation specifications exist, including ATM, Frame 713 Relay, X.25, other standardized and proprietary LAN technologies, and 714 others. 716 3.3. Transport Layer 718 In this we list several transports: UDP, TCP, SCTP, and DCCP. Of 719 these, UDP and TCP are best known and most widely used, due to 720 history. SCTP and DCCP were built for specific purposes more 721 recently and bear consideration at least for those purposes. 723 Note that if it is appropriate, other transports can also be built. 724 This is largely a question of requirements. 726 3.3.1. User Datagram Protocol (UDP) 728 The User Datagram Protocol [RFC0768] and the Lightweight User 729 Datagram Protocol [RFC3828] are properly not "transport" protocols in 730 the sense of "a set of rules governing the exchange or transmission 731 of data electronically between devices". They are labels that 732 provide for multiplexing of applications directly on the IP layer, 733 with transport functionality embedded in the application. 735 From a historical perspective, one should note that many simplistic 736 exchange designs have been built using UDP, and many of them have not 737 worked all that well. The use of UDP really should be treated as 738 designing a new transport. More generally, advice on the use of UDP 739 in new applications has been compiled in the Unicast UDP Usage 740 Guidelines for Application Designers [RFC5405]. 742 Datagram Transport Layer Security [RFC5238] can be used to prevent 743 eavesdropping, tampering, or message forgery. Alternatively, UDP can 744 run over IPsec. 746 3.3.2. Transmission Control Protocol (TCP) 748 TCP [RFC0793] is the predominant transport protocol in use in the 749 Internet, with a long history. It is "reliable", as the term is used 750 in protocol design: it delivers data to its peer and provides 751 acknowledgement to the sender, or it dies trying. It has extensions 752 for Congestion Control [RFC2581] and Explicit Congestion Notification 753 [RFC3168]. 755 The user interface for TCP is a byte stream interface - an 756 application using TCP might "write" to it several times only to have 757 the data compacted into a common segment and delivered as such to its 758 peer. For message-stream interfaces, we generally use the ISO 759 Transport Service on TCP [RFC1006][RFC2126] in the application. 761 Transport Layer Security [RFC5246] can be used to prevent 762 eavesdropping, tampering, or message forgery. Alternatively, TCP can 763 run over IPsec. Additionally, [RFC4987] discusses mechanisms similar 764 to SCTP and DCCP's "cookie" approach that may be used to secure TCP 765 sessions against flooding attacks. 767 TCP has supported ongoing research since it was written. As a 768 result, the End to End research group has published a Roadmap for TCP 769 Specification Documents [RFC4614] which will guide expectations in 770 that area. 772 3.3.3. Stream Control Transmission Protocol (SCTP) 774 SCTP [RFC4960] is a more recent reliable transport protocol that can 775 be imagined as a TCP-like context containing multiple separate and 776 independent message streams (as opposed to TCP's byte streams). The 777 design of SCTP includes appropriate congestion avoidance behavior and 778 resistance to flooding and masquerade attacks. As it uses a message 779 stream interface as opposed to TCP's byte stream interface, it may 780 also be more appropriate for the ISO Transport Service than RFC 1006/ 781 2126. 783 SCTP offers several delivery options. The basic service is 784 sequential non-duplicated delivery of messages within a stream, for 785 each stream in use. Since streams are independent, one stream may 786 pause due to head of line blocking while another stream in the same 787 session continues to deliver data. In addition, SCTP provides a 788 mechanism for bypassing the sequenced delivery service. User 789 messages sent using this mechanism are delivered to the SCTP user as 790 soon as they are received. 792 SCTP implements a simple "cookie" mechanism intended to limit the 793 effectiveness of flooding attacks by mutual authentication. This 794 demonstrates that the application is connected to the same peer, but 795 does not identify the peer. Mechanisms also exist for Dynamic 796 Address Reconfiguration [RFC5061], enabling peers to change addresses 797 during the session and yet retain connectivity. Transport Layer 798 Security [RFC3436] can be used to prevent eavesdropping, tampering, 799 or message forgery. Alternatively, SCTP can run over IPsec. 801 3.3.4. Datagram Congestion Control Protocol (DCCP) 803 DCCP [RFC4340] is an "unreliable" transport protocol (e.g., one that 804 does not guarantee message delivery) that provides bidirectional 805 unicast connections of congestion-controlled unreliable datagrams. 806 DCCP is suitable for applications that transfer fairly large amounts 807 of data and that can benefit from control over the tradeoff between 808 timeliness and reliability. 810 DCCP implements a simple "cookie" mechanism intended to limit the 811 effectiveness of flooding attacks by mutual authentication. This 812 demonstrates that the application is connected to the same peer, but 813 does not identify the peer. Datagram Transport Layer Security 814 [RFC5238] can be used to prevent eavesdropping, tampering, or message 815 forgery. Alternatively, DCCP can run over IPsec. 817 3.4. Infrastructure 819 3.4.1. Domain Name System 821 To facilitate network management and operations, the Internet 822 Community has defined the Domain Name System (DNS) 823 [RFC1034][RFC1035]. Names are hierarchical: a name like example.com 824 is found registered with a .com registrar, and within the associated 825 network other names like baldur.cincinatti.example.com can be 826 defined, with obvious hierarchy. Security extensions, which all a 827 registry to sign the records it contains and as a result demonstrate 828 their authenticity, are defined by the DNS Security Extensions 829 [RFC4033][RFC4034][RFC4035]. 831 Similarly unrequired but useful is the ability for a device to update 832 its own DNS record. One could imagine a sensor, for example, that is 833 using Stateless Address Autoconfiguration [RFC4862] to create an 834 address to associate it with a name using DNS Dynamic Update 835 [RFC2136] or DNS Secure Dynamic Update [RFC3007]. 837 3.4.2. Dynamic Host Configuration 839 As discussed in Section 3.2.1 and Section 3.2.2, IPv6 address 840 assignment can be accomplished using autoconfiguration but can also 841 be accomplished using DHCP [RFC2131] or DHCPv6 [RFC3315]. The best 842 argument for the use of autoconfiguration is a large number of 843 systems that require little more than a random number as an address; 844 the argument for DHCP is administrative control. 846 There are other parameters that may need to be allocated to hosts, 847 and these do require administrative configuration; examples include 848 the address of one's DNS server, keys if Secure DNS is in use, and 849 others. 851 3.5. Other Applications 853 There are several applications that are widely used but are not 854 properly thought of as infrastructure. 856 3.5.1. Network Time 858 The Network Time Protocol was originally designed by Dave Mills of 859 the University of Delaware and CSNET, for the purpose of implementing 860 a temporal metric in the Fuzzball Routing Protocol and generally 861 coordinating time experiments. The current versions of the time 862 protocol are the Network Time Protocol [RFC1305], which is designed 863 for synchronization to within a few microseconds, and the Simple 864 Network Time Protocol [RFC4330] which is used to set real time clocks 865 to within a few milliseconds. The former is more precise, but relies 866 on frequent exchanges; the latter is less precise and lower overhead. 868 NTP is currently being updated in [I-D.ietf-ntp-ntpv4-proto]. 870 3.5.2. Session Initiation Protocol 872 The Session Initiation Protocol 873 [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an 874 application layer control (signaling) protocol for creating, 875 modifying and terminating multimedia sessions on the Internet, meant 876 to be more scalable than H.323. Multimedia sessions can be voice, 877 video, instant messaging, shared data, and/or subscriptions of 878 events. SIP can run on top of TCP, UDP, SCTP, or TLS over TCP. SIP 879 is independent of the transport layer, and independent of the 880 underlying IPv4/v6 version. In fact, the transport protocol used can 881 change as the SIP message traverses SIP entities from source to 882 destination. 884 SIP itself does not choose whether a session is voice or video, the 885 SDP: Session Description Protocol [RFC4566]. Within the SDP, which 886 is transported by SIP, codecs are offered and accepted (or not), the 887 port number and IP address is decided for where each endpoint wants 888 to receive their RTP [RFC3550] packets. This part is critical to 889 understand because of the affect on NATs. Unless a NAT (with or 890 without a Firewall) is designed to be SDP aware (i.e., looking into 891 each packet far enough to discover what the IP address and port 892 number is for this particular session - and resetting it based on the 893 Session Traversal Utilities for NAT [RFC5389], the session 894 established by SIP will not result in RTP packets being sent to the 895 proper endpoint (in SIP called a user agent, or UA). It should be 896 noted that SIP messaging has no issues with NATs, it is just the UA's 897 inability to generally learn about the presence of the NATs that 898 prevent the RTP packets from being received by the UA establishing 899 the session. 901 3.5.3. Calendaring 903 Internet calendaring, as implemented in Apple iCal, Microsoft Outlook 904 and Entourage, and Google Calendar, is specified in Internet 905 Calendaring and Scheduling Core Object Specification (iCalendar) 906 [RFC5545] and is in the process of being updated to an XML schema in 907 iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml] 908 Several protocols exist to carry calendar events, including 909 Transport-Independent Interoperability Protocol (iTIP) [RFC2446], 910 (which has recently been updated in [I-D.ietf-calsify-2446bis]) , the 911 Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open 912 source work on the Atom Publishing Protocol [RFC5023]. 914 4. A simplied view of the business architecture 916 The Internet was originally structured in such a way that any host 917 could directly connect to any other host for which it could determine 918 an IP address. That was very quickly found to have issues, and folks 919 found ways to change that. To understand the implications, one must 920 understand, at a high level, the business structure of the Internet. 922 The Internet, whose name implies that it is a network of networks, 923 may be understood as a number of interconnected businesses. Central 924 to its business structure are the networks that provide connectivity 925 to other networks, called "Transit Providers". These networks sell 926 bulk bandwidth to each other, and to other networks as customers. 927 Around the periphery of these networks, one finds companies, schools, 928 and other networks that provide services directly to individuals. 929 These might generally be divided into "Enterprise Networks" and 930 "Access Networks"; Enterprise networks provide "free" connectivity to 931 their own employees or members, and also provide them a set of 932 services including electronic mail, web services, and so on. Access 933 Networks sell broadband connectivity (DSL, Cable Modem, 802.11 934 wireless or 3GPP wireless), or "dial" services including PSTN dial-up 935 and ISDN, to subscribers. The subscribers are typically either 936 residential or small office/home office (SOHO) customers. 937 Residential customers are generally entirely dependent on their 938 access provider for all services, while a SOHO buys some services 939 from the access provider and may provide others for itself. Networks 940 that sell transit services to nobody else - SOHO, residential, and 941 enterprise networks - are generally refereed to as "edge networks"; 942 Transit Networks are considered to be part of the "core" of the 943 Internet, and access networks are between the two. This general 944 structure is depicted in Figure 3. 946 ------ ------ 947 / \ / \ 948 /--\ / \ / \ 949 |SOHO|---+ Access | |Enterprise| 950 \--/ | Service | | Network | 951 /--\ | Provider| | | 952 |Home|---+ | ------ | | 953 \--/ \ +---+ +---+ / 954 \ / / \ \ / 955 ------ | Transit | ------ 956 | Service | 957 | Provider | 958 | | 959 \ / 960 \ / 961 ------ 963 Figure 3: Conceptual model of Internet businesses 965 A specific example is shown in a traceroute from the author's home to 966 a school he can see nearby. Internet connectivity in Figure 4 passes 967 through 969 o The author's home, 971 o Cox Communications, an Access Network using Cable Modem 972 technology, 974 o TransitRail, a commodity peering service for research and 975 education (R&E) networks, 977 o Corporation for Education Network Initiatives in California 978 (CENIC), a transit provider for educational networks, and 980 o the University of California at Santa Barbara, which in this 981 context might be viewed as an access network for its students and 982 faculty or as an enterprise network. 984 fred% traceroute www.ucsb.edu 985 traceroute to web.ucsb.edu (128.111.24.41), 986 64 hops max, 40 byte packets 987 1 fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms 988 2 wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms ... 989 3 68.6.13.101 ... 990 4 68.6.13.129 ... 991 5 langbbr01-as0.r2.la.cox.net ... 992 6 calren46-cust.lsanca01.transitrail.net ... 993 7 dc-lax-core1--lax-peer1-ge.cenic.net ... 994 8 dc-lax-agg1--lax-core1-ge.cenic.net ... 995 9 dc-ucsb--dc-lax-dc2.cenic.net ... 996 10 r2--r1--1.commserv.ucsb.edu ... 997 11 574-c--r2--2.commserv.ucsb.edu ... 998 12 * * * 1000 Figure 4: Traceroute from residential customer to educational 1001 institution 1003 Another specific example could be shown in a traceroute from the 1004 author's home to his employer. Internet connectivity in that case 1005 uses a Virtual Private Network (VPN tunnel) from the author's home, 1006 crossing Cox Cable (an Access Network) and Pacific Bell (a Transit 1007 Network), and terminating in Cisco Systems (an Enterprise Network); a 1008 traceroute of the path doesn't show that as it is invisible within 1009 the VPN and the contents of the VPN are invisible, due to encryption, 1010 to the networks on the path. Instead, the traceroute in Figure 5 is 1011 entirely within Cisco's internal network. 1013 fred% traceroute irp-view13 1014 traceroute to irp-view13.cisco.com (171.70.120.60), 1015 64 hops max, 40 byte packets 1016 1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms 1017 1018 2 **** 1019 3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms... 1020 4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ... 1021 5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ... 1022 6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ... 1023 7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ... 1024 8 sjc12-dc5-gw2-ten3-1 ... 1025 9 sjc5-dc4-gw1-ten8-1 ... 1026 10 irp-view13 ... 1028 Figure 5: Traceroute across VPN 1030 In both cases, it will be observed that the author's home internally 1031 uses address space from the Address Allocation for Private Internets 1033 [RFC1918], and other networks generally use public address space. It 1034 will also be observed that on entry to UCSB, the traceroute in 1035 Figure 4 terminates before arriving at the target. 1037 Three middleware technologies are in obvious use here. These are the 1038 use of a firewall, a Network Address Translator (NAT), and a Virtual 1039 Private Network (VPN). 1041 Firewalls are generally sold as, and considered, a security 1042 technology. A firewall imposes a border between two administrative 1043 domains, which are usually a residential, SOHO, or enterprise network 1044 and its access or transit provider. In its essence, a firewall is a 1045 data diode, imposing a policy on what sessions may pass between a 1046 protected domain and the rest of the Internet. Simple policies 1047 generally permit sessions to be originated from the protected network 1048 but not from the outside; more complex policies may permit additional 1049 sessions from the outside, as electronic mail to a mail server or a 1050 web session to a web server, and may prevent certain applications 1051 from global access even though they are originated from the inside. 1052 Firewalls are controversial in the Internet community; network 1053 managers often insist on them simply because they impose a boundary; 1054 others point out that their value as a security solution is 1055 debatable, as most attacks come from behind the firewall and 1056 application layer attacks such as viruses carried in email or Active 1057 X are invisible to them. In general, as a security solution, they 1058 are justified as a defense in depth; while the end system must in the 1059 end be responsible for its own security, a firewall can inhibit or 1060 prevent certain kinds of attacks from certain quarters such as the 1061 consumption of CPU time on a critical server. Key documents 1062 describing firewall technology and the issues it poses include: 1064 o IP Multicast and Firewalls [RFC2588] 1066 o Benchmarking Terminology for Firewall Performance [RFC2647] 1068 o Behavior of and Requirements for Internet Firewalls [RFC2979] 1070 o Benchmarking Methodology for Firewall Performance [RFC3511] 1072 o Mobile IPv6 and Firewalls: Problem Statement [RFC4487] 1074 o NAT and Firewall Traversal Issues of Host Identity Protocol 1075 Communication [RFC5207] 1077 Network Address Translation is a technology that was developed in 1078 response to ISP behaviors in the mid-1990's; when [RFC1918] was 1079 published, many ISPs started handing out single or small numbers of 1080 addresses, and edge networks were forced to translate. In time, this 1081 became considered a good thing, or at least not a bad thing; it 1082 amplified the public address space, and it was sold as if it were a 1083 firewall. It of course is not; while traditional dynamic NATs only 1084 translate between internal and external session address/aport tuples 1085 during the detected duration of the session, that session state may 1086 exist in the network much longer than it exists on the end system, 1087 and as a result constitutes an attack vector. The design, value, and 1088 limitations of network address translation are described in: 1090 o IP Network Address Translator Terminology and Considerations 1091 [RFC2663] 1093 o Traditional IP Network Address Translator [RFC3022] 1095 o Protocol Complications with the IP Network Address Translator 1096 [RFC3027] 1098 o Network Address Translator Friendly Application Design Guidelines 1099 [RFC3235] 1101 o IAB Considerations for Network Address Translation [RFC3424] 1103 o IPsec-Network Address Translation Compatibility Requirements 1104 [RFC3715] 1106 o Network Address Translation Behavioral Requirements for Unicast 1107 UDP [RFC4787] 1109 o State of Peer-to-Peer Communication across Network Address 1110 Translators [RFC5128] 1112 o IP Multicast Requirements for a Network Address Translator and a 1113 Network Address Port Translator [RFC5135] 1115 Virtual Private Networks come in many forms; what they have in common 1116 is that they are generally tunneled over the internet backbone, so 1117 that as in Figure 5, connectivity appears to be entirely within the 1118 edge network although it is in fact across a service provider's 1119 network. Examples include IPsec tunnel-mode encrypted tunnels, IP- 1120 in-IP or Generic Routing Encapsulation (GRE) [RFC2784] tunnels, and 1121 MPLS LSPs [RFC3031][RFC3032]. . 1123 5. IANA Considerations 1125 This memo asks the IANA for no new parameters. 1127 Note to RFC Editor: This section will have served its purpose if it 1128 correctly tells IANA that no new assignments or registries are 1129 required, or if those assignments or registries are created during 1130 the RFC publication process. From the author"s perspective, it may 1131 therefore be removed upon publication as an RFC at the RFC Editor's 1132 discretion. 1134 6. Security Considerations 1136 Security is addressed in some detail in Section 2.2 and Section 3.1. 1138 7. Acknowledgements 1140 Review comments were made by Andrew Yourtchenko, Ashok Narayanan, 1141 Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Hemant 1142 Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry 1143 Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, 1144 Ralph Droms, Russ White, Sheila Frankel, and Toerless Eckert. Dave 1145 McGrew and Ralph Droms suggested text. 1147 8. References 1149 8.1. Normative References 1151 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1152 Communication Layers", STD 3, RFC 1122, October 1989. 1154 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1155 and Support", STD 3, RFC 1123, October 1989. 1157 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1158 RFC 1812, June 1995. 1160 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 1161 April 2006. 1163 8.2. Informative References 1165 [Chapman] Chapman, E., "Ethernet over Barbed Wire, Arcnet, 100MB 1166 Token Ring, 100Base-VGAnylan and iSCSI ...", 2007. 1168 [I-D.daboo-et-al-icalendar-in-xml] 1169 Daboo, C., Douglass, M., and S. Lees, "iCalendar XML 1170 Representation", draft-daboo-et-al-icalendar-in-xml-00 1171 (work in progress), June 2009. 1173 [I-D.ietf-6man-node-req-bis] 1174 Loughney, J. and T. Narten, "IPv6 Node Requirements RFC 1175 4294-bis", draft-ietf-6man-node-req-bis-03 (work in 1176 progress), July 2009. 1178 [I-D.ietf-calsify-2446bis] 1179 Daboo, C., "iCalendar Transport-Independent 1180 Interoperability Protocol (iTIP)", 1181 draft-ietf-calsify-2446bis-09 (work in progress), 1182 April 2009. 1184 [I-D.ietf-ntp-ntpv4-proto] 1185 Burbank, J., "Network Time Protocol Version 4 Protocol And 1186 Algorithms Specification", draft-ietf-ntp-ntpv4-proto-11 1187 (work in progress), September 2008. 1189 [I-D.ietf-tls-rfc4347-bis] 1190 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1191 Security version 1.2", draft-ietf-tls-rfc4347-bis-03 (work 1192 in progress), October 2009. 1194 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1195 August 1980. 1197 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1198 September 1981. 1200 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1201 RFC 792, September 1981. 1203 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1204 RFC 793, September 1981. 1206 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1207 converting network protocol addresses to 48.bit Ethernet 1208 address for transmission on Ethernet hardware", STD 37, 1209 RFC 826, November 1982. 1211 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 1212 over Ethernet networks", STD 41, RFC 894, April 1984. 1214 [RFC1006] Rose, M. and D. Cass, "ISO transport services on top of 1215 the TCP: Version 3", STD 35, RFC 1006, May 1987. 1217 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1218 STD 13, RFC 1034, November 1987. 1220 [RFC1035] Mockapetris, P., "Domain names - implementation and 1221 specification", STD 13, RFC 1035, November 1987. 1223 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1224 RFC 1112, August 1989. 1226 [RFC1149] Waitzman, D., "Standard for the transmission of IP 1227 datagrams on avian carriers", RFC 1149, April 1990. 1229 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1230 dual environments", RFC 1195, December 1990. 1232 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1233 Specification, Implementation", RFC 1305, March 1992. 1235 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1236 (IPCP)", RFC 1332, May 1992. 1238 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1239 RFC 1661, July 1994. 1241 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1242 E. Lear, "Address Allocation for Private Internets", 1243 BCP 5, RFC 1918, February 1996. 1245 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1246 Extensions (MIME) Part One: Format of Internet Message 1247 Bodies", RFC 2045, November 1996. 1249 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1250 Extensions (MIME) Part Two: Media Types", RFC 2046, 1251 November 1996. 1253 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1254 Part Three: Message Header Extensions for Non-ASCII Text", 1255 RFC 2047, November 1996. 1257 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1258 Extensions (MIME) Part Five: Conformance Criteria and 1259 Examples", RFC 2049, November 1996. 1261 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 1262 January 1997. 1264 [RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top 1265 of TCP (ITOT)", RFC 2126, March 1997. 1267 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1268 RFC 2131, March 1997. 1270 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1271 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1272 RFC 2136, April 1997. 1274 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1276 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1277 Criteria for Evaluating Reliable Multicast Transport and 1278 Application Protocols", RFC 2357, June 1998. 1280 [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, 1281 "iCalendar Transport-Independent Interoperability Protocol 1282 (iTIP) Scheduling Events, BusyTime, To-dos and Journal 1283 Entries", RFC 2446, November 1998. 1285 [RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar 1286 Message-Based Interoperability Protocol (iMIP)", RFC 2447, 1287 November 1998. 1289 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1290 November 1998. 1292 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1293 (IPv6) Specification", RFC 2460, December 1998. 1295 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1296 Networks", RFC 2464, December 1998. 1298 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1299 "Definition of the Differentiated Services Field (DS 1300 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1301 December 1998. 1303 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1304 and W. Weiss, "An Architecture for Differentiated 1305 Services", RFC 2475, December 1998. 1307 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 1308 and R. Wheeler, "A Method for Transmitting PPP Over 1309 Ethernet (PPPoE)", RFC 2516, February 1999. 1311 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1312 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1313 March 1999. 1315 [RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of 1316 Service", RFC 2549, April 1999. 1318 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1319 Control", RFC 2581, April 1999. 1321 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, 1322 May 1999. 1324 [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, 1325 June 1999. 1327 [RFC2647] Newman, D., "Benchmarking Terminology for Firewall 1328 Performance", RFC 2647, August 1999. 1330 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1331 Translator (NAT) Terminology and Considerations", 1332 RFC 2663, August 1999. 1334 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1335 Listener Discovery (MLD) for IPv6", RFC 2710, 1336 October 1999. 1338 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1339 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1340 March 2000. 1342 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1343 Firewalls", RFC 2979, October 2000. 1345 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1346 Update", RFC 3007, November 2000. 1348 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1349 Address Translator (Traditional NAT)", RFC 3022, 1350 January 2001. 1352 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications 1353 with the IP Network Address Translator", RFC 3027, 1354 January 2001. 1356 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1357 Label Switching Architecture", RFC 3031, January 2001. 1359 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1360 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1361 Encoding", RFC 3032, January 2001. 1363 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1364 of Explicit Congestion Notification (ECN) to IP", 1365 RFC 3168, September 2001. 1367 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 1368 Application Design Guidelines", RFC 3235, January 2002. 1370 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1371 A., Peterson, J., Sparks, R., Handley, M., and E. 1372 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1373 June 2002. 1375 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1376 Event Notification", RFC 3265, June 2002. 1378 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1379 Language) XML-Signature Syntax and Processing", RFC 3275, 1380 March 2002. 1382 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1383 and M. Carney, "Dynamic Host Configuration Protocol for 1384 IPv6 (DHCPv6)", RFC 3315, July 2003. 1386 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1387 Thyagarajan, "Internet Group Management Protocol, Version 1388 3", RFC 3376, October 2002. 1390 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1391 Self-Address Fixing (UNSAF) Across Network Address 1392 Translation", RFC 3424, November 2002. 1394 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 1395 Layer Security over Stream Control Transmission Protocol", 1396 RFC 3436, December 2002. 1398 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1399 M., and J. Crowcroft, "The Use of Forward Error Correction 1400 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1402 [RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin, 1403 "Benchmarking Methodology for Firewall Performance", 1404 RFC 3511, April 2003. 1406 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1407 Jacobson, "RTP: A Transport Protocol for Real-Time 1408 Applications", STD 64, RFC 3550, July 2003. 1410 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1411 Listener Discovery (MLD) Protocol", RFC 3590, 1412 September 2003. 1414 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 1415 (NAT) Compatibility Requirements", RFC 3715, March 2004. 1417 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1418 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1420 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1421 G. Fairhurst, "The Lightweight User Datagram Protocol 1422 (UDP-Lite)", RFC 3828, July 2004. 1424 [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail 1425 Extensions (S/MIME) Version 3.1 Certificate Handling", 1426 RFC 3850, July 2004. 1428 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1429 Extensions (S/MIME) Version 3.1 Message Specification", 1430 RFC 3851, July 2004. 1432 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1433 Requirement for the Session Initiation Protocol (SIP)", 1434 RFC 3853, July 2004. 1436 [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1437 "Negative-acknowledgment (NACK)-Oriented Reliable 1438 Multicast (NORM) Protocol", RFC 3940, November 2004. 1440 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1441 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1443 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1444 Rose, "DNS Security Introduction and Requirements", 1445 RFC 4033, March 2005. 1447 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1448 Rose, "Resource Records for the DNS Security Extensions", 1449 RFC 4034, March 2005. 1451 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1452 Rose, "Protocol Modifications for the DNS Security 1453 Extensions", RFC 4035, March 2005. 1455 [RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ 1456 Multipurpose Internet Mail Extensions (S/MIME) 1457 Capabilities", RFC 4262, December 2005. 1459 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1460 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1462 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 1463 Extensions (MIME) Part Four: Registration Procedures", 1464 BCP 13, RFC 4289, December 2005. 1466 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1467 Architecture", RFC 4291, February 2006. 1469 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1470 Internet Protocol", RFC 4301, December 2005. 1472 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1473 December 2005. 1475 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1476 RFC 4303, December 2005. 1478 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1479 RFC 4306, December 2005. 1481 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 1482 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 1483 December 2005. 1485 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1486 Mode with IPsec Encapsulating Security Payload (ESP)", 1487 RFC 4309, December 2005. 1489 [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the 1490 Session Initiation Protocol's (SIP) Non-INVITE 1491 Transaction", RFC 4320, January 2006. 1493 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 1494 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 1496 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1497 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1499 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1500 Security", RFC 4347, April 2006. 1502 [RFC4410] Pullen, M., Zhao, F., and D. Cohen, "Selectively Reliable 1503 Multicast Protocol (SRMP)", RFC 4410, February 2006. 1505 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1506 Message Protocol (ICMPv6) for the Internet Protocol 1507 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1509 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 1510 IPv6 and Firewalls: Problem Statement", RFC 4487, 1511 May 2006. 1513 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1514 Description Protocol", RFC 4566, July 2006. 1516 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1517 Group Management Protocol Version 3 (IGMPv3) and Multicast 1518 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1519 Specific Multicast", RFC 4604, August 2006. 1521 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1522 IP", RFC 4607, August 2006. 1524 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1525 for Transmission Control Protocol (TCP) Specification 1526 Documents", RFC 4614, September 2006. 1528 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1529 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1530 RFC 4787, January 2007. 1532 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 1533 Requirements for Encapsulating Security Payload (ESP) and 1534 Authentication Header (AH)", RFC 4835, April 2007. 1536 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1537 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1538 September 2007. 1540 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1541 Address Autoconfiguration", RFC 4862, September 2007. 1543 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1544 Protocol (SIP)", RFC 4916, June 2007. 1546 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1547 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1548 Overview, Assumptions, Problem Statement, and Goals", 1549 RFC 4919, August 2007. 1551 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1552 Extensions for Stateless Address Autoconfiguration in 1553 IPv6", RFC 4941, September 2007. 1555 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1556 "Transmission of IPv6 Packets over IEEE 802.15.4 1557 Networks", RFC 4944, September 2007. 1559 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1560 RFC 4960, September 2007. 1562 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1563 Mitigations", RFC 4987, August 2007. 1565 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 1566 Protocol", RFC 5023, October 2007. 1568 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1569 Kozuka, "Stream Control Transmission Protocol (SCTP) 1570 Dynamic Address Reconfiguration", RFC 5061, 1571 September 2007. 1573 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 1574 PPP", RFC 5072, September 2007. 1576 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 1577 Peer (P2P) Communication across Network Address 1578 Translators (NATs)", RFC 5128, March 2008. 1580 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a 1581 Network Address Translator (NAT) and a Network Address 1582 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 1584 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 1585 Firewall Traversal Issues of Host Identity Protocol (HIP) 1586 Communication", RFC 5207, April 2008. 1588 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1589 the Datagram Congestion Control Protocol (DCCP)", 1590 RFC 5238, May 2008. 1592 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1593 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1595 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1596 October 2008. 1598 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1599 for IPv6", RFC 5340, July 2008. 1601 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1602 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1603 October 2008. 1605 [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, 1606 "Addressing an Amplification Vulnerability in Session 1607 Initiation Protocol (SIP) Forking Proxies", RFC 5393, 1608 December 2008. 1610 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1611 for Application Designers", BCP 145, RFC 5405, 1612 November 2008. 1614 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 1615 Core Object Specification (iCalendar)", RFC 5545, 1616 September 2009. 1618 [RFC5621] Camarillo, G., "Message Body Handling in the Session 1619 Initiation Protocol (SIP)", RFC 5621, September 2009. 1621 [SP-MULPIv3.0] 1622 CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols 1623 Interface Specification, CM-SP-MULPIv3.0-I10-090529", 1624 May 2009. 1626 Author's Address 1628 Fred Baker 1629 Cisco Systems 1630 Santa Barbara, California 93117 1631 USA 1633 Email: fred@cisco.com