Internet Engineering Task Force Sanjib HomChaudhuri Internet-Draft Cisco Systems, Inc Document: Category: Informational Marco Foschiano Cisco Systems, Inc. June 17, 2004 Expires on December, 2004 Private VLANs: Addressing VLAN scalability and security issues in a multi-client environment Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 December, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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 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 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, 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 Vlans 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] RFC 3069, 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., Via Torri Bianche 7, Vimercate, MI, 20059, Italy email address: foschia@cisco.com Full Copyright Notice Copyright (C) The Internet Society (2004). 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 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.