idnits 2.17.1 draft-macaulay-6man-packet-stain-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Aug 2012) is 4271 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'REF 1' is mentioned on line 144, but not defined == Missing Reference: 'RFC4302' is mentioned on line 353, but not defined == Unused Reference: 'REF2' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 415, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'REF1' -- Possible downref: Non-RFC (?) normative reference: ref. 'REF2' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group T. Macaulay 3 Internet-Draft McAfee Inc. 4 Intended status: Standards Track Aug 2012 5 Expires: February 2, 2013 7 IPv6 packet staining 8 draft-macaulay-6man-packet-stain-01 10 Abstract 12 This document specifies the application of security staining on an 13 IPv6 datagrams and the minimum requirements for IPv6 nodes staining 14 flows, IPv6 nodes forwarding stained packets within a given domain of 15 control, and nodes interpreting stains on flows. 17 The usage of the packet staining destination option enables proactive 18 delivery of security intelligence to IPv6 nodes such as firewalls and 19 intrusion prevention systems, and end-points such servers, 20 workstations, mobile and smart devices and an infinite array of as- 21 yet-to-be-invented sensors and controllers. 23 The usage of packet staining is not intended for use across the open 24 internet, where fragmentation issues associated with increased header 25 size may induce service degradation; packet staining is intended as a 26 security adjunct within a given doamin of control such as an carrier 27 or enterprise network. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 2, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Packet Staining Benefits . . . . . . . . . . . . . . . . . 4 67 3.2. Implementation and support models . . . . . . . . . . . . 5 68 3.3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Requirements for staining IPv6 packets . . . . . . . . . . . . 7 70 5. Packet Stain Destination Option (PSDO) . . . . . . . . . . . . 7 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 From the viewpoint of the network layer, a flow is a sequence of 80 packets sent from a particular source to a particular unicast, 81 anycast, or multicast destination. From an upper layer viewpoint, a 82 flow could consist of all packets in one direction of a specific 83 transport connection or media stream. However, a flow is not 84 necessarily 1:1 mapped to a transport connection. 86 Traditionally, flow classifiers have been based on the 5-tuple of the 87 source and destination addresses, ports, and the transport protocol 88 type. However, as the growth of internetworked devices continues 89 under IPv6, security issues associated with the reputation of the 90 source of flows are becoming a critical criterion associated with the 91 trust of the data payloads and the security of the destination end- 92 points and the networks on which they reside. 94 The usage of security reputational intelligence associated with the 95 source address field and possibly the port and protocol [REF1] 96 enables packet-by-packet IPv6 security classification, where the IPv6 97 header extensions in the form of Destination Options may be used to 98 stain each packet with security reputation information such that the 99 network routing is unaffected, but intermediate security nodes and 100 endpoint devices can apply policy decisions about incoming 101 information flows without the requirement to assemble and treat 102 payloads at higher levels of the stack. 104 IPv6 packet staining support consists of labeling datagrams with 105 security reputation information through the addition of an IPv6 106 destination option in the packet header by packet manipulation 107 devices (PMDs) in the carrier or enterprise network. This 108 destination option may be read by in-line security nodes upstream 109 from the packet destination, as well as by the destination nodes 110 themselves. 112 The usage of packet staining is not intended for use across the open 113 internet, where fragmentation issues associated with increased header 114 size may induce service degradation; packet staining is intended as a 115 security adjunct within a given doamin of control such as an carrier 116 or enterprise network. 118 2. Conventions used in this document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 3. Background 126 Internet based threats in the form of both malicious software and the 127 agents that control this software (organized crime, spys, 128 hackitivits) have surpassed the abilities of signature-based security 129 systems; whether they be on the enterprise perimeter, within the 130 corporate network, on the endpoint point or in-the-cloud (internet- 131 based service). Additionally, the sensitivity of IP network 132 continues to grow as new generation of smart devices is appearing on 133 the networks in the form of broadband mobile devices, legacy 134 industrial control devices, and very low-power sensors. This diverse 135 collections of IP-based assets is coming to be known as the Internet 136 of Things (IOT). 138 In response to the accelerating threats, the security vendor 139 community have integrated their products with proprietary forms of 140 security reputation intelligence. This intelligence is about IP 141 addresses and domains which have been observed engaged in attack- 142 behaviours such as inappropriate messaging and traffic volumes, 143 domain management, Botnet command-and-control channel exchanges and 144 other indicators of either compromise or malicious intent. [REF 1] 145 IP address may also end up on a security reputation list if they are 146 identified as compromised through vendor-specific signature-based 147 processes. Security reputation intelligence from vendors is 148 typically made available to perimeter and end-point products through 149 proprietary, internet-based queries to vendor information bases. 151 This system of using proactive, security reputation intelligence has 152 many benefits, but also several weakness and scaling challenges. 153 Specifically, existing intelligence systems are: 154 1. subject to direct attack from the internet on distribution 155 points, for instance 156 2. are proprietary to vendor devices 157 3. require fat-clients consuming both bandwidth and CPU, and 158 4. introduces flow latency while queries are sent, received and 159 processed 160 5. introduces intelligence latency as reputation lists will be 161 inevitably cached and only periodically refreshed given the 162 number and range of vendor-specific processing elements 164 3.1. Packet Staining Benefits 166 In contrast to the challenges of current security reputation 167 intelligence systems, packet staining has the following strengths 168 1. packet staining can occur transparently in the network, 169 presenting no attack surface 171 2. packet staining uses standardized, public domain IPv6 172 capabilities 173 3. security rules can be easily applied in hardware or firmware 174 4. reading packet stains introduces little to no latency 175 5. near-real-time threat intelligence distribution systems can be 176 implemented can be implemented out of band in PMDs using a 177 standardized packet staining method allowing multiple 178 intelligence sources (vendor sources) to be aggregated and 179 applied in an agnostic (cross-vendor) manner. 181 3.2. Implementation and support models 183 Packet staining may be accomplished by different entities including 184 carriers, enterprises and third-party value-added service providers. 186 Carriers or service providers may elect to implement staining centres 187 at strategic locations in the network to provide value-added services 188 on a subscription basis. Under this model, subscribers to a security 189 staining service would see their traffic directed through a staining 190 centre where Destination Options are added to the IPv6 headers and 191 IPv4 traffic is encapsulated within IPv6 tunnels, with stained 192 headers. 194 Carriers or service providers may elect to stain all IPv6 traffic 195 entering their network, and allow subscribers to process the stains 196 at their own discretion. 198 If such upstream, network-based staining services are inappropriate 199 or unavailable, Enterprise data centre managers / cloud computing 200 service providers may elect to deploy IPv6 staining at the perimeter 201 into the internal network, tunnelling all IPv4 traffic, and allow 202 data centre/cloud service users to process stains at their 203 discretion. 205 Enterprise may wish to deploy IPv6 on internal networks, and stain 206 all internal traffic whereby security nodes and end-points may apply 207 corporate security policy related to reputation. 209 3.3. Use cases 211 The following are example use-cases for a security technique based 212 upon a packet staining system. 214 Organization Perimeter Use-case Traffic to a subscriber is routed 215 through a PMD in the carrier network configured to stain (apply 216 Destination Options extensions) all packets to the subscriber (TM)s 217 IP-range, which have entries in the threat intelligence information 218 base. The PMD accesses the information base from a locally cached 219 file or other method not defined in this draft. Packets from sources 220 not in the information base pass through the PDM unchanged. Packets 221 from sources in the information base have a Destinations Option added 222 to the datagram header. The Destination Options contains reputation 223 from the information base. The format of the destination option is 224 discussed later in this draft. IPv6 perimeter devices such as 225 firewalls, web proxies or security routers on the perimeter of the 226 subscriber network look for Destination Options on incoming packets 227 with reputation stains. If a stain is found, the perimeter device 228 applies the organization policy associated with the reputation 229 indicated by the stain. For instance, drop the packet, quarantine 230 the packet, issue alarms, or pass the packets and associated flow to 231 specially hardened extra-net authentication systems, or do nothing. 233 IPv4 support Use-case" IPv4 header fields and options are not 234 suitable for packet staining; however, there is a clear security 235 benefit to supporting IPv4 flows. IPv4 traffic to a subscriber is 236 routed through a PMD in the carrier network configured to encapsulate 237 the IPv4 traffic in an IPv6 tunnel. The PMD applies a stain 238 (Destination Options extension) to the IPv6 tunnel as per the 239 Perimeter Use-case above. Subscriber perimeter devices such as 240 firewalls, web proxies or security routers are configured to support 241 both native IPv6 flows and IPv6 tunnels contain legacy IPv4 flows. 242 Perimeter devices look for Destination Options on incoming IPv6 243 packets with reputation stains. If a stain is found, the perimeter 244 device applies the organization policy associated with the reputation 245 indicated by the stain to the IPv4 packet within the IPv6 tunnel. In 246 this manner IPv4 support may be transparent to end-users and 247 applications. 249 IPv6 end-point use-case" IPv6 end-points may make use of reputation 250 stains by processing Destination Options before engaging in any 251 application level processing. In the case of certain classes of 252 smart device, remote and mobile sensors, reputation stains may be a 253 critical form of security when other mitigations such as signature 254 bases and firewalls are too power and processor intensive to support. 256 URL-specific stains" it is a common occurrence to see large public 257 content portals with millions of users sharing dozens of addresses. 258 Frequently, malicious content will be loaded to such sites. This 259 content represents a very small fraction of the otherwise legitimate 260 content on the site, which may be under the direct control of 261 entirely separate entities . Degrading the reputation of IP 262 addresses used by these large portals based on a very small amount of 263 content is problematic. For such sites, reputation stains should 264 have the ability to include the URL of malicious content, such that 265 the reputation of the only specific portions of these large portals 266 is degraded according to threat evidence, rather than the entire IP 267 address, CIDR block, ASN or domain name. 269 4. Requirements for staining IPv6 packets 271 1. The default behaviour of a security node MUST be to leave a 272 packet unchanged (apply no stain). 273 2. Reputation stains may be inserted or overwritten by security 274 nodes in the path. 275 3. Reputation stains may not be applied by the sender/source of the 276 packet. 277 4. The reputation staining mechanism needs to be visible to all 278 stain-aware nodes on the path. 279 5. The mechanism needs to be able to traverse nodes that do not 280 understand the reputation stains. This is required to ensure 281 that packet-staining can be incrementally deployed over the 282 Internet. 283 6. The presence of the reputation staining mechanism should not 284 significantly alter the processing of the packet by nodes, unless 285 policy is explicitly configured. This is required to ensure that 286 stained packets do not face any undue delays or drops due to a 287 badly chosen mechanism. 288 7. A PMD should be able to distinguish a trusted stain from an 289 untrusted stain, through mechanism such as digital signatures or 290 intrinsic trust among network elements. 291 8. A staining node MAY apply more specific and selective staining 292 services according to subscriptions. Staining nodes SHOULD 293 support different reputation taxonomies to support different 294 subscribers and/or interoperability with other staining entities, 295 and have the ability to stain flows to different subscriber 296 sources according to different semantics. 297 9. Staining MUST NOT increase header size such that headers are 298 fragmented due to nodes supporting MTU smaller than the complete 299 header, once stained. Therefore staining should only be applied 300 within a domain of control where MTU is known and can be managed. 302 5. Packet Stain Destination Option (PSDO) 304 The Packet Stain Destination Option (PSDO) is a destination option 305 that can be included in IPv6 datagrams that are inserted by PMDs in 306 order to inform packet staining aware nodes on the path, or 307 endpoints, that the PSDO has an alignment requirement of (none). 309 0 1 2 3 310 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Option Type | Option Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |S|U| Stain Data | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 1: Packet Stain Destination Option Layout 319 Option Type 321 8-bit identifier of the type of option. The option identifier 322 for the reputation stain option will be allocated by the IANA. 324 Option Length 326 8-bit unsigned integer. The length of the option (excluding 327 the Option Type and Option Length fields). 329 S Bit 331 When this bit is set, the reputation stain option has been signed. 333 U Bit 335 When this bit is set, the reputation stain option contains a 336 malicious URL. 338 Stain Data 340 Contains the staining data. 342 6. Acknowledgements 344 The author wishes to achknowledge the guidance and support of Suresh 345 Krishnan from Ericsson's Montreal lab. The author also wishes to 346 credit Chris Mac-Stoker from NIKSUN for his substantial contributions 347 to the early stages of the packet staining concept. 349 7. Security Considerations 351 Some implementation may elect to no apply digital signature to 352 reputation stains in the Destination Option, in which case the stain 353 is not protected in any way, even if IPsec authentication [RFC4302] 354 is in use. Therefore an unsigned reputation stain can be forged by 355 an on-path attacker. Implementers are advised that any en-route 356 change to an unsigned security reputation stain value is 357 undetectable. Therefore packet staining use the Destination Options 358 extension without digital signatures requires intrinsic trust among 359 the network elements and the PMD, and the destination node or 360 intervening security nodes such as firewalls or IDS services. For 361 this reason, receiving nodes MAY need to take account of the network 362 from which the stained packet was received. For instance, a multi- 363 homed organization may have some service providers with staining 364 services and others that do not. A receiving node SHOULD be able to 365 distinguish which source from which stains are expected. A receiving 366 node SHOULD by default ignore any reputation stains from sources 367 (networks or devices) that have not been specifically configured as 368 trusted. 370 The reputation intelligence of IP source addresses, ASNs, CIDR blocks 371 and domains is fundamental to the application of reputation stains 372 within packet headers. Such reputation information can be seeded 373 from a variety of open and closed sources. Poorly managed or 374 compromised intelligence information bases can result in denial of 375 service against legitimate IP addresses, and allow malicious entities 376 to appear trustworthy. Intelligence information bases themselves may 377 be compromised in a variety of ways; for instance the raw information 378 feeds may be corrupted with erroneous information, alternately the 379 intelligence reputation algorithms could be flawed in design or 380 corrupted such that they generate false reputation scores. Therefore 381 seed intelligence SHOULD be sourced and monitored with demonstratable 382 diligence. Similarly, reputation algorithms should be protected from 383 unauthorized change with multi-layered access controls. 385 The value of reputation stains will be directly proportional to the 386 trustworthiness, reliability and reputation of the intelligence 387 source itself. Operators of security nodes SHOULD have defined and 388 auditable methods upon which they select and manage the source of 389 reputation intelligence and the packet staining infrastructure 390 itself. 392 8. IANA Considerations 394 This document defines a new IPv6 destination option for carrying 395 security reputation packet stains. IANA is requested to assign a new 396 destination option type (TBA1) in the Destination Options registry 397 maintained at http://www.iana.org/assignments/ipv6-parameters 1) 398 Signed Security Reputation Option, 2) Unsigned Security Reputation 399 Option 3) Signed Security Reputation Option with malicious URL 4) 400 Unsigned Security Reputation Option with malicious URL The act bits 401 for this option need to be 10 and the chg bit needs to be 0. 403 9. Normative References 405 [REF1] Macaulay, T., "Upstream Intelligence: anatomy, 406 architecture, case studies and use-cases.", Information 407 Assurance Newsletter, DOD , Aug to Feburary 2010 to 2011. 409 [REF2] Gont, F., "Security and Interoperability of Oversized IPv6 410 Header Chains", June 2012. 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, March 1997. 415 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 416 (IPv6) Specification", RFC 2460, December 1998. 418 Author's Address 420 Tyson Macaulay 421 McAfee Inc. 422 2821 Mission College Boulevard 423 Sanata Clara, California 424 U.S.A. 426 Email: tyson_macaulay@mcafee.com