idnits 2.17.1 draft-kline-default-perimeter-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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Home routers performing dynamic border discovery MUST continuously evaluate the interior and exterior classifications of interfaces. These may change at any time, for example if new devices are added into the network or a power event causes all equipment to reset, and specific ordering of device bring-up within a homenet network MAY NOT be assumed. -- The document date (November 6, 2012) is 4161 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Home Networking E. Kline 3 Internet-Draft Google Japan 4 Intended status: Informational November 6, 2012 5 Expires: May 10, 2013 7 Default Border Definition 8 draft-kline-default-perimeter-01 10 Abstract 12 Automatic, simple identification of when traffic is crossing a 13 perimeter is highly desirable for a variety of home network uses. 14 This document describes how to use homenet routing protocol 15 adjacencies as the primary signal of a common administrative domain 16 (e.g. "the home"). Classification of interfaces et cetera as 17 internal or external follow from this, as do various policy and 18 implementation implications. One fundamental implication is that the 19 active definition of a home network's interior is no more secure than 20 its policy for forming homenet routing protocol adjacencies. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 10, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Dynamically determining the border . . . . . . . . . . . . . . 4 60 3.1. Collect information about neighboring routers . . . . . . 5 61 3.2. Classify next hops . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Classify interfaces . . . . . . . . . . . . . . . . . . . 6 63 3.3.1. Mixed mode . . . . . . . . . . . . . . . . . . . . . . 6 64 3.4. State changes and logging . . . . . . . . . . . . . . . . 6 65 4. Fixed-category interfaces . . . . . . . . . . . . . . . . . . 6 66 4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 5.1. Disclamatory remarks . . . . . . . . . . . . . . . . . . . 7 69 5.2. Security of adjacency formation . . . . . . . . . . . . . 8 70 5.2.1. Secure links and authenticated adjacency formation . . 8 71 5.2.2. Unsecure links . . . . . . . . . . . . . . . . . . . . 8 72 5.2.3. Recommendations . . . . . . . . . . . . . . . . . . . 9 73 5.3. Example border-aware filtering policies . . . . . . . . . 9 74 5.3.1. Anti-spoofing on internal interfaces . . . . . . . . . 9 75 5.3.2. Stateful filtering on external interfaces . . . . . . 10 76 5.3.3. Mixed-mode interface filtering . . . . . . . . . . . . 10 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 Automatic, simple identification of when traffic is crossing the 87 homenet perimeter is highly desirable for a variety of home network 88 uses. This is a non-trivial task as it is tantamount to automated 89 discovery of administrative boundaries. 91 Many architectures make it difficult or impossible (by design) to 92 detect administrative boundaries and rely on various mechanisms of 93 user or administrator invention to create or modify such boundaries. 94 Other hints about administrative boundaries can be insecure, 95 unreliable, operationally impractical, or may place arbitrary 96 requirements upon the architecture where previously no such 97 requirement existed. 99 This document describes how to use homenet routing protocol 100 adjacencies as the primary signal of a common administrative domain 101 (e.g. "the home"). Classification of interfaces et cetera as 102 internal or external follow from this, as do various policy and 103 implementation implications. One fundamental implication is that the 104 active definition of a home network's interior is no more secure than 105 its policy for forming homenet routing protocol adjacencies. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Terminology 115 In order to address border determination at a manageable scale the 116 scope has been limited to discussing concepts of "interior", 117 "exterior", and "border". Documents may reference any of the terms 118 "internal", "interior", "external", or "exterior" as required by 119 grammar (adjective versus noun use cases). Definitions in use by 120 this document are as follows. 122 Internal/Interior 124 The interior is broadly defined to include the collection of 125 interfaces (physical or virtual), nodes, and forwarding next hops 126 collectively under the control of a single logical administrative 127 domain. This document uses the homenet routing protocol 128 adjacencies as a indicator of membership in the same logical 129 administrative domain. 131 External/Exterior 133 The exterior is broadly defined to include all interfaces 134 (physical or virtual), nodes, and forwarding next hops 135 collectively NOT under the control of any single logical 136 administrative domain and specifically NOT under the control of 137 the administrative domain which defines the interior. 139 Border/Perimeter 141 The border is taken to be the collection of all ephemeral 142 demarcations within the collection of interior nodes which 143 forward traffic such that any IP packet transiting that 144 demarcation can be said to be crossing either from the interior 145 toward the exterior or from the exterior toward the interior. 146 This is independent of whether or not such traffic is permitted 147 by policy to complete its transiting from one zone to the other. 149 Additionally, some implementations MAY choose to support handling 150 questionable home network configurations which result in an interface 151 qualifying for both interior and exterior classification 152 simultaneously. Requirements for this are discussed further below. 154 Expressly not considered by this document are architectures having 155 multiple interior networks, nor the relationships between them as 156 separate from their relationship to their common exterior or any 157 common border (e.g. a hierarchy of internal networks). This document 158 is solely concerned with a single interior, a single exterior, and a 159 single logical perimeter between the two. 161 3. Dynamically determining the border 163 Homenet routers may support interfaces which attempt to learn the 164 nature of their relationship to neighboring routers, and determine 165 where the border between the "interior" and the "exterior" lies. 167 Interfaces which have not yet determined their categorization may 168 consider themselves to be in a "learning" state, where no traffic is 169 routed but probing continues. Once nodes of any kind (e.g. either 170 routers or hosts) are detected, classification takes place and the 171 router exits the "learning" state. 173 The classification algorithm documented here is roughly: 175 1. Continously collect information on all interfaces about 176 neighboring routers (including manually configured routers). 178 2. Classify next hops as either "internal" or "external" primarily 179 by homenet router protocol adjacency status. 181 3. Classify interfaces according to the nature of their next hops. 183 Manually configured next hops MUST also have their classification as 184 either "internal" or "external" explicitly specified. As such, they 185 can be considered to be of a fixed category, and on-going evaluation 186 is NOT required. 188 Policies of various sorts can be applied and updated as appropriate 189 based on these classifications, as and when they are determined. 191 3.1. Collect information about neighboring routers 193 An interface (physical or virtual) which is configured to dynamically 194 assess its internal or external classification MUST periodically 195 probe for routing information on the link. This includes sending 196 Router Solicitations, DHCPv6 Prefix Delegation requests, and probing 197 for homenet routing protocol-capable nodes. 199 Probing for routing information MUST be performed whenever the 200 interface is logically up. The periodicity of probes is protocol- 201 dependent (e.g. subject to Router Advertisement lifetimes, DHCPv6 202 lease timers, or homenet routing protocol timers). Wherever 203 possible, implementations SHOULD limit the impact of probing by 204 implementing mechanisms like exponential back-off. 206 Homenet routers MUST be able to identify loops, e.g. when two (or 207 more) of the router's own interfaces are connected on the same link. 208 Compliant routers MUST administratively log this misconfiguration, 209 and SHOULD implement a mechanism that permits maximum continued 210 homenet functionality if possible. For example, implementations MAY 211 administratively disable all but one of looped interfaces. 213 3.2. Classify next hops 215 Routing information is used to categorize next hops as either 216 "internal" or "external". 218 Routers with which a homenet routing protocol adjacency is 219 successfully established MUST be considered "internal". 221 Routers of which this homenet router has knowledge but with which no 222 homenet routing protocol adjacency is successfully establish AND from 223 which no routing information is learned SHOULD be considered 224 "internal". This includes "downstream" routers for which the homenet 225 router is acting as the Delegating Router via a DHCPv6 Prefix 226 Delegation exchange. 228 All other routers with which no homenet routing protocol adjacency is 229 successfully established MUST be considered "external". 231 3.3. Classify interfaces 233 An interface with no "external" next hops SHOULD be categorized as 234 "internal". This includes interfaces serving leaf networks 235 consisting only of hosts, an interface which has "downstream" routers 236 for which this router is a Delegating Router, an interface with only 237 homenet routing protocol adjacent peers, or any combination thereof. 239 An interface with next hops all of which are categorized as 240 "external" MUST be categorized as "external". 242 3.3.1. Mixed mode 244 Some devices MAY choose to support handling questionable home network 245 configurations which result in an interface having both interior and 246 exterior next hops simultaneously. This can happen if, for example, 247 two homenet routers form an adjacency with each other over the same 248 interface they use for communicating to "upstream" ISP routers. 250 All homenet routers, whether this configuration is considered 251 supported or not, MUST administratively log and provide product- 252 relevant notification of this configuration, preferably with 253 recommendations for resolution. 255 3.4. State changes and logging 257 Home routers performing dynamic border discovery MUST continuously 258 evaluate the interior and exterior classifications of interfaces. 259 These may change at any time, for example if new devices are added 260 into the network or a power event causes all equipment to reset, and 261 specific ordering of device bring-up within a homenet network MAY NOT 262 be assumed. 264 Homenet routers performing dynamic border discovery SHOULD 265 administratively log the perimeter classification of all interfaces 266 (physical and virtual), the reason(s) for such classification, and 267 times at which such classifications are made or changed. 269 4. Fixed-category interfaces 271 Interfaces (physical or virtual) which have product-defined purposes 272 or are otherwise permanently categorized by the homenet router 273 implementation as exclusively "internal" or exclusively "external" do 274 not require any algorithm to determine their categorization. 276 Homenet routers MUST restrict relevant traffic on fixed-category 277 interfaces according to their categorizations. Specifically, they 278 MUST NOT originate traffic which could result in re-categorizing the 279 interface IF the interface were dynamically attempting to learn its 280 categorization. For example, a fixed "external" interface MUST NOT 281 attempt to participate in the homenet routing protocol. Similarly, 282 fixed "internal" interfaces must not issue DHCPv6 Prefix Delegation 283 requests. 285 4.1. Examples 287 Examples of product-defined interfaces include home router interfaces 288 which are labeled for their intended use, e.g. RJ-45 ports labeled 289 "WAN" and "LAN" or symbols indicating "The Internet" and "inside the 290 home". Other examples include wireless routers with defined separate 291 WLAN "home" and "guest" ESSIDs. 293 Another set of examples of product-defined, fixed category interfaces 294 are those which require subscriber credentials in order for that 295 interface to successfully pass general purpose traffic. These 296 include authenticated PPPoE sessions and 3G/LTE PDP contexts (e.g. 297 requiring a SIM card associated with a valid customer account). 298 These SHOULD be classified as "exterior". 300 Similarly, an implementation may consider the interface a mobile 301 device uses to provide service to "tethering" clients to be a fixed- 302 category interface. Such interfaces SHOULD be classified as 303 "interior". 305 5. Security Considerations 307 A key motivation for border identification is the application of 308 security policies which can take into account classifications of 309 interior, exterior, and the transition from one the other. General 310 remarks, comments on the security of the adjacencies which form the 311 basis of border identification, and examples of potential policies 312 which might be applied follow. 314 5.1. Disclamatory remarks 316 By default all network nodes SHOULD follow best current security 317 practices. Any node may at times find itself in a hostile 318 environment. This is obviously true of mobile nodes, for example, 319 when connecting to any public "Wi-Fi" network. This is, of course, 320 equally true of more traditionally "fixed" nodes. Any compromised 321 neighbor node ("fixed" or mobile) may be used as a conduit for 322 further compromise. Indeed, one study of a captured "botnet" 323 ([TORPIG], section 5.2.4) found that roughly 78.9% of infected hosts 324 had RFC 1918 [RFC1918] addresses, commonly used in IPv4 NAT 325 deployments. 327 Though it goes without saying, at all times homenet implementers MUST 328 remain mindful of best current security practices, including but not 329 limited to RFC 4864 [RFC4864], RFC 4890 [RFC4890], RFC 6092 330 [RFC6092], and others. 332 5.2. Security of adjacency formation 334 The security of the border definition is limited by the security 335 applied to the formation of homenet routing protocol adjacencies: the 336 next hops with which a homenet router forms adjacencies are the next 337 hops the router trusts with the application of interior policies. 339 5.2.1. Secure links and authenticated adjacency formation 341 The trustworthiness of next hops during adjacency formation can be 342 improved if the security of the link connecting them can be trusted. 343 Using encrypted link technologies like 802.1x or secured "Wi-Fi" 344 ESSIDS when forming homenet adjacencies, or authenticating homenet 345 next hops by physical or cryptographic mechanisms limits the ability 346 of malicious nodes to join the homenet interior. 348 5.2.2. Unsecure links 350 In general IP over Ethernet connections, common to residential 351 Internet (and countless other places like some in-room hotel network) 352 service provider deployments, create the possibility of malicious 353 nodes attempting to join the homenet interior. 355 In a broad variety of circumstances users already implicitly trust 356 unsecured links. Residential subscribers generally trust that their 357 ISP has properly isolated their connection from any neighbors; few if 358 any subscribers validate the ISP's DHCP server in order to thwart a 359 malicious neighbor intervening. 361 In the event of a network with a single upstream where an interior 362 next hop is formed instead of an external next hop, the homenet 363 network as a whole would have detected no external next hops. 364 Homenet router networks in which there are no external next hops 365 SHOULD administratively log this configuration and SHOULD provide a 366 means to alert the user to this condition. Note that for isolated 367 networks of homenet routers (e.g. a lab network) this configuration 368 is entirely valid. 370 User notification alone is not sufficient protection for the homenet 371 user, and will not correctly alert the user of a homenet with two 372 upstream connections, one of which has mistakenly not categorized a 373 next hop as external. To better serve the homenet user, homenet 374 routers are SHOULD follow one or more of the recommendations in 375 Section 5.2.3. 377 5.2.3. Recommendations 379 Homenet router implementations that support dynamic discovery of the 380 border (i.e. have interfaces on which the dynamic border detection 381 described in Section 3 can be configured to operate) SHOULD support 382 restricting homenet routing protocol adjacency formation to only next 383 hops which meet some user-defined or user-verified authentication 384 mechanism (including examples described in Section 5.2.1). 386 Alternatively, implementations MAY incorporate a mechanism (possibly 387 physical) whereby a homenet user can disable border detection on an 388 interface which the user wishes to force into either an interior or 389 exterior classification (e.g. a button to force an interface to be 390 "external" only). 392 5.3. Example border-aware filtering policies 394 As a homenet router forms adjacencies and learns internal aggregate 395 prefixes it could dynamically maintain a single logical entity 396 encompassing all current internal prefixes in use that can be treated 397 as a whole (e.g. an access list). Below are example filtering 398 policies that might be applied by homenet routers with knowledge of 399 both this prefix set and the interior or exterior classification of 400 all interfaces. 402 The examples below use the string "{interior_nets}" for refer to the 403 grouping of all internal aggregate prefixes. The sample filtering 404 policy rules are written in configuration pseudo-syntax that should 405 hopefully be intuitive. 407 5.3.1. Anti-spoofing on internal interfaces 409 Given knowledge of all interior network prefixes and the 410 categorization of interfaces, all interior interfaces could apply a 411 stateless filter designed to prevent devices in the home from 412 originating source-address-spoofed traffic. 414 Using a filter configuration pseudo-syntax: 416 from !{interior_nets} to !{interior_nets} deny 417 ... # permit or deny other kinds of traffic 419 5.3.2. Stateful filtering on external interfaces 421 Given knowledge of all interior network prefixes and the 422 categorization of interfaces, all exterior interfaces could apply a 423 stateful filter designed to discard traffic without matching state in 424 the homenet router. 426 Using a filter configuration pseudo-syntax: 428 ... # permit other kinds of good traffic first 429 from {interior_nets} to !{interior_nets} permit 430 from !{interior_nets} to {interior_nets} established permit 431 from any to any deny 433 5.3.3. Mixed-mode interface filtering 435 Given knowledge of all interior network prefixes and the 436 categorization of interfaces, all mixed-node interfaces could apply a 437 stateful filter designed to discard exterior traffic without matching 438 state in the homenet router and still statelessly permit internal 439 traffic. 441 Using a filter configuration pseudo-syntax: 443 ... # permit other kinds of good traffic first 444 from {interior_nets} to !{interior_nets} permit 445 from !{interior_nets} to {interior_nets} established permit 446 from {interior_nets} to {interior_nets} permit 447 from any to any deny 449 Because routing changes elsewhere in the home may cause traffic to 450 shift among interior next hops which may not have state, traffic 451 between interior routers may not be well-served by stateful 452 filtering. One consequence for this policy on mixed-mode interfaces 453 is that traffic from the exterior with spoofed source addresses from 454 the "{interior_nets}" set of prefixes may be mistakenly allowed into 455 the home. 457 Filter implementations which can incorporate knowledge of the 458 previous and next hops and their classifications can design much more 459 precise filters. Such implementations could deny traffic with 460 "{interior_nets}" source addresses arriving from an exterior next 461 hop, but permit them from an interior next hop on the same mixed-mode 462 interface. 464 6. Acknowledgements 466 Many thanks for the constructive input and criticism of Shwetha 467 Bhandari, Lorenzo Colitti, Markus Stenberg, Mark Townsley, and Ole 468 Troan. 470 Thanks also must go to pleasant, peaceful and productive trips on the 471 Japan Rail (JR) Shinkansen ("bullet train"). 473 7. IANA Considerations 475 This memo includes no request to IANA. 477 8. References 479 8.1. Normative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 8.2. Informative References 486 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 487 E. Lear, "Address Allocation for Private Internets", 488 BCP 5, RFC 1918, February 1996. 490 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 491 E. Klein, "Local Network Protection for IPv6", RFC 4864, 492 May 2007. 494 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 495 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 497 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 498 Customer Premises Equipment (CPE) for Providing 499 Residential IPv6 Internet Service", RFC 6092, 500 January 2011. 502 [TORPIG] Stone-Gross, B., "Your Botnet is My Botnet: Analysis of a 503 Botnet Takeover", 2009, . 506 Author's Address 508 Erik Kline 509 Google Japan 510 Roppongi 6-10-1, 26th Floor 511 Minato, Tokyo 106-6126 512 JP 514 Phone: +81 03 6384 9000 515 Email: ek@google.com