idnits 2.17.00 (12 Aug 2021) /tmp/idnits37876/draft-kline-homenet-default-perimeter-00.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 12, 2013) is 3350 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 March 12, 2013 5 Expires: September 13, 2013 7 Default Border Definition 8 draft-kline-homenet-default-perimeter-00 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 September 13, 2013. 39 Copyright Notice 41 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . 7 66 4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 5.1. Disclamatory remarks . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . 10 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 intervention to create or modify such 94 boundaries. Other hints about administrative boundaries can be 95 insecure, unreliable, operationally impractical, or may place 96 arbitrary 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 is performed. Once nodes of any kind (e.g. either 170 routers or hosts) are detected, classification takes place and the 171 interface 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 SHOULD also have their classification 184 as either "internal" or "external" explicitly specified. As such, 185 they can be considered to be of a fixed category, and on-going 186 evaluation is NOT required. If no "interior"/"exterior" 187 classification is specified the next hop MUST by default be 188 classified as "exterior". 190 Numerous policies can be applied and updated as appropriate based on 191 these classifications, as and when they are determined. Further 192 discussion of policy recommendations (except by example) is outside 193 the scope of this document. 195 3.1. Collect information about neighboring routers 197 An interface (physical or virtual) which is configured to dynamically 198 assess its internal or external classification MUST periodically 199 probe for routing information on the link. This includes sending 200 Router Solicitations, DHCPv6 Prefix Delegation requests (or Renew 201 requests), and probing for homenet routing protocol-capable nodes. 203 Probing for routing information MUST be performed whenever the 204 interface is logically up. The periodicity of probes is protocol- 205 dependent (e.g. subject to Router Advertisement lifetimes, DHCPv6 206 lease timers, or homenet routing protocol timers). Wherever 207 possible, implementations SHOULD limit the impact of probing by 208 implementing mechanisms like exponential back-off. 210 Homenet routers MUST be able to identify when two (or more) of the 211 router's interfaces are connected on to the same link, e.g. by 212 observing unique properties of a probe by which it can recognize 213 itself. Compliant routers MUST administratively log this 214 configuration, and SHOULD implement a mechanism that permits maximum 215 continued homenet functionality if possible. For example, 216 implementations MAY administratively disable all but one of the 217 interfaces in question or MAY treat the collection of interfaces as a 218 single logical interface in a manner suitable to the link type. 220 3.2. Classify next hops 222 Routing information is used to categorize next hops as either 223 "internal" or "external". 225 Routers with which a homenet routing protocol adjacency is 226 successfully established MUST be considered "internal". 228 Routers of which this homenet router has knowledge but with which no 229 homenet routing protocol adjacency is successfully establish AND from 230 which no routing information is learned SHOULD be considered 231 "internal". This includes "downstream" routers for which the homenet 232 router may be acting as the Delegating Router via a DHCPv6 Prefix 233 Delegation exchange but which do not implement the homenet routing 234 protocol. 236 All other routers with which no homenet routing protocol adjacency is 237 successfully established MUST be considered "external". 239 3.3. Classify interfaces 241 An interface with no "external" next hops SHOULD be categorized as 242 "internal". This includes interfaces serving leaf networks 243 consisting only of hosts, an interface which has "downstream" routers 244 for which this router is a Delegating Router, an interface with only 245 homenet routing protocol adjacent peers, or any combination thereof. 247 An interface with next hops all of which are categorized as 248 "external" MUST be categorized as "external". 250 3.3.1. Mixed mode 252 Some devices MAY choose to support handling questionable home network 253 configurations which result in an interface having both interior and 254 exterior next hops simultaneously. This can happen if, for example, 255 two homenet routers form an adjacency with each other over the same 256 interface they use for communicating to "upstream" ISP routers. 258 A homenet router by default SHOULD classify such "mixed mode" 259 interfaces as "external". Transmitting "internal" communications 260 over interfaces with "external" nodes is NOT RECOMMENDED. 262 All homenet routers, whether this configuration is considered 263 supported or not, MUST administratively log and provide product- 264 relevant notification of this configuration, preferably with 265 recommendations for resolution. 267 3.4. State changes and logging 269 Home routers performing dynamic border discovery MUST continuously 270 evaluate the interior and exterior classifications of interfaces. 271 These may change at any time, for example if new devices are added 272 into the network or a power event causes all equipment to reset, and 273 specific ordering of device bring-up within a homenet network MUST 274 NOT be assumed. 276 Homenet routers performing dynamic border discovery SHOULD 277 administratively log the perimeter classification of all interfaces 278 (physical and virtual), the reason(s) for such classification, and 279 times at which such classifications are made or changed. 281 4. Fixed-category interfaces 283 Interfaces (physical or virtual) which have product-defined purposes 284 or are otherwise permanently categorized by the homenet router 285 implementation as exclusively "internal" or exclusively "external" do 286 not require any algorithm to determine their categorization. 288 Homenet routers MUST restrict relevant traffic on fixed-category 289 interfaces according to their categorizations. Specifically, they 290 MUST NOT originate traffic which could result in re-categorizing the 291 interface IF the interface were dynamically attempting to learn its 292 categorization. For example, a fixed "external" interface MUST NOT 293 attempt to participate in the homenet routing protocol. Similarly, 294 fixed "internal" interfaces must not issue DHCPv6 Prefix Delegation 295 requests. 297 4.1. Examples 299 Examples of product-defined interfaces include home router interfaces 300 which are labeled for their intended use, e.g. RJ-45 ports labeled 301 "WAN" and "LAN" or symbols indicating "The Internet" and "inside the 302 home". Other examples include wireless routers with defined separate 303 WLAN "home" and "guest" ESSIDs. 305 Another set of examples of product-defined, fixed category interfaces 306 are those which require subscriber credentials in order for that 307 interface to successfully pass general purpose traffic. These 308 include authenticated PPPoE sessions and 3G/LTE PDP contexts (e.g. 309 requiring a SIM card associated with a valid customer account). 310 These SHOULD be classified as "exterior". 312 Similarly, an implementation may consider the interface a mobile 313 device uses to provide service to "tethering" clients to be a fixed- 314 category interface. Such interfaces SHOULD be classified as 315 "interior". 317 5. Security Considerations 319 A key motivation for border identification is the application of 320 security policies which can take into account classifications of 321 interior, exterior, and the transition from one the other. General 322 remarks, comments on the security of the adjacencies which form the 323 basis of border identification, and examples of potential policies 324 which might be applied follow. 326 5.1. Disclamatory remarks 328 By default all network nodes SHOULD follow best current security 329 practices. Any node may at times find itself in a hostile 330 environment. This is obviously true of mobile nodes, for example, 331 when connecting to any public "Wi-Fi" network. This is, of course, 332 equally true of more traditionally "fixed" nodes. Any compromised 333 neighbor node ("fixed" or mobile) may be used as a conduit for 334 further compromise. Indeed, one study of a captured "botnet" 335 ([TORPIG], section 5.2.4) found that roughly 78.9% of infected hosts 336 had RFC 1918 [RFC1918] addresses, commonly used in IPv4 NAT 337 deployments. 339 Though it goes without saying, at all times homenet implementers MUST 340 remain mindful of best current security practices, including but not 341 limited to RFC 4864 [RFC4864], RFC 4890 [RFC4890], RFC 6092 342 [RFC6092], and others. 344 5.2. Security of adjacency formation 346 The security of the border definition is limited by the security 347 applied to the formation of homenet routing protocol adjacencies: the 348 next hops with which a homenet router forms adjacencies are the next 349 hops the router trusts with the application of interior policies. 351 5.2.1. Secure links and authenticated adjacency formation 353 The trustworthiness of next hops during adjacency formation can be 354 improved if the security of the link connecting them can be trusted. 355 Using encrypted link technologies like 802.1x or secured "Wi-Fi" 356 ESSIDS when forming homenet adjacencies, or authenticating homenet 357 next hops by physical or cryptographic mechanisms limits the ability 358 of malicious nodes to join the homenet interior. 360 5.2.2. Unsecure links 362 In general IP over Ethernet connections, common to residential 363 Internet (and countless other places like some in-room hotel network) 364 service provider deployments, create the possibility of malicious 365 nodes attempting to join the homenet interior. 367 In a broad variety of circumstances users already implicitly trust 368 unsecured links. Residential subscribers generally trust that their 369 ISP has properly isolated their connection from any neighbors; few if 370 any subscribers validate the ISP's DHCP server in order to thwart a 371 malicious neighbor intervening. 373 In the event of a network with a single upstream where an interior 374 next hop is formed instead of an external next hop, the homenet 375 network as a whole would have detected no external next hops. 376 Homenet router networks in which there are no external next hops 377 SHOULD administratively log this configuration and SHOULD provide a 378 means to alert the user to this condition. Note that for isolated 379 networks of homenet routers (e.g. a lab network) this configuration 380 is entirely valid. 382 User notification alone is not sufficient protection for the homenet 383 user, and will not correctly alert the user of a homenet with two 384 upstream connections, one of which has mistakenly not categorized a 385 next hop as external. To better serve the homenet user, homenet 386 routers are SHOULD follow one or more of the recommendations in 387 Section 5.2.3. 389 5.2.3. Recommendations 391 Homenet router implementations that support dynamic discovery of the 392 border (i.e. have interfaces on which the dynamic border detection 393 described in Section 3 can be configured to operate) SHOULD support 394 restricting homenet routing protocol adjacency formation to only next 395 hops which meet some user-defined or user-verified authentication 396 mechanism (including examples described in Section 5.2.1). 398 Alternatively, implementations MAY incorporate a mechanism (possibly 399 physical) whereby a homenet user can disable border detection on an 400 interface which the user wishes to force into either an interior or 401 exterior classification (e.g. a button to force an interface to be 402 "external" only). 404 5.3. Example border-aware filtering policies 406 As a homenet router forms adjacencies and learns internal aggregate 407 prefixes it could dynamically maintain a single logical entity 408 encompassing all current internal prefixes in use that can be treated 409 as a whole (i.e. an access list). Below are example filtering 410 policies that might be applied by homenet routers with knowledge of 411 both this prefix set and the interior or exterior classification of 412 all interfaces. 414 The examples below use the string "{interior_nets}" for refer to the 415 grouping of all internal aggregate prefixes. The sample filtering 416 policy rules are written in configuration pseudo-syntax that should 417 hopefully be intuitive. 419 5.3.1. Anti-spoofing on internal interfaces 421 Given knowledge of all interior network prefixes and the 422 categorization of interfaces, all interior interfaces could apply a 423 stateless filter designed to prevent devices in the home from 424 originating source-address-spoofed traffic. 426 Using a filter configuration pseudo-syntax: 428 from !{interior_nets} to !{interior_nets} deny 429 ... # permit or deny other kinds of traffic 431 5.3.2. Stateful filtering on external interfaces 433 Given knowledge of all interior network prefixes and the 434 categorization of interfaces, all exterior interfaces could apply a 435 stateful filter designed to discard traffic without matching state in 436 the homenet router. 438 Using a filter configuration pseudo-syntax: 440 ... # permit other kinds of good traffic first 441 from {interior_nets} to !{interior_nets} permit 442 from !{interior_nets} to {interior_nets} established permit 443 from any to any deny 445 5.3.3. Mixed-mode interface filtering 447 Given knowledge of all interior network prefixes and the 448 categorization of interfaces, all mixed-node interfaces could apply a 449 stateful filter designed to discard exterior traffic without matching 450 state in the homenet router and still statelessly permit internal 451 traffic. 453 Using a filter configuration pseudo-syntax: 455 ... # permit other kinds of good traffic first 456 from {interior_nets} to !{interior_nets} permit 457 from !{interior_nets} to {interior_nets} established permit 458 from {interior_nets} to {interior_nets} permit 459 from any to any deny 461 Because routing changes elsewhere in the home may cause traffic to 462 shift among interior next hops which may not have state, traffic 463 between interior routers may not be well-served by stateful 464 filtering. One consequence for this policy on mixed-mode interfaces 465 is that traffic from the exterior with spoofed source addresses from 466 the "{interior_nets}" set of prefixes may be mistakenly allowed into 467 the home. 469 Filter implementations which can incorporate knowledge of the 470 previous and next hops and their classifications can design much more 471 precise filters. Such implementations could deny traffic with 472 "{interior_nets}" source addresses arriving from an exterior next 473 hop, but permit them from an interior next hop on the same mixed-mode 474 interface. 476 6. Acknowledgements 478 Many thanks for the constructive input and criticism of Shwetha 479 Bhandari, Lorenzo Colitti, Markus Stenberg, Mark Townsley, and Ole 480 Troan. 482 Thanks also must go to pleasant, peaceful and productive trips on the 483 Japan Rail (JR) Shinkansen ("bullet train"). 485 7. IANA Considerations 487 This memo includes no request to IANA. 489 8. References 491 8.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 8.2. Informative References 498 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 499 E. Lear, "Address Allocation for Private Internets", 500 BCP 5, RFC 1918, February 1996. 502 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 503 E. Klein, "Local Network Protection for IPv6", RFC 4864, 504 May 2007. 506 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 507 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 509 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 510 Customer Premises Equipment (CPE) for Providing 511 Residential IPv6 Internet Service", RFC 6092, 512 January 2011. 514 [TORPIG] Stone-Gross, B., "Your Botnet is My Botnet: Analysis of a 515 Botnet Takeover", 2009, . 518 Author's Address 520 Erik Kline 521 Google Japan 522 Roppongi 6-10-1, 26th Floor 523 Minato, Tokyo 106-6126 524 JP 526 Phone: +81 03 6384 9000 527 Email: ek@google.com