Home Networking E. Kline Internet-Draft Google Japan Intended status: Informational March 12, 2013 Expires: September 13, 2013 Default Border Definition draft-kline-homenet-default-perimeter-00 Abstract Automatic, simple identification of when traffic is crossing a perimeter is highly desirable for a variety of home network uses. This document describes how to use homenet routing protocol adjacencies as the primary signal of a common administrative domain (e.g. "the home"). Classification of interfaces et cetera as internal or external follow from this, as do various policy and implementation implications. One fundamental implication is that the active definition of a home network's interior is no more secure than its policy for forming homenet routing protocol adjacencies. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 13, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Kline Expires September 13, 2013 [Page 1] Internet-Draft Default Border Definition March 2013 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Dynamically determining the border . . . . . . . . . . . . . . 4 3.1. Collect information about neighboring routers . . . . . . 5 3.2. Classify next hops . . . . . . . . . . . . . . . . . . . . 5 3.3. Classify interfaces . . . . . . . . . . . . . . . . . . . 6 3.3.1. Mixed mode . . . . . . . . . . . . . . . . . . . . . . 6 3.4. State changes and logging . . . . . . . . . . . . . . . . 6 4. Fixed-category interfaces . . . . . . . . . . . . . . . . . . 7 4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.1. Disclamatory remarks . . . . . . . . . . . . . . . . . . . 8 5.2. Security of adjacency formation . . . . . . . . . . . . . 8 5.2.1. Secure links and authenticated adjacency formation . . 8 5.2.2. Unsecure links . . . . . . . . . . . . . . . . . . . . 8 5.2.3. Recommendations . . . . . . . . . . . . . . . . . . . 9 5.3. Example border-aware filtering policies . . . . . . . . . 9 5.3.1. Anti-spoofing on internal interfaces . . . . . . . . . 10 5.3.2. Stateful filtering on external interfaces . . . . . . 10 5.3.3. Mixed-mode interface filtering . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Kline Expires September 13, 2013 [Page 2] Internet-Draft Default Border Definition March 2013 1. Introduction Automatic, simple identification of when traffic is crossing the homenet perimeter is highly desirable for a variety of home network uses. This is a non-trivial task as it is tantamount to automated discovery of administrative boundaries. Many architectures make it difficult or impossible (by design) to detect administrative boundaries and rely on various mechanisms of user or administrator intervention to create or modify such boundaries. Other hints about administrative boundaries can be insecure, unreliable, operationally impractical, or may place arbitrary requirements upon the architecture where previously no such requirement existed. This document describes how to use homenet routing protocol adjacencies as the primary signal of a common administrative domain (e.g. "the home"). Classification of interfaces et cetera as internal or external follow from this, as do various policy and implementation implications. One fundamental implication is that the active definition of a home network's interior is no more secure than its policy for forming homenet routing protocol adjacencies. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology In order to address border determination at a manageable scale the scope has been limited to discussing concepts of "interior", "exterior", and "border". Documents may reference any of the terms "internal", "interior", "external", or "exterior" as required by grammar (adjective versus noun use cases). Definitions in use by this document are as follows. Internal/Interior The interior is broadly defined to include the collection of interfaces (physical or virtual), nodes, and forwarding next hops collectively under the control of a single logical administrative domain. This document uses the homenet routing protocol adjacencies as a indicator of membership in the same logical administrative domain. Kline Expires September 13, 2013 [Page 3] Internet-Draft Default Border Definition March 2013 External/Exterior The exterior is broadly defined to include all interfaces (physical or virtual), nodes, and forwarding next hops collectively NOT under the control of any single logical administrative domain and specifically NOT under the control of the administrative domain which defines the interior. Border/Perimeter The border is taken to be the collection of all ephemeral demarcations within the collection of interior nodes which forward traffic such that any IP packet transiting that demarcation can be said to be crossing either from the interior toward the exterior or from the exterior toward the interior. This is independent of whether or not such traffic is permitted by policy to complete its transiting from one zone to the other. Additionally, some implementations MAY choose to support handling questionable home network configurations which result in an interface qualifying for both interior and exterior classification simultaneously. Requirements for this are discussed further below. Expressly not considered by this document are architectures having multiple interior networks, nor the relationships between them as separate from their relationship to their common exterior or any common border (e.g. a hierarchy of internal networks). This document is solely concerned with a single interior, a single exterior, and a single logical perimeter between the two. 3. Dynamically determining the border Homenet routers may support interfaces which attempt to learn the nature of their relationship to neighboring routers, and determine where the border between the "interior" and the "exterior" lies. Interfaces which have not yet determined their categorization may consider themselves to be in a "learning" state, where no traffic is routed but probing is performed. Once nodes of any kind (e.g. either routers or hosts) are detected, classification takes place and the interface exits the "learning" state. The classification algorithm documented here is roughly: 1. Continously collect information on all interfaces about neighboring routers (including manually configured routers). Kline Expires September 13, 2013 [Page 4] Internet-Draft Default Border Definition March 2013 2. Classify next hops as either "internal" or "external" primarily by homenet router protocol adjacency status. 3. Classify interfaces according to the nature of their next hops. Manually configured next hops SHOULD also have their classification as either "internal" or "external" explicitly specified. As such, they can be considered to be of a fixed category, and on-going evaluation is NOT required. If no "interior"/"exterior" classification is specified the next hop MUST by default be classified as "exterior". Numerous policies can be applied and updated as appropriate based on these classifications, as and when they are determined. Further discussion of policy recommendations (except by example) is outside the scope of this document. 3.1. Collect information about neighboring routers An interface (physical or virtual) which is configured to dynamically assess its internal or external classification MUST periodically probe for routing information on the link. This includes sending Router Solicitations, DHCPv6 Prefix Delegation requests (or Renew requests), and probing for homenet routing protocol-capable nodes. Probing for routing information MUST be performed whenever the interface is logically up. The periodicity of probes is protocol- dependent (e.g. subject to Router Advertisement lifetimes, DHCPv6 lease timers, or homenet routing protocol timers). Wherever possible, implementations SHOULD limit the impact of probing by implementing mechanisms like exponential back-off. Homenet routers MUST be able to identify when two (or more) of the router's interfaces are connected on to the same link, e.g. by observing unique properties of a probe by which it can recognize itself. Compliant routers MUST administratively log this configuration, and SHOULD implement a mechanism that permits maximum continued homenet functionality if possible. For example, implementations MAY administratively disable all but one of the interfaces in question or MAY treat the collection of interfaces as a single logical interface in a manner suitable to the link type. 3.2. Classify next hops Routing information is used to categorize next hops as either "internal" or "external". Routers with which a homenet routing protocol adjacency is Kline Expires September 13, 2013 [Page 5] Internet-Draft Default Border Definition March 2013 successfully established MUST be considered "internal". Routers of which this homenet router has knowledge but with which no homenet routing protocol adjacency is successfully establish AND from which no routing information is learned SHOULD be considered "internal". This includes "downstream" routers for which the homenet router may be acting as the Delegating Router via a DHCPv6 Prefix Delegation exchange but which do not implement the homenet routing protocol. All other routers with which no homenet routing protocol adjacency is successfully established MUST be considered "external". 3.3. Classify interfaces An interface with no "external" next hops SHOULD be categorized as "internal". This includes interfaces serving leaf networks consisting only of hosts, an interface which has "downstream" routers for which this router is a Delegating Router, an interface with only homenet routing protocol adjacent peers, or any combination thereof. An interface with next hops all of which are categorized as "external" MUST be categorized as "external". 3.3.1. Mixed mode Some devices MAY choose to support handling questionable home network configurations which result in an interface having both interior and exterior next hops simultaneously. This can happen if, for example, two homenet routers form an adjacency with each other over the same interface they use for communicating to "upstream" ISP routers. A homenet router by default SHOULD classify such "mixed mode" interfaces as "external". Transmitting "internal" communications over interfaces with "external" nodes is NOT RECOMMENDED. All homenet routers, whether this configuration is considered supported or not, MUST administratively log and provide product- relevant notification of this configuration, preferably with recommendations for resolution. 3.4. State changes and logging 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 MUST Kline Expires September 13, 2013 [Page 6] Internet-Draft Default Border Definition March 2013 NOT be assumed. Homenet routers performing dynamic border discovery SHOULD administratively log the perimeter classification of all interfaces (physical and virtual), the reason(s) for such classification, and times at which such classifications are made or changed. 4. Fixed-category interfaces Interfaces (physical or virtual) which have product-defined purposes or are otherwise permanently categorized by the homenet router implementation as exclusively "internal" or exclusively "external" do not require any algorithm to determine their categorization. Homenet routers MUST restrict relevant traffic on fixed-category interfaces according to their categorizations. Specifically, they MUST NOT originate traffic which could result in re-categorizing the interface IF the interface were dynamically attempting to learn its categorization. For example, a fixed "external" interface MUST NOT attempt to participate in the homenet routing protocol. Similarly, fixed "internal" interfaces must not issue DHCPv6 Prefix Delegation requests. 4.1. Examples Examples of product-defined interfaces include home router interfaces which are labeled for their intended use, e.g. RJ-45 ports labeled "WAN" and "LAN" or symbols indicating "The Internet" and "inside the home". Other examples include wireless routers with defined separate WLAN "home" and "guest" ESSIDs. Another set of examples of product-defined, fixed category interfaces are those which require subscriber credentials in order for that interface to successfully pass general purpose traffic. These include authenticated PPPoE sessions and 3G/LTE PDP contexts (e.g. requiring a SIM card associated with a valid customer account). These SHOULD be classified as "exterior". Similarly, an implementation may consider the interface a mobile device uses to provide service to "tethering" clients to be a fixed- category interface. Such interfaces SHOULD be classified as "interior". 5. Security Considerations A key motivation for border identification is the application of Kline Expires September 13, 2013 [Page 7] Internet-Draft Default Border Definition March 2013 security policies which can take into account classifications of interior, exterior, and the transition from one the other. General remarks, comments on the security of the adjacencies which form the basis of border identification, and examples of potential policies which might be applied follow. 5.1. Disclamatory remarks By default all network nodes SHOULD follow best current security practices. Any node may at times find itself in a hostile environment. This is obviously true of mobile nodes, for example, when connecting to any public "Wi-Fi" network. This is, of course, equally true of more traditionally "fixed" nodes. Any compromised neighbor node ("fixed" or mobile) may be used as a conduit for further compromise. Indeed, one study of a captured "botnet" ([TORPIG], section 5.2.4) found that roughly 78.9% of infected hosts had RFC 1918 [RFC1918] addresses, commonly used in IPv4 NAT deployments. Though it goes without saying, at all times homenet implementers MUST remain mindful of best current security practices, including but not limited to RFC 4864 [RFC4864], RFC 4890 [RFC4890], RFC 6092 [RFC6092], and others. 5.2. Security of adjacency formation The security of the border definition is limited by the security applied to the formation of homenet routing protocol adjacencies: the next hops with which a homenet router forms adjacencies are the next hops the router trusts with the application of interior policies. 5.2.1. Secure links and authenticated adjacency formation The trustworthiness of next hops during adjacency formation can be improved if the security of the link connecting them can be trusted. Using encrypted link technologies like 802.1x or secured "Wi-Fi" ESSIDS when forming homenet adjacencies, or authenticating homenet next hops by physical or cryptographic mechanisms limits the ability of malicious nodes to join the homenet interior. 5.2.2. Unsecure links In general IP over Ethernet connections, common to residential Internet (and countless other places like some in-room hotel network) service provider deployments, create the possibility of malicious nodes attempting to join the homenet interior. In a broad variety of circumstances users already implicitly trust Kline Expires September 13, 2013 [Page 8] Internet-Draft Default Border Definition March 2013 unsecured links. Residential subscribers generally trust that their ISP has properly isolated their connection from any neighbors; few if any subscribers validate the ISP's DHCP server in order to thwart a malicious neighbor intervening. In the event of a network with a single upstream where an interior next hop is formed instead of an external next hop, the homenet network as a whole would have detected no external next hops. Homenet router networks in which there are no external next hops SHOULD administratively log this configuration and SHOULD provide a means to alert the user to this condition. Note that for isolated networks of homenet routers (e.g. a lab network) this configuration is entirely valid. User notification alone is not sufficient protection for the homenet user, and will not correctly alert the user of a homenet with two upstream connections, one of which has mistakenly not categorized a next hop as external. To better serve the homenet user, homenet routers are SHOULD follow one or more of the recommendations in Section 5.2.3. 5.2.3. Recommendations Homenet router implementations that support dynamic discovery of the border (i.e. have interfaces on which the dynamic border detection described in Section 3 can be configured to operate) SHOULD support restricting homenet routing protocol adjacency formation to only next hops which meet some user-defined or user-verified authentication mechanism (including examples described in Section 5.2.1). Alternatively, implementations MAY incorporate a mechanism (possibly physical) whereby a homenet user can disable border detection on an interface which the user wishes to force into either an interior or exterior classification (e.g. a button to force an interface to be "external" only). 5.3. Example border-aware filtering policies As a homenet router forms adjacencies and learns internal aggregate prefixes it could dynamically maintain a single logical entity encompassing all current internal prefixes in use that can be treated as a whole (i.e. an access list). Below are example filtering policies that might be applied by homenet routers with knowledge of both this prefix set and the interior or exterior classification of all interfaces. The examples below use the string "{interior_nets}" for refer to the grouping of all internal aggregate prefixes. The sample filtering Kline Expires September 13, 2013 [Page 9] Internet-Draft Default Border Definition March 2013 policy rules are written in configuration pseudo-syntax that should hopefully be intuitive. 5.3.1. Anti-spoofing on internal interfaces Given knowledge of all interior network prefixes and the categorization of interfaces, all interior interfaces could apply a stateless filter designed to prevent devices in the home from originating source-address-spoofed traffic. Using a filter configuration pseudo-syntax: from !{interior_nets} to !{interior_nets} deny ... # permit or deny other kinds of traffic 5.3.2. Stateful filtering on external interfaces Given knowledge of all interior network prefixes and the categorization of interfaces, all exterior interfaces could apply a stateful filter designed to discard traffic without matching state in the homenet router. Using a filter configuration pseudo-syntax: ... # permit other kinds of good traffic first from {interior_nets} to !{interior_nets} permit from !{interior_nets} to {interior_nets} established permit from any to any deny 5.3.3. Mixed-mode interface filtering Given knowledge of all interior network prefixes and the categorization of interfaces, all mixed-node interfaces could apply a stateful filter designed to discard exterior traffic without matching state in the homenet router and still statelessly permit internal traffic. Using a filter configuration pseudo-syntax: ... # permit other kinds of good traffic first from {interior_nets} to !{interior_nets} permit from !{interior_nets} to {interior_nets} established permit from {interior_nets} to {interior_nets} permit from any to any deny Because routing changes elsewhere in the home may cause traffic to shift among interior next hops which may not have state, traffic between interior routers may not be well-served by stateful Kline Expires September 13, 2013 [Page 10] Internet-Draft Default Border Definition March 2013 filtering. One consequence for this policy on mixed-mode interfaces is that traffic from the exterior with spoofed source addresses from the "{interior_nets}" set of prefixes may be mistakenly allowed into the home. Filter implementations which can incorporate knowledge of the previous and next hops and their classifications can design much more precise filters. Such implementations could deny traffic with "{interior_nets}" source addresses arriving from an exterior next hop, but permit them from an interior next hop on the same mixed-mode interface. 6. Acknowledgements Many thanks for the constructive input and criticism of Shwetha Bhandari, Lorenzo Colitti, Markus Stenberg, Mark Townsley, and Ole Troan. Thanks also must go to pleasant, peaceful and productive trips on the Japan Rail (JR) Shinkansen ("bullet train"). 7. IANA Considerations This memo includes no request to IANA. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007. Kline Expires September 13, 2013 [Page 11] Internet-Draft Default Border Definition March 2013 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011. [TORPIG] Stone-Gross, B., "Your Botnet is My Botnet: Analysis of a Botnet Takeover", 2009, . Author's Address Erik Kline Google Japan Roppongi 6-10-1, 26th Floor Minato, Tokyo 106-6126 JP Phone: +81 03 6384 9000 Email: ek@google.com Kline Expires September 13, 2013 [Page 12]