[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-kline-homenet-default-perimeter

Internet Engineering Task Force                                 E. Kline
Internet-Draft                                               Google Inc.
Intended status: Informational                             July 29, 2012
Expires: January 30, 2013


                    Default Perimeter Identification
                    draft-kline-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 proposes a set of default tests to be applied to
   traffic scheduled for forwarding, which can be used collectively to
   identify this perimeter in some (but not all) environments.

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 January 30, 2013.

Copyright Notice

   Copyright (c) 2012 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
   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.



Kline                   Expires January 30, 2013                [Page 1]


Internet-Draft      Default Perimeter Identification           July 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Fundamental recommendations  . . . . . . . . . . . . . . . . .  4
     3.1.  Network node default security practices  . . . . . . . . .  4
     3.2.  State changes and logging  . . . . . . . . . . . . . . . .  5
   4.  Useful perimeter signals . . . . . . . . . . . . . . . . . . .  5
     4.1.  Product-defined interface purposes . . . . . . . . . . . .  6
     4.2.  Routing adjacency  . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Links requiring subscriber information . . . . . . . . . .  6
     4.4.  Links requiring existing network-layer connectivity  . . .  7
     4.5.  Links that are fundamentally point-to-point in nature  . .  7
   5.  IP over Ethernet . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  DHCPv6 PD, if and only if... . . . . . . . . . . . . . . .  8
     5.2.  Other tricks?  . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Additional considerations  . . . . . . . . . . . . . . . . . .  8
     6.1.  Physical vs virtual interfaces . . . . . . . . . . . . . .  8
     6.2.  Mixed zone next-hops on the same interface . . . . . . . .  9
     6.3.  Perimeter and protocol version . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Additional Stuff  . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10






















Kline                   Expires January 30, 2013                [Page 2]


Internet-Draft      Default Perimeter Identification           July 2012


1.  Introduction

   Automatic, simple identification of when traffic is crossing a
   perimeter is highly desirable for a variety of home network uses.
   This document proposes a set of default tests to be applied to
   traffic scheduled for forwarding, which can be used collectively to
   identify this perimeter.

   Of note are limitations introduced by the ubiquitous use of IP over
   Ethernet (IPoE) Internet access methods.  By design these
   architectures make it difficult (at best) to distinguish any
   difference between a LAN port in an enterprise and a home Internet
   connection.

   Nevertheless, where practical, an automated mechanism of perimeter
   discovery permits home devices to define default definitions of the
   "interior", i.e. the home, and the "exterior", usually the greater
   Internet.  Once indentified, a device could apply default security
   policies to traffic transiting the perimeter.

   Specifying the default policy that should be applied to traffic
   crossing this perimeter is out of scope of this document.
   Implementors should remain mindful of recommended practices, e.g.
   RFC 4864 [RFC4864], et cetera.

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 perimeter identification at a manageable scale
   the scope has been limited to discussing concepts of "interior",
   "exterior", and "perimeter".  Working definitions in use by this
   document are as follows.

   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.







Kline                   Expires January 30, 2013                [Page 3]


Internet-Draft      Default Perimeter Identification           July 2012


   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.

   Perimeter
           The perimeter 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.

   Expressly not discussed herein are architectures having multiple
   interior networks, nor the relationships between them as separate
   from their relationship to their common exterior or any common
   perimeter.  The architectures under discussion have a single
   interior, single exterior, and a single logical perimeter between
   them.

   The definition of perimeter is such that, for example, an IP packet
   arriving on a NAT device's interior interface that is "hairpinned"
   and retransmitted out the interior interface is not considered to
   have touched nor crossed the perimeter.

   The definition of perimeter as written technically permits traffic
   being forwarded over an interface to be classified as transiting a
   perimeter or not based on the classification of the next-hop.  The
   implications of this are discussed in a later section.


3.  Fundamental recommendations

   The application of security policies at the perimeter and possible
   relaxation of security policies within the interior are apt to have
   administrative consequences.  Some fundamental recommendations for
   nodes operating in this environment follow.

3.1.  Network node default security practices

   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 when, for
   instance, connecting to a variety of public "Wi-Fi" networks.  In



Kline                   Expires January 30, 2013                [Page 4]


Internet-Draft      Default Perimeter Identification           July 2012


   such environments mobile nodes cannot be sure that there is any
   network device acting in the mobile node's own best security
   interests with respect to others on the local network.

   It is equally true of more traditionally "fixed" nodes: any
   compromised neighbor nodes ("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, commmonly used in
   IPv4 NAT deployments.

3.2.  State changes and logging

   Devices conforming to this and other homenet documents MUST
   continuously evaluate the interior, exterior, and perimeter
   classifications of interfaces and traffic.  These may change at any
   time, for example if new devices are added into the network or a
   power event causes all equipment to reset, and specific ordering of
   device bring-up within a homenet network MAY NOT be assumed.

   Nodes compliant with this and other homenet documents SHOULD
   administratively log the perimeter classification of interfaces (both
   physical and virtual), the reason(s) for such classification, and
   times at which such classifications are made or changed.


4.  Useful perimeter signals

   This is a non-trivial task as it is tantamount to automated discovery
   of administrative boundaries.

   Many architectures fundamentally make it difficult or impossible to
   detect administrative boundaries and rely on various mechanisms of
   user or administrator invention to create or modify such boundaries.
   Other hints about administrative boundaries may be insecure,
   unreliable, operationally impractical, or may place arbitrary
   requirements upon the architectural where previously no such
   requirement existed.

   Nevertheless there are some signals that may be useful.  Which
   signals are available and useful vary with the access architecture,
   and in some cases there may be virtually no reliable information to
   securely determine a perimeter.  An physically or cryptographically
   authenticated routing protocol may be the highest fidelity signal for
   determining the interior, and thereby the exterior and perimeter.






Kline                   Expires January 30, 2013                [Page 5]


Internet-Draft      Default Perimeter Identification           July 2012


4.1.  Product-defined interface purposes

   Many products come with interfaces labeled with their intended use.
   Examples include home routers with RJ-45 ports labeled "WAN" and
   "LAN", or perhaps with symbols indicating "The Internet" and "inside
   the home".  Other examples include wireless routers with defined
   separate WLAN and "Guest" ESSIDs.  In such cases where interior and
   exterior are clearly delineated a homenet device SHOULD by default
   consider traffic forwarded between interfaces of differing regions as
   traversing a boundary.

4.2.  Routing adjacency

   Some networks may employ a physically or cryptographically secure
   routing protocol.  Within such networks, traffic received from and
   scheduled to be forwarded to next-hops with whom an adjacency has
   been formed SHOULD by default be classified as interior and not
   considered to be transiting a perimeter.

   Similarly, traffic forwarded to or received from next-hops with whom
   no adjacency has been formed SHOULD by default be classified as
   exterior.  A next-hop with whom no adjacency has been formed but
   which nevertheless constitutes the next-hop for a learned or
   configured route SHOULD by default be considered exterior.

   If (and only if?) an interface has only interior next-hops then
   traffic originating from nodes on links on that interface SHOULD by
   default be considered to be interior...  Discuss: [two routers each
   sharing a hub with two upstreams on it].  HELP: need more thought to
   clarify forwarding traffic to on-link destinations versus to next-
   hops for further forwarding.  Don't want to accidentally classify
   interior on-link nodes as exterior because no adjacency is formed.

   HELP: much more thought is required here.  What about bring-up order?
   What about an interior node attempting and failing to start an
   authenticated adjacency: it's a problem if the interface flips into
   exterior classification.

   HELP: find language that doesn't, for example, define interior to be
   the entire Internet when RPKI is in use.

4.3.  Links requiring subscriber information

   One obvious administrative boundary is a link that requires
   subscriber credentials in order for that link to successfully forward
   and receive general traffic.  Examples include authenticated PPPoE
   sessions, 3G/LTE PDP contexts (requiring a SIM card associated with a
   customer account), and authenticated VPN links.  By default, all



Kline                   Expires January 30, 2013                [Page 6]


Internet-Draft      Default Perimeter Identification           July 2012


   traffic traversing such a link SHOULD be considered to be traversing
   a perimeter.

4.4.  Links requiring existing network-layer connectivity

   By default, all traffic traversing any interface that encapsulates
   (decapsulates) its payload in a layer higher than or equal to the
   network (IP) layer in order to forward (receive) traffic SHOULD be
   considered to be traversing a perimeter.  Examples of such interfaces
   include: Teredo, 6to4, 6rd, 4rd, PPTP and L2TP tunnels, et cetera.

   In cases where the exact layer of encapsulation is not necessarily
   clearly defined or agreed upon, e.g.  MPLS interfaces, traffic
   traversing such interfaces SHOULD also by default be considered to be
   traversing a perimeter.

   In the absence of default perimeter classification, such links would
   provide a mechanism to breach an otherwise existing perimeter and
   generally complicate the definition and discovery of the interior.
   In cases where such interfaces are desired to be classified as part
   of the interior, and traffic traversing them also classified as
   interior traffic, another means MAY use to re-classify accordingly.

4.5.  Links that are fundamentally point-to-point in nature

   Most home networking technology supports more than two nodes on the
   same logical link communicating directly.  By default, traffic
   traversing from such a "shared access" link which is classified as
   interior to one which is fundamentally point-to-point in nature (e.g.
   PPPoE, PPPoA, or some other future link type) SHOULD be considered as
   transiting a perimeter.

   Additionally, traffic transiting a homenet device from such a "shared
   access" link which is classified as interior to one on which no on-
   link neighbor discovery and/or communication is permitted by
   configuration of the node itself, e.g. an 802.11 SSID on which the
   node acting as an infrastructural access point forbids direct
   neighbor communications, SHOULD be considered as crossing a
   perimeter.

   HELP: what does this mean for 6lowpan networks inside the home?


5.  IP over Ethernet

   The ubiquity of IPoE undoubtedly greatly simplifies network
   architectures and node requirements for connecting to such networks.
   However, it can be difficult at best for a homenet device to



Kline                   Expires January 30, 2013                [Page 7]


Internet-Draft      Default Perimeter Identification           July 2012


   determine if it is fully in the interior of a network or part of the
   perimeter.

5.1.  DHCPv6 PD, if and only if...

   DHCPv6 PD is at this time the most common method for supplying "SoHo"
   networks with a routable prefix block.  If (and only if) a means of
   distributing prefixes among interior routers is devised that does NOT
   use DHCPv6 Prefix Delegation, then a link on which DHCPv6 PD
   succeeded SHOULD be considered an administrative boundary and traffic
   traversing this interface SHOULD be considered to be traversing a
   perimeter.

   If DHCPv6-PD is to be used within the interior then this signal is
   not useful.

5.2.  Other tricks?

   (TBD) If you're DHCPv6-setting-up-the-reverse-DNS then that interface
   SHOULD be considered part of the perimeter.

   (TBD) If DHCPv4'ing an RFC 1918,6598,... address?  What other
   prefixes and updates will be required as we run out of IPv4?


6.  Additional considerations

   Everything herein needs more thought and work.

6.1.  Physical vs virtual interfaces

   In certain configurations it may be desirable that the perimeter
   defined on a virtual interface also be extended to include the
   physical interface(s) over which such traffic is forwarded/received.
   For example, consider a router configured with a PPPoE virtual
   interface on a physical 802.3 interface.  In such a configuration,
   the security policy applied to traffic transiting the PPPoE interface
   should most likely also be applied to non-PPPoE traffic transitting
   the physical interface.  If not, the "interior" region would
   otherwise be logically extended to include the upstream access link.
   As there is no guaranteed of administrative boundary XXX, a default
   configuration SHOULD consider the physical interface a perimeter.

   By way of contrast, consider an entirely interior router which also
   has a VPN interface, through which traffic may be passed to, say, a
   resident's company network.  While a VPN virtual interface SHOULD be
   considered a logical demarcation point, the physical interface
   through which VPN-encapsulated traffic is transmitted need not



Kline                   Expires January 30, 2013                [Page 8]


Internet-Draft      Default Perimeter Identification           July 2012


   necessarily be classified as such.  Instead, what may be desired is
   that traffic to/from interfaces that are interior to this VPN-enabled
   router may pass through either the VPN interface or any "upstream"
   interfaces, but traffic originating from "upstream" interfaces may be
   default DENIED transit through the VPN interface.  While this
   situation may be far from the norm for networks, it nevertheless
   affords the maintenance of a simple mental model of a hierarchical
   network.

   To address these uses, by default the physical interface(s) through
   which a virtual interface's traffic is forward should also be
   considered a perimeter, unless other means determine that it is in
   fact an interior interface.  Note that in all cases such a virtual
   interface is considered a perimeter.

   Discuss: applying the policy to the entire interface for some
   "infrastructural" connections (e.g.  PPPoE).  Virtual link versus
   physical link, virtual interface versus physical interface.

6.2.  Mixed zone next-hops on the same interface

   By default, if one then all.  TBD: explain.

6.3.  Perimeter and protocol version

   In cases where one IP version's perimeter might be determined to
   differ in some way from another IP version's identified perimeter,
   the potential for confusion and misconfiguration, and therefore
   security risk, increases.  In the interests of simplicity, and in
   keeping with the principle of least surprise, traffic transiting
   links or forwarding to (received from) next-hops which would transit
   a perimeter in one protocol version SHOULD be considered as
   transiting a perimeter for traffic of all protocol versions.


7.  Acknowledgements

   The author gratefully acknowledges the constructive input and
   criticism of Lorenzo Colitti, Mark Townsley, and Ole Troan.

   Thanks also must go to pleasant, peaceful and productive trips on the
   Japan Rail (JR) Shinkansen ("bullet train").


8.  IANA Considerations

   This memo includes no request to IANA.




Kline                   Expires January 30, 2013                [Page 9]


Internet-Draft      Default Perimeter Identification           July 2012


9.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.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.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
              E. Klein, "Local Network Protection for IPv6", RFC 4864,
              May 2007.

   [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>.


Appendix A.  Additional Stuff

   This becomes an Appendix.


Author's Address

   Erik Kline
   Google Inc.
   Roppongi 6-10-1, 26th Floor
   Minato, Tokyo  106-6126
   JP

   Phone: +81 03 6384 9000
   Email: ek@google.com




Kline                   Expires January 30, 2013               [Page 10]


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