[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kline-default-perimeter) 00

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, <http://www.cs.ucsb.edu/~seclab/
              projects/torpig/torpig.pdf>.


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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/