<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC1918 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
  <!ENTITY RFC2119 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!--
  <!ENTITY RFC3552 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
-->
  <!ENTITY RFC4864 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml">
  <!ENTITY RFC4890 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4890.xml">
  <!ENTITY RFC6092 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6092.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info"
     docName="draft-kline-homenet-default-perimeter-00"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
       ipr values: trust200902, noModificationTrust200902,
                   noDerivativesTrust200902, or pre5378Trust200902
       you can add the attributes updates="NNNN" and obsoletes="NNNN"
       they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="Default Border Definition">
Default Border Definition
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Erik Kline" initials="E." surname="Kline">
      <organization>Google Japan</organization>

      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>Roppongi 6-10-1, 26th Floor</street>
          <city>Minato</city>
          <region>Tokyo</region>
          <code>106-6126</code>
          <country>JP</country>
        </postal>

        <phone>+81 03 6384 9000</phone>

        <email>ek@google.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date/>

    <!-- Meta-data Declarations -->

    <area>Internet Area</area>

    <workgroup>Home Networking</workgroup>

    <!-- WG name at the upperleft corner of the doc, IETF is fine for
         individual submissions.  If this element is not present, the default
         is "Network Working Group", which is used by the RFC Editor as a nod
         to the history of the IETF. -->

    <keyword>border</keyword>
    <keyword>homenet</keyword>
    <keyword>perimeter</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>
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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
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.
      </t>
      <t>
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.
      </t>
      <t>
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.
      </t>

      <section title="Requirements Language">
        <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section>


    <section title="Terminology">
      <t>
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.
      </t>

      <t>
        <list hangIndent="4" style="hanging">
          <t hangText="Internal/Interior">
          <vspace blankLines="1" />
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.
          </t>

          <t hangText="External/Exterior">
          <vspace blankLines="1" />
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.
          </t>

          <t hangText="Border/Perimeter">
          <vspace blankLines="1" />
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.
          </t>
        </list>
      </t>

      <t>
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.
      </t>

      <t>
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.
      </t>
    </section>

    <section anchor="algorithm" title="Dynamically determining the border">
      <t>
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.
      </t>
      <t>
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.
      </t>

      <t>
The classification algorithm documented here is roughly:
        <list style="numbers">
          <t>
Continously collect information on all interfaces about neighboring routers
(including manually configured routers).
          </t>
          <t>
Classify next hops as either "internal" or "external" primarily by homenet
router protocol adjacency status.
          </t>
          <t>
Classify interfaces according to the nature of their next hops.
          </t>
        </list>
      </t>

      <t>
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".
      </t>
      <t>
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.
      </t>

      <section title="Collect information about neighboring routers">
        <t>
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.
        </t>

        <t>
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.
        </t>

        <t>
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.
        </t>
      </section>

      <section title="Classify next hops">
        <t>
Routing information is used to categorize next hops as either "internal" or
"external".
        </t>
        <t>
Routers with which a homenet routing protocol adjacency is successfully
established MUST be considered "internal".
        </t>
        <t>
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.
        </t>
        <t>
All other routers with which no homenet routing protocol adjacency is
successfully established MUST be considered "external".
        </t>
      </section>

      <section title="Classify interfaces">
        <t>
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.
        </t>
        <t>
An interface with next hops all of which are categorized as "external"
MUST be categorized as "external".
        </t>

        <section title="Mixed mode">
          <t>
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.
          </t>
          <t>
A homenet router by default SHOULD classify such "mixed mode" interfaces as
"external".  Transmitting "internal" communications over interfaces with
"external" nodes is NOT RECOMMENDED.
          </t>
          <t>
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.
          </t>
        </section>
      </section>

      <section title="State changes and logging">
        <t>
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 NOT be assumed.
        </t>
        <t>
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.
        </t>
      </section>
    </section>

    <section title="Fixed-category interfaces">
      <t>
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.
      </t>
      <t>
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.
      </t>

      <section title="Examples">
        <t>
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.
        </t>
        <t>
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".
        </t>
        <t>
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".
        </t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
