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]