The IEEE 802.1Q VLAN header extends the IEEE 802.3 Ethernet protocol’s basic capability (see the Cisco Tech Note “Inter-Switch Link and IEEE 802.1Q Frame Format,”
referenced in the “Further Reading” section). The IEEE 802.1Q VLAN header format consists of the original IEEE 802.3 Ethernet frame header, plus two additional 2-byte fields inserted as shown in Figure B-10. (A reference for IEEE 802.1Q is included in the “Further Reading” section.) The IEEE 802.1Q VLAN header fields shown in Figure B-10 are listed and described in Table B-10, along with a brief description of some known modifications or spoofs to relevant header fields that have been seen used in common VLAN attacks.
Figure B-10 IEEE 802.1Q VLAN Frame Header
Table B-10 IEEE 802.1Q VLAN Frame Header Fields and Their Security Implications
Field Length Header Field Header Value and Description
7 bytes Preamble
(PRE)
This field provides an alternating pattern of 1s and 0s (binary 10101010), indicating to receiving stations that a frame follows, and used to synchronize receiving stations with the incoming bit stream on the wire. The specific pattern varies depending upon the specific Ethernet encoding used, which is outside the scope of this book.
continues 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 2 3 1 1 2 3 4 5 6 7 8 9 10 11 12
VLAN Identifier Code (VLAN ID) Tag Protocol Identifier
(TPI)
User Priority
(QoS)
IEEE 802.1Q Header/Tag (4 Bytes)
CFI
7 1 6 6 2 4
Preamble Destination Address
Frame Check Sequence Source
Address
SFD TPI
2
TCI
2
Type/Length
46 to 1500
Payload
Maximum Frame Size 1522 Bytes
Security Implications: No security implications exist because this field is used solely for physical and data link layer bit and Ethernet frame synchronization. Of course, in switchless Ethernet topologies, a faulty or malicious host may continuously transmit bits on the wire, causing collisions and preventing other hosts from transmitting. This does not apply to the switched Ethernet topologies, which are most commonly deployed today.
1 byte Start of Frame Delimiter (SFD)
This field provides an alternating pattern of 1s and 0s, ending with two consecutive 1 bits (binary 10101011), indicating that the next bit is the leftmost bit in the leftmost byte of the frame’s destination address.
Security Implications:Similar to the Preamble above, no security implications exist because this field is used solely for physical and data link layer bit and Ethernet frame synchronization.
6 bytes Destination Address (DA)
This field identifies the MAC address of the station(s) that should receive the Ethernet frame. The leftmost bit in the DA field indicates whether the address is an individual address (indicated by a 0) or a group address (indicated by a 1). The second bit from the left indicates whether the DA is globally administered (indicated by a 0) or locally administered (indicated by a 1). The remaining 46 bits are a uniquely assigned value that identifies a single station (unicast), a defined group of stations (multicast), or all stations on the network (broadcast).
Security Implications: In the legitimate case, the IP protocol dynamically resolves IP address to MAC address bindings, and vice versa, using ARP and RARP. In the malicious case, an attacker may craft the destination address within an Ethernet frame in an attempt to launch ARP spoofing, switch spoofing, double 802.1Q encapsulation, private VLAN, and STP attacks, as outlined in Chapter 2.
6 bytes Source
Address (SA)
This field identifies the MAC address of the sending station.
The SA must always be an individual (unicast) address, and the leftmost bit in the SA field is always 0.
Table B-10 IEEE 802.1Q VLAN Frame Header Fields and Their Security Implications (Continued)
Field Length Header Field Header Value and Description
Security Implications:In the legitimate case, the sending host inserts its MAC address in this field. In the malicious case, an attacker may craft the MAC source address within an Ethernet frame in an attempt to launch CAM table overflow and ARP spoofing attacks, as outlined in Chapter 2. Note that ARP spoofing affects both source and destination Ethernet addresses. The attacker first advertises itself as an IP host using a point hosts may begin transmitting packets destined to the spoofed IP host to the attacker’s Ethernet address. For more information on ARP spoofing attacks, refer to Chapter 2.
2 bytes Tag Protocol Identifier (TPI)
The TPI field indicates that the Ethernet frame is an IEEE 802.1Q VLAN tagged frame. IEEE 802.1Q VLAN tagged frames have a TPI value of 0x8100.
Security Implications: It is possible that if this field indicates a value that does not represent the 802.1Q VLAN tag, a poorly written network stack may improperly process such packets, resulting in a DoS or buffer overflow condition.
2 bytes Tag Control Information (TCI)
The TCI field consists of three subfields:
• User Priority (3 bits): Defines user priority, giving eight (23) priority levels for the frame as specified by the IEEE 802.1P standard.
• Canonical Format Identifier (1 bit): Provides compatibility between Ethernet and Token Ring networks. If the value of this field is 1, the MAC address is in noncanonical format. If the value is 0, the MAC address is in canonical format. A value of 0 is used within Ethernet-only networks.
• VLAN ID Code (12 bits): Identifies the VLAN to which the frame belongs. This field allows for up to 4096 possible VIDs (212). A value of 0 is used to identify priority frames and value 4095 (FFF) is reserved, so the maximum possible VLAN configurations are 4094.
Security Implications:An attacker may craft the VLAN ID within an 802.1Q VLAN tagged Ethernet frame in an attempt to launch switch spoofing and double 802.1Q encapsulation attacks, as outlined in Chapter 2.
continues Table B-10 IEEE 802.1Q VLAN Frame Header Fields and Their Security Implications (Continued)
Field Length Header Field Header Value and Description
2 bytes Type/Length This field indicates either the number of data bytes that are contained in the Data field of the frame (length) or the frame type ID if the frame is assembled using an optional format (Ethernet II frame). Specifically, if the Type/Length field value is less than or equal to 1500 bytes (0x05DC), the frame is considered an IEEE 802.3 frame. If the Type/Length field value is greater than 1536 bytes (0x0600), it is considered an Ethernet II frame. A value of 0x0800, for example, represents an Ethernet II encapsulated TCP/IP packet. Similarly, a value of 1500 (0x05DC) represents an IEEE 802.3 frame with a total frame length of 1518 bytes, including Destination Address, Source Address, Type/Length, and FCS header fields. The IEEE 802.2 LLC/SNAP header located within the Data field is outside the scope of this book.
Security Implications: DoS attacks may use a value that does not represent the true frame length or Ethernet II subprotocol identifier. A poorly written network stack may improperly process these packets, resulting in a DoS or buffer overflow condition. Note, many Ethernet vendors have also added support for jumbo Ethernet frames to increase overall networked application throughput and to accommodate VLAN and MPLS header information.1 Jumbo frames are frames that are bigger than the standard IEEE 802.3 Ethernet frame size of 1518 bytes. Because jumbo frames are not part of the IEEE standard, the definition of jumbo frame size is vendor-dependent.
46 to 1500 bytes
Data/Payload This field carries the payload of the Ethernet frame. The data field can be anywhere from 46 to 1500 bytes in size.
Security Implications: In the legitimate case, if the frame does not have 46 bytes’ worth of information to convey, the station pads the end of this field with 1s. Short frames (runts) are typically an indication of collisions (on old switchless topologies). In the malicious case, runts could be injected on the network artificially.
4 bytes Frame Check
Sequence (FCS)
This field contains a 32-bit cyclic redundancy check (CRC) value. The FCS is generated over the DA, SA, Type/Length, and Data fields, and excludes the Preamble and SFD.
Security Implications:The FCS is created by the source MAC and is recalculated by receiving MACs to check for damaged frames. Frames with invalid checksums are discarded silently, and hence no useful attacks seem plausible that manipulate or spoof this header field.
1. “Jumbo/Giant Frame Support on Catalyst Switches Configuration Example.” (Doc. ID: 24048.) Cisco Documentation.
http://www.cisco.com/warp/public/473/148.html.
Table B-10 IEEE 802.1Q VLAN Frame Header Fields and Their Security Implications (Continued)
Field Length Header Field Header Value and Description
MPLS Protocol Header
MPLS is deployed for a variety of applications, including Layer 3 IP VPNs, Layer 2 VPNs, traffic engineering, and fast network convergence (reroute). Most current MPLS deployments are intradomain, where MPLS labeled packets are not exchanged between external or untrusted peers. With the growth of interdomain MPLS VPNs and Carrier Supporting Carrier (CsC) services, MPLS labeled packets are increasingly being exchanged at interprovider boundaries. This section reviews the MPLS label header formats, the label fields, and associated security implications.
RFC 3032 and RFC 4182 define the MPLS label stack encoding (see the “Further Reading”
section for links to these RFCs). For IP-based MPLS services, the MPLS header appears after the Layer 2 headers (for example, Ethernet) but before the IP packet, as shown in Figure B-11. The MPLS header is represented by a label stack that consists of a sequence of label stack entries. Each label stack entry is 4 bytes in length. The depth of the label stack often varies between MPLS networks and is dependent upon the MPLS services deployed (for example, MPLS VPNs, MPLS TE/FRR, and AToM). The MPLS label format contains four fields, as illustrated in Figure B-12. Each of these fields is listed and described in Table B-11, along with a brief description of applicable security considerations.
Figure B-11 MPLS Encapsulation Example of an IP Packet Transported over an Ethernet Interface
IP Packet IP Packet Length
MPLS Label Stack
MPLS Encapsulated IP Packet
N x 32 Bits
(N = Number of Label Stack Entries)
7 1 6 6 2 46 to 1500 4
Preamble Destination
Address Payload
Frame Check Sequence Source
Address
SFD Type/Length
Maximum Frame Size 1518 Bytes
Figure B-12 MPLS Label Stack Encoding
Table B-11 MPLS Label Fields and Security Considerations
Bit Offset Header Field Header Value and Description 0–19
(20 bits)
Label This field carries the actual value of the MPLS label, which may be assigned by a variety of MPLS label distribution protocols, including but not limited to LDP, BGP, and M-BGP.1,2,3
Security Implications:Label distribution protocols allocate labels per IP prefix or Forwarding Equivalence Class (FEC). An FEC is used by MPLS routers to determine how packets are mapped to MPLS label switched paths (LSP).
Received MPLS packets should also always be discarded on interfaces where no MPLS application is enabled. It is plausible that a poorly written network stack may improperly process MPLS packets on an interface not enabled for MPLS.
Such a condition would facilitate MPLS label spoofing, enabling attacks against downstream devices.
MPLS provides for the discarding of any labeled packet having an invalid label.
This is analogous to dropping IPv4 packets having no corresponding route (or next hop) in the local IP routing table. A label is considered valid if the label was advertised by the MPLS router itself in accordance with label distribution protocols. Conversely, labels are not verified against an MPLS source (for example, using RPF checking), and the MPLS label space is not global (network wide). Labels are local to, and assigned by, each individual transit MPLS router in support of the label-switching paradigm. An MPLS router considers a label invalid if it was not assigned by itself from its own label pool.
Labels are allocated from a global system pool within an MPLS router and not per interface (the exception being cell mode MPLS, which is not widely deployed). A global label pool within the MPLS router makes label spoofing less difficult because the label of received MPLS packets is not verified against the ingress router interface or MPLS source. Hence, as long as the ingress router interface is enabled for MPLS and the label received is valid within the local MPLS router’s global label pool, the MPLS packet is forwarded downstream based on the received label’s associated LSP. Given that interface IP ACLs do not apply to MPLS label encapsulated packets, label spoofing may allow unauthorized access and reachability to downstream network devices and to secure VPNs. For this reason, MPLS is not widely deployed using Inter-AS VPN options (b) and (c) between untrusted peers, as outlined in Chapter 2. If Inter-AS 4
0 8 12 16 20 24 28 31
Bits
Label EXP S TTL
0
VPN is configured using options (b) and (c), then all valid labels (spoofed or not) will be accepted. Hence, there must be a trust relationship between peers doing Inter-AS VPN options (b) and (c). Conversely, the CsC configuration maintains label bindings per VRF (or VPN). This enables label spoofing avoidance mechanisms that verify that the MPLS labels of packets received are, in fact, associated with the assigned VRF. If not, the MPLS labeled packets are discarded. Hence, within a CsC configuration, the inherent label spoofing avoidance mechanisms ensure that routing and address separation between VPNs is maintained.
20–22 (3 bits)
Experimental Use (EXP)
This field is reserved for experimental use. However, it is widely used for QoS classification and drop precedence of MPLS packets. The value within this field may range from 0 through 7.
Security Implications:When IP packets are encapsulated within MPLS, Cisco IOS will copy the (3-bit) IP precedence value into the MPLS EXP of each imposed label entry by default. Attackers may attempt to exploit this default behavior by marking malicious IP traffic with high priority—for example, IP precedence values 5–7. In this way, such malicious traffic may receive high- priority treatment (EXP 5–7) within the MPLS network. Further, using this technique, attacks may be launched against high-priority traffic classes, which may trigger a DoS condition or adversely impact network SLAs. To change this default behavior, an interface QoS policy must be applied using Cisco MQC.
23 (1 bit)
Bottom of Stack (S)
This field (or bit) indicates whether the associated label entry is the bottom of the label stack. A value of 1 represents the last label stack entry. Conversely, all other label stack entries have a value within this field of 0. Per RFC 3032, the top of the label stack appears earliest in the packet, and the bottom appears latest. The encapsulated IP packet immediately follows the bottom label stack entry, which has the S bit set to 1.
Security Implications: No useful attacks seem plausible that manipulate or spoof this header field. It is plausible that a poorly written network stack may improperly process MPLS packets with an unexpected S bit. For example, setting a value of 0 when the label entry is the bottom label of the label stack or a value of 1 when the label entry is not the bottom of the label stack should cause the router to silently discard such packets. A poorly written network stack may incur a buffer overflow or DoS condition, making it susceptible to such an attack.
continues Table B-11 MPLS Label Fields and Security Considerations (Continued)
Bit Offset Header Field Header Value and Description
Further Reading
Rosen, E., D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, and A. Conta.
MPLS Label Stack Encoding. RFC 3032. IETF, Jan. 2001. http://www.ietf.org/rfc/
rfc3032.txt.
24–31 (8 bits)
Time to Live (TTL)
This field carries the MPLS packet’s TTL value. Similar to the IP TTL, the MPLS TTL specifies the maximum number of links (hops) that the MPLS packet may be forwarded over. This counter is decremented by each MPLS router processing the packet while forwarding it toward its destination. When the TTL value reaches 0, the MPLS packet is discarded. This prevents MPLS packets from looping endlessly, as would otherwise occur during accidental forwarding loops, for example. This 8-bit value can range anywhere from 255 to 0. The processing of this field is further described in RFC 3443.4
Security Implications:When IP packets are encapsulated within MPLS, Cisco IOS will copy the (8-bit) IP TTL value into the MPLS TTL of each imposed label entry by default. This makes MPLS routers visible via IP traceroute, and enables IP packets to TTL expire within the MPLS network. Attackers may attempt to exploit this default behavior for reconnaissance purposes or to launch transit DoS attacks or ICMP reflection attacks,5 as outlined in Chapter 2. To change the default behavior and mitigate the risk of such attacks, IP to MPLS TTL propagation may be disabled using the IOS no mpls ip propagate-ttl forwarded CLI command, as described in Chapter 7.
1. Andersson, L., P. Doolan, N. Feldman, A. Fredette, and B. Thomas. LDP Specification. RFC 3036. IETF, Jan. 2001.
http://www.ietf.org/rfc/rfc3036.txt.
2. Rekhter, Y., and E. Rosen. Carrying Label Information in BGP-4. RFC 3107. IETF, May 2001.
http://www.ietf.org/rfc/rfc3107.txt.
3. Rosen, E., and Y. Rekhter. BGP/MPLS IP Virtual Private Networks (VPNs). RFC 4364. IETF, Feb. 2006.
http://www.ietf.org/rfc/rfc4364.txt.
4. Agarwal, P., and B. Akyol. Time To Live Processing in MPLS Networks. RFC 3443. IETF, Jan. 2003.
http://www.ietf.org/rfc/rfc3443.txt.
5. Bonica, R., D. Gan, D. Tappan, and C. Pignataro. ICMP Extensions for Multiprotocol Label Switching. RFC 4950. IETF, Aug. 2007.
http://www.rfc-editor.org/rfc/rfc4950.txt.
Table B-11 MPLS Label Fields and Security Considerations (Continued)
Bit Offset Header Field Header Value and Description
Rosen, E. Removing a Restriction on the Use of MPLS Explicit NULL. RFC 4182.
IETF, Sept. 2005. http://www.ietf.org/rfc/rfc4182.txt.
Stevens, W. R. TCP/IP Illustrated, Volume 1. Addison-Wesley Professional, 1993.