Internet Engineering Task Force S. HomChaudhuri
Internet Draft M. Foschiano
Category: Informational Cisco Systems
Expires: August 2007 February 2007
Private VLANs: Addressing VLAN scalability and
security issues in a multi-client environment
draft-sanjib-private-vlan-06.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Private VLANs August 2007
Abstract
This document describes the concept of Layer 2 isolation among
devices that are members of the same Layer 2 domain.
A vlan is a broadcast domain in which all devices can establish
direct communication with one another at Layer 2.
As a consequence, devices that are connected to the same vlan have
an implicit trust relationship with each other. If 'untrusted'
devices are introduced into a vlan, security issues may arise
because trusted and untrusted devices end up sharing the same
broadcast domain.
The traditional solution to this kind of problem is to assign a
separate vlan to each device that is concerned about Layer 2
security issues. That however is not a scalable solution. The
mechanism proposed in this document can offer total Layer 2
isolation between devices connected to the same vlan. What that
means is that, on the one hand, each customer will enjoy the
benefits that come with a separate dedicated vlan, while on the
other hand the service provider will enjoy the benefit of consuming
as few as two vlan identifiers.
Moreover, the scheme described in this document allows end devices
to be Layer 2 isolated while sharing the same IP subnet, which in
turn allows the network designer to employ larger subnets and reduce
the address allocation and management overhead.
Conventions used in this document
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 [1].
HomChaudhuri, Foschiano [Page 2]
Private VLANs August 2007
Table of Contents
1. Introduction................................................4
1.1 Security Concerns with Sharing a Vlan.....................4
1.2 Traditional Solution......................................5
1.3 Problems with the Traditional Solution....................5
2. Private Vlans Architecture..................................5
3. Private Vlan Switch Ports and Their Characteristics.........9
3.1 Isolated Vlan............................................10
4. Extending Private Vlans across Switches....................11
5. A More Flexible IP Addressing Scheme.......................11
6. Routing Considerations.....................................12
Security Considerations.........................................12
IANA Considerations.............................................12
Deployment Consideration........................................13
Changes from the Previous Version...............................13
Acknowledgements................................................13
Normative References............................................13
Informative References..........................................13
Authors' Addresses..............................................13
IPR Notice......................................................14
Full Copyright Notice...........................................14
HomChaudhuri, Foschiano [Page 3]
Private VLANs August 2007
1. Introduction
In an Ethernet network, the data frames can contain a 'vlan ID'
field. The IEEE 802.1Q standard [2] specifies that the vlan ID field
is 12 bits wide. That allows for a theoretical maximum of 4094 vlans
in an Ethernet network (vlan numbers 0 and 4095 are reserved). If
the network administrator assigns one vlan per user, then that
equates to a maximum of 4094 users that can be supported. The
private vlans technology addresses this scalability problem by
offering more granular and more flexible Layer 2 segregation, as
explained in the following sections.
1.1 Security Concerns with Sharing a Vlan
Companies who have Internet presence can either host their servers
in their own premises or, alternatively, they can locate their
servers at the Internet Service Provider's premises. A typical ISP
would have a server farm that offers web hosting functionality for a
number of customers. Co-locating the servers in a server farm offers
ease of management but at the same time may raise security concerns.
Let us assume that the ISP puts all the servers in one big vlan.
Servers residing in the same vlan can listen to Layer 2 broadcasts
from other servers. Once a server learns the MAC address associated
to the IP address of another computer in the same vlan, it can
establish direct Layer 2 communication with that device without
having to go through a Layer 3 gateway/firewall. If for example a
hacker gets access to one of the servers, he can use that
compromised host to launch an attack on other servers in the server
farm. To protect themselves from malicious attacks, ISP customers
want their machines to be isolated from other machines in the same
server farm.
The security concerns become even more apparent in metropolitan area
networks. Metropolitan Service Providers may want to provide Layer 2
Ethernet access to homes, rental communities, businesses, etc. In
this scenario, the subscriber next door could very well be a hacker.
It is therefore very important to offer Layer 2 traffic isolation
among customers. Customer A would not want his Layer 2 frames being
broadcast to customer B, who happens to be in the same vlan. Also,
customer A would not want customer B to bypass a router or a
firewall and establish direct Layer 2 communication with him/her.
HomChaudhuri, Foschiano [Page 4]
Private VLANs August 2007
1.2 Traditional Solution
The traditional solution would be to assign a separate vlan to each
customer. That way, each user is assured of Layer 2 isolation from
devices belonging to other users.
1.3 Problems with the Traditional Solution
In the vlan-per-customer model, if an ISP offers web-hosting
services to, say, 4000 customers it would consume 4000 vlans.
Theoretically, the maximum number of vlans that an 802.1Q-compliant
networking device can support is 4094. In reality, many devices
support a much lesser number of active vlans. Even if all devices
supported all 4094 vlans, there would still be a scalability problem
when the 4095th customer signed up.
A second problem with assigning a separate vlan per customer is
management of IP addresses. Since each vlan requires a separate
subnet, there can be potential wastage of IP addresses in each
subnet. This issue has been described by RFC3069 [3] and will not be
discussed in detail in this document.
2. Private Vlans Architecture
The private vlans architecture is similar but more elaborate than
the aggregated vlan model proposed in RFC3069. The concepts of
'super vlan' and 'sub vlan' used in that RFC are functionally
similar to the concepts of 'primary vlan' and 'secondary vlan' used
in this document.
A regular vlan is a single broadcast domain. The private vlan
technology partitions a larger vlan broadcast domain into smaller
sub-domains. So far two kinds of sub-domains have been defined: an
'isolated' sub-domain and a 'community' sub-domain. Each sub-domain
is defined by assigning a proper designation to a group of switch
ports.
Within a private vlan domain three separate port designations exist.
Each port designation has its own unique set of rules which regulate
a connected endpoint's ability to communicate with other connected
endpoints within the same private vlan domain. The three port
designations are: promiscuous, isolated, and community.
HomChaudhuri, Foschiano [Page 5]
Private VLANs August 2007
An endpoint connected to a promiscuous port has the ability to
communicate with any endpoint within the private vlan. Multiple
promiscuous ports may be defined within a single private vlan domain.
In most networks, Layer 3 default gateways or network management
stations are commonly connected to promiscuous ports.
Isolated ports are typically used for those endpoints that only
require access to a limited number of outgoing interfaces on a
private-vlan-enabled device. An endpoint connected to an isolated
port will only possess the ability to communicate with those
endpoints connected to promiscuous ports. Endpoints connected to
adjacent isolated ports cannot communicate with one another. For
example, within a web hosting environment, isolated ports can be
used to connect hosts that require access only to default gateways.
A private vlan community is a grouping of ports connected to devices
belonging to the same entity (for example, an ISP customer or a
household). Within a community, endpoints can communicate with one
another and can also communicate with any configured promiscuous
port. Endpoints belonging to one community cannot instead
communicate with endpoints belonging to a different community or
with endpoints connected to isolated ports.
Figure 1 illustrates the private vlan model.
HomChaudhuri, Foschiano [Page 6]
Private VLANs August 2007
-----------
| R |
-----------
|
|
|
----------------------------------------
| p1 |
| [--Vp--] |
=====| t1 |
| switch |
| |
| [--Vi--] [--Vc--] |
|i1 i2 c1 c2 |
----------------------------------------
| | | |
| | | |
| | | |
A B C D
Vp - Primary vlan
Vi - Isolated vlan
Vc - Community vlan
A, B - Isolated devices
C, D - Community devices
R - Router (or other L4-L7 device)
i1, i2 - Isolated switch ports
c1, c2 - Community switch ports
p1 - Promiscuous switch port
t1 - Inter-switch link port (a vlan-aware port)
Fig 1. Private vlan classification of switch ports
--------------------------------------------------
With reference to Figure 1, each of the port types is described
below.
Isolated ports: An isolated port (i1 or i2) cannot talk to any other
port in that private vlan domain except for promiscuous ports. If a
customer device needs to have access only to a gateway router, then
it should be attached to an isolated port. An isolated port is
typically an access port, but in certain applications it can also be
a hybrid or trunk port (according to Annex D's terminology in [2]).
HomChaudhuri, Foschiano [Page 7]
Private VLANs August 2007
Community ports: A community port (c1 or c2) is part of a group of
ports. The ports within a community can have Layer 2 communications
with one another and can also talk to any promiscuous port. If an
ISP customer has, say, 4 devices and wants his/her machines to be
isolated from other customers' machines but to be able to
communicate among themselves, then community ports should be used.
Promiscuous ports: As the name suggests, a promiscuous port (p1) can
talk to all other types of ports. A promiscuous port can talk to
isolated ports as well as community ports and vice versa. Layer 3
gateways, DHCP servers and other 'trusted' devices that need to
communicate with the customer endpoints are typically connected via
a promiscuous port. A promiscuous port can be either an access port
or a hybrid/trunk port according to the terminology presented in
Annex D of the IEEE 802.1Q spec [2].
The table below summarizes the communication privileges between the
different private vlan port types.
Table 1.
---------------------------------------------------------------
| | isolat-| promis-| commu-| commu-| interswitch |
| | ted |cuous | nity1 | nity2 | link port |
---------------------------------------------------------------
| isolated | deny | permit | deny | deny | permit |
---------------------------------------------------------------
| promiscuous | permit | permit | permit| permit| permit |
---------------------------------------------------------------
| community1 | deny | permit | permit| deny | permit |
---------------------------------------------------------------
| community2 | deny | permit | deny | permit| permit |
---------------------------------------------------------------
| interswitch | | | | | |
| link port | deny(*)| permit| permit| permit| permit |
---------------------------------------------------------------
(*) Please note that this asymmetric behavior is for traffic
traversing inter-switch link ports over an isolated vlan only.
Traffic from an inter-switch link port to an isolated port will be
denied if it is in the isolated vlan. Traffic from an inter-switch
link port to an isolated port will be permitted if it is in the
primary vlan.
N.B.: An interswitch link port is simply a regular port that
connects two switches (and that happens to carry two or more vlans).
HomChaudhuri, Foschiano [Page 8]
Private VLANs August 2007
The concept of sub-domains within a vlan domain cannot be easily
implemented with only one vlan ID. However, a mechanism of pairing
of vlans can be used to achieve this notion. A sub-domain can be
represented by a pair of vlan numbers:
<Vp,Vs> Vp is the primary vlan
Vs is the secondary vlan
-----
| Vp|
-----
/ \
/ \
/ \
----- -----
| Vi| | Vc|
----- -----
Fig 2 A private vlan can be implemented with 2 or more vlan numbers
--------------------------------------------------------------------
A private vlan is built with at least one pair of vlans: one (and
only one) primary vlan plus one or more secondary vlans. Secondary
vlans can be of two types: isolated vlans (Vi) or community vlans
(Vc). The specific characteristic of an isolated vlan is that it
allows all its ports to have the same degree of segregation that
could be obtained from using one separate dedicated vlan per port.
Note that a total of only two vlan identifiers are consumed in
providing this port isolation characteristic.
Also please note that this vlan pairing scheme simply requires that
all traffic transported within primary and secondary vlans be tagged
according to the IEEE 802.1Q standard [2], i.e., with at most a
single standard vlan tag (no special double-tagging is necessary due
to the 1:1 correspondence between a secondary vlan and its primary).
3. Private Vlan Switch Ports and Their Characteristics
The switch ports in a private vlan domain have special
characteristics, as described in section 2. One key characteristic
is port segregation within an isolated vlan.
HomChaudhuri, Foschiano [Page 9]
Private VLANs August 2007
3.1 Isolated Vlan
An isolated vlan is a component of the private vlan architecture. It
is one type of secondary vlan. While there can be multiple community
vlans in a private vlan domain, only one isolated vlan is sufficient
to serve multiple customers.
In the private vlan architecture, each of the secondary vlans is
'bound' or 'associated' to a primary vlan. Only one isolated vlan
may be bound to a specific primary vlan to serve any number of
customers.
With reference to Figure 1, a router R connected to the promiscuous
port can have Layer 2 communication with a device A connected to the
isolated port and also with a device C connected to the community
port. Devices C and D can also have Layer 2 communication between
themselves, since they are part of the same community vlan. However,
devices A and B cannot communicate at Layer 2 due to the special
port segregation property of the isolated vlan. Also, devices A and
C cannot communicate at Layer 2 since they belong to different
secondary vlans.
The distinctive characteristic of an isolated vlan is that all
endpoints connected to its ports are isolated at Layer 2. The impact
of this enforced restriction is two-fold. Firstly, service providers
can assign multiple customers to the same isolated vlan, thereby
conserving vlan IDs. Secondly, customers can be assured that their
Layer 2 traffic cannot be sniffed by other customers sharing the
same isolated vlan.
Some switch vendors have attempted to provide this port isolation
feature within a vlan, by implementing the logic at the port level.
When implemented at the port level, the isolation behavior is
restricted to a single switch. When a vlan spans multiple switches,
there is no standard mechanism to propagate port-level isolation
information to other switches and, consequently, the isolation
behavior fails in other switches. In this document, the proposal is
to implement the port isolation information at the vlan level. A
particular vlan ID can be configured to be the isolated vlan. All
switches in the network would give special "isolated vlan" treatment
to frames tagged with this particular vlan ID. Thereby, the isolated
vlan behavior can be maintained consistently across all switches in
a Layer 2 network.
HomChaudhuri, Foschiano [Page 10]
Private VLANs August 2007
4. Extending Private Vlans across Switches
Isolated, community and primary vlans can span across switches, just
like regular vlans. Inter-switch link ports need not be aware of the
special vlan type and will carry frames tagged with these vlans just
like they do any other frames.
One of the objectives of the private vlan architecture is to ensure
that traffic from an isolated port in one switch does not reach
another isolated or community port in a different switch even after
traversing an inter-switch link. By embedding the isolation
information at the vlan level and by transporting it along with the
packet, it is possible to maintain a consistent behavior throughout
the network. Therefore, the mechanism discussed in section 2, which
will restrict Layer 2 communication between two isolated ports in
the same switch, will also restrict Layer 2 communication between
two isolated ports in two different switches.
5. A More Flexible IP Addressing Scheme
The common practice of deploying multiple vlans in a network for
security reasons and of allocating a subnet to each vlan has led to
a certain number of inefficiencies in network designs, such as the
suboptimal utilization of the IP addressing space (as exemplified
in the introduction of RFC3069 [3]). Moreover, each subnet requires
a certain number of addresses to be set aside for internetworking
purposes (a subnetwork address, a directed broadcast address,
default gateway address(es), etc.). A high number of used vlans
traditionally translates into a significant number of special
addresses to be consumed.
On the other hand, in a private vlan domain all members can share a
common address space which is part of a single subnet associated to
the primary vlan. An end device can be assigned an IP address
statically or by using a DHCP server connected to a promiscuous port.
Since IP addresses are no longer allocated on a smaller subnet basis
but are assigned from a larger address pool shared by all members in
the private vlan domain, address allocation becomes much more
efficient: fewer addresses are consumed for internetworking purposes
while most of the address space is allotted to end devices, leaving
ample flexibility in the way available addresses are (re-)assigned.
HomChaudhuri, Foschiano [Page 11]
Private VLANs August 2007
6. Routing Considerations
The entire private vlan architecture confines secondary vlans within
the 2nd layer of the OSI model. With reference to Figure 2, the
secondary vlans are internal to a private vlan domain. Layer 3
entities are not directly aware of their existence: to them it
appears as if all the end devices are part of the primary vlan.
With reference to Figure 1, the isolation behavior between devices A
and B is at the Layer 2 level only. Devices A and B can still
communicate at the layer 3 level via the router R. Since A and B are
part of the same subnet, the router assumes that they should be able
to talk directly to each other. That however is prevented by the
isolated vlan's specific behavior. So, in order to enable A and B to
communicate via the router, a proxy-ARP-like functionality needs to
be supported on the router interface.
Security Considerations
In a heterogeneous Layer 2 network that is built with switches from
multiple vendors, the private vlans feature should be supported and
configured on all the switches. If a switch S in that network does
not support this feature, then there may be undesired forwarding of
packets including permanent flooding of Layer 2 unicast frames. That
is because switch S is not aware of the association between primary
and secondary vlans and consequently cannot apply the segregation
rules and constraints characteristic of the private vlan
architecture (an example of one such constraint is explained in [2]
B.1.3). This impact is limited to traffic within the private vlan
domain and will not affect the regular Layer 2 forwarding behavior
on other vlans.
If the private vlans feature is properly deployed, it can be used to
segregate at Layer 2 individual users or groups of users from each
other: this segregation allows a network designer to more
effectively constrain Layer 2 forwarding so as to, for instance,
block or contain unwanted inter-device communication like port scans
or ARP poisoning attacks.
IANA Considerations
This document has no actions for IANA.
HomChaudhuri, Foschiano [Page 12]
Private VLANs August 2007
Deployment Consideration
Cisco Systems has supported the Private Vlans technology in the
Cisco Catalyst family of switches since year 2000.
Changes from the Previous Version
This version incorporates further edits based on reviewer's
feedback, including an expanded section on IP addressing.
Acknowledgements
Many people have contributed to the Private Vlans architecture. We
would particularly like to thank, in alphabetical order, Senthil
Arunachalam, Jason Chen, Tom Edsall, Michael Fine, Herman Hou,
Milind Kulkarni, Kannan Kothandaraman, Prasanna Parthasarathy, Heng-
Hsin Liao, Tom Nosella, Ramesh Santhanakrishnan, Mukundan Sudarsan,
Charley Wen and Zhong Xu for their significant contributions.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] IEEE Std 802.1Q-2003, IEEE Standards for Local and Metropolitan
Area Networks: Virtual Bridged Local Area Networks
Informative References
[3] RFC 3069, Vlan Aggregation for Efficient IP Address Allocation
Authors' Addresses
Marco Foschiano, Cisco Systems, Inc., Via Torri Bianche 7, Vimercate,
MI, 20059, Italy, email address: foschia@cisco.com
Sanjib HomChaudhuri, Cisco Systems, Inc., 170 West Tasman Drive, San
Jose, CA, 95134, email address: sanjib@cisco.com
HomChaudhuri, Foschiano [Page 13]
Private VLANs August 2007
IPR Notice
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full Copyright Notice
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
HomChaudhuri, Foschiano [Page 14]
Private VLANs August 2007
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
This Internet-Draft will expire in August 2007.
HomChaudhuri, Foschiano [Page 15]