A key motivation for border identification is the application of 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.
      </t>

      <section title="Disclamatory remarks">
        <t>
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"
(<xref target="TORPIG" />, section 5.2.4) found that roughly 78.9% of infected
hosts had <xref target="RFC1918">RFC 1918</xref> addresses, commonly used in
IPv4 NAT deployments.
        </t>
        <t>
Though it goes without saying, at all times homenet implementers MUST remain
mindful of best current security practices, including but not limited to
<xref target="RFC4864">RFC 4864</xref>,
<xref target="RFC4890">RFC 4890</xref>,
<xref target="RFC6092">RFC 6092</xref>,
and others.
       </t>
      </section>

      <section title="Security of adjacency formation">
        <t>
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.
        </t>
        <section anchor="secure_links"
                 title="Secure links and authenticated adjacency formation">
          <t>
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.
          </t>
        </section>
        <section title="Unsecure links">
          <t>
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.
          </t>
          <t>
In a broad variety of circumstances users already implicitly trust 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.
          </t>
          <t>
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.
          </t>
          <t>
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 <xref target="recs4unsecure"/>.
          </t>
        </section>
        <section anchor="recs4unsecure" title="Recommendations">
          <t>
Homenet router implementations that support dynamic discovery of the border
(i.e. have interfaces on which the dynamic border detection described in
<xref target="algorithm"/> 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 <xref target="secure_links"/>).
          </t>
          <t>
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).
          </t>
        </section>
      </section>

      <section title="Example border-aware filtering policies">
        <t>
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.
        </t>
        <t>
The examples below use the string "{interior_nets}" for refer to the grouping
of all internal aggregate prefixes.  The sample filtering policy rules are
written in configuration pseudo-syntax that should hopefully be intuitive.
        </t>

        <section title="Anti-spoofing on internal interfaces">
          <t>
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.
          </t>
          <figure>
            <preamble>
Using a filter configuration pseudo-syntax:
            </preamble>
            <artwork>
    from !{interior_nets} to !{interior_nets} deny
    ... # permit or deny other kinds of traffic
            </artwork>
          </figure>
        </section>

        <section title="Stateful filtering on external interfaces">
          <t>
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.
          </t>
          <figure>
            <preamble>
Using a filter configuration pseudo-syntax:
            </preamble>
            <artwork>
    ... # 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
            </artwork>
          </figure>
        </section>

        <section title="Mixed-mode interface filtering">
          <t>
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.
          </t>
          <figure>
            <preamble>
Using a filter configuration pseudo-syntax:
            </preamble>
            <artwork>
    ... # 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
            </artwork>
          </figure>
          <t>
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 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.
          </t>
          <t>
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.
          </t>
        </section>
      </section>
<!--
      <section title="XXX">
        <t>
All drafts are required to have a security considerations section. See
<xref target="RFC3552">RFC 3552</xref> for a guide.
        </t>
      </section>
-->
    </section>

    <!-- Possibly a 'Contributors' section ... -->
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
Many thanks for the constructive input and criticism of Shwetha Bhandari,
Lorenzo Colitti, Markus Stenberg, Mark Townsley, and Ole Troan.
      </t>
      <t>
Thanks also must go to pleasant, peaceful and productive trips on the
Japan Rail (JR) Shinkansen ("bullet train").
      </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>
This memo includes no request to IANA.
      </t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->
  <back>
    <references title="Normative References">

      &RFC2119;

    </references>

    <references title="Informative References">

      &RFC1918;

<!--
      &RFC3552;
-->

      &RFC4864;

      &RFC4890;

      &RFC6092;

      <reference anchor="TORPIG"
           target="http://www.cs.ucsb.edu/~seclab/projects/torpig/torpig.pdf">
        <front>
          <title>
Your Botnet is My Botnet: Analysis of a Botnet Takeover
          </title>

          <author initials="B" surname="Stone-Gross">
            <organization>University of California, Santa Barbara
            </organization>
          </author>
          <date year="2009" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
