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]