Internet Engineering Task Force Sanjib HomChaudhuri
Internet-Draft Cisco Systems, Inc
Document: <draft-sanjib-private-vlan-01.txt>
Category: Informational Marco Foschiano
Cisco Systems, Inc.
May 6, 2004
Expires on November, 2004
Private VLANs: Addressing VLAN scalability and security issues in
a multi-client environment.
Status of this Memo
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026 except that the right to produce derivative
works is not granted.
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.
This Internet-Draft will expire in November, 2004.
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 layer 2 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.
1. Introduction
In an Ethernet network, the data frames contain a 'vlan id' field. The
IEEE 802.1Q standard 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 L3 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.
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 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 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.
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 the
router or multi-layer switch. 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 may communicate with one
another and may 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.
-----------
| 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
i1, i2 - Isolated switch ports
c1, c2 - Community switch ports
p1 - Promiscuous switch ports
t1 - inter-switch link port
Fig 1. Private vlan and switch ports
--------------------------------------
With reference to Figure 1, each of the port types are 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.
Community ports: A community port (c1 or c2) is part of a group
of ports. The ports within the 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.
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.
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 may 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.
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.
3.1. Isolated Vlan
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 can 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 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 may 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.
4. Extending private vlans across switches
Isolated, community and primary vlans can span across switches, just
like regular vlans. Interswitch 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 interswitch 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, that
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. IP addressing scheme
For discussion on this topic, refer to RFC3069. The following is
a brief discussion added for the sake of completeness.
All members in a private vlan domain share a common address space
which is allocated for the primary vlan. A customer device is
assigned an IP address manually or by using a DHCP server connected
to a promiscuous port. Since IP addresses are no longer 'block
allocated' on a per vlan basis but are assigned from an address pool
shared by all members in the private vlan domain, address allocation
becomes much more efficient.
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.
7. Security Considerations
In a heterogeneous layer 2 network that is built with switches
from multiple vendors, the private vlans feature must be supported
and configured in all switches. If a switch S in that network does
not support this feature, then there may be unexpected 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. This impact is limited to traffic within the
Private Vlans domain and will not affect regular layer 2 forwarding
behavior on other vlans.
8. Deployment consideration
Cisco Systems has supported the private vlan technology in the
Cisco Catalyst family of switches since year 2000.
9. Acknowledgement
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.
10. References
[1] IEEE Std 802.1Q-1998, IEEE Standards for Local and Metropolitan
Area Networks: Virtual Bridged Local Area Networks
[2] RFC3069, Vlan Aggregation for Efficient IP Address Allocation
11. Author's address
Sanjib HomChaudhuri, Cisco Systems, Inc., 3550 Cisco Way , San Jose,
CA, 95134 email address: sanjib@cisco.com
Marco Foschiano, Cisco Systems, Inc., 170 West Tasman Drive, San Jose,
CA, 95134 email address: foschia@cisco.com