Insight - White Paper – Passive Optical LAN (POL) Security
Introduction
Passive optical networks (PON) have been in use by service providers for decades now. Whether a Fibre to the Home (FTTH) or Business (FTTB) application, these networks are now the de facto standard for broadband access solutions. In recent years however, the application of a PON network in the Local Area Network (LAN) environment has garnered attention by enterprise customers. This application is known as a Passive Optical LAN or POL and offers significant capital and operational savings. One additional advantage associated with a POL is the security it provides in the LAN segment of an enterprise network.
This paper provides some background and looks at issues focused on security when considering the implementation of a Passive Optical LAN.
Passive Optical LAN Connectivity
Fibre is inherently secure
The benefits of fibre optic cabling are well known in the IT industry. In addition to the advantages of increased network throughput, lower cost, and longer life-span, fibre optic cabling presents a compelling case for increased security due to its physical properties and the way active electronics make use of the fibre connection.
One of the first security topics that comes to mind with fibre networks is the increased complexity of a network intrusion by accessing the physical cable or “tapping in”. To be sure, it is most certainly possible to tap fibre optic cable. But within the context of a POL, it is a very complex operation to introduce a device which is capable of intercepting both the upstream and downstream optical signal while not disrupting the traffic to other ONT devices. As we will describe further in this document the ITU standards used in most POL solution requires 128 bit encryption for traffic presented to end users. After taking into consideration the development and application of such a complex device, the insider threat would likely be relegated to a focus on the end user host devices rather than the transport of end user data traffic. In addition, a POL presents fewer access points where an intruder can gain access to a fibre cable necessary to insert a tap. An active tap would need to be inserted in the upstream aggregate (or feeder fibre) to collect any upstream traffic from other ONTs. This feeder fibre is almost always located above ceiling spaces or locked in equipment rooms where such an intrusion would be quite visible or difficult to access.
Authentication of the ONT
Unlike a managed switch, an ONT within a POL is not capable of being a stand-alone device. In order for an ONT to begin switching traffic, it must first be connected to the optical signal and authenticate to the OLT to receive its assigned channel and VLAN assignments. This authentication process is achieved when the ONT is first discovered on the network using the process defined in the ITU standard G.984.3. The ONT uses a unique on board serial number to authenticate via the OLT. In the same way that a MAC address is unique to a device, these ONT
serial numbers are manufacturer-specific and the OLT can be configured to only allow specific serial numbers on a PON network. For example, an ONT may be recognized initially with the model number and serial number and the management system could be
configured to place the ONT into service immediately. Optionally however, the administrator may configure the system to disallow any ONT to be placed into service without an administrator manually configuring it. The OLT either acknowledges the ONT (via semantically correct matching serial numbers) and allows network connectivity or, depending on the serial number validation check, can refuse access for any given ONT. This process ensures that only known ONT devices are allowed access to the POL network and prevents a rogue ONT from registering.
POL offers encryption for LAN traffic
The GPON protocol uses a point-to-multipoint architecture downstream (to the user) and a point-to-point architecture upstream. The downstream traffic therefore would be subject to interception by anyone connected to downstream fibre interfaces. To counter this threat AES 128 encryption is used on traffic transmitted downstream over the GPON network and therefore only the ONT which as exchanged the key information with the upstream OLT will be able to decrypt the traffic and switch it to the proper Ethernet interface. It would be a rare occurrence to find an enterprise LAN where encryption is employed on end user traffic. Nevertheless, encryption is part of the ITU standard for PON networks and therefore network administrators can benefit by this additional layer of security in their network. In addition to this encryption the physical architecture of a POL does not support the connectivity of other mid-span active components which could pose a potential intrusion point into the network hierarchy. All endpoints must be known and acknowledged ONT devices.
Secure Forwarding
The OLT allows for the use of a feature called Secure Forwarding. When Secure Forwarding is enabled for a VLAN, the service becomes IP session aware and snoops the DHCP offer messages to the ONTs and caches the allocated DHCP IP address information. Any DHCP offer will be translated from broadcast traffic to unicast traffic and only forwarded to the intended user. The OLT will then only allow the flow of traffic from end user ports if the source address is of the same address that was previously learned from the specific ONT user port. If the traffic does not originate from the correct address, the traffic is discarded. Also for devices attached with static IP addresses, a static
entry is required on the ONT port when secure forwarding is enabled so the OLT can compare the configured IP address to the source address of the statically configured device in the data frame. If they do not match, the traffic is discarded. Therefore, a more secure capability is achieved preventing a user connecting to the ONT port and attempting to perform a hopping or spoofing attack. This feature can be enabled on any VLAN in the system.
Malicious use of MAC Addresses for Traffic Manipulation
The ONT and the OLT maintain MAC address tables populated by the traffic forwarded on the network. There exists a possibility that an end user can inject traffic from many (spoofed) MAC sources in an attempt to overwhelm the OLT Forwarding Database (MAC) tables. This could result in undesirable behaviour within the OLT denying service availability until the attack has subsided. As a mitigation the OLT is configured to implement a limit on the number of MAC addresses that can be learned from the ONT, provisionally this is set at a limit of 4, 16 or 64 MAC addresses per ONT port depending on the service type. These limits can be further tailored by the administrator as desired.
The VLAN itself can also be set to limit MACs learned across the entire broadcast domain. These are set to 4000 per service nominally to prevent a MAC storm/DoS
attack affecting all services. These limits can be increased or decreased as desired. If the solution is deployed where the customer does not believe there is a threat to the network facing FDB table, this artificial limit can be removed.
MAC Movement
In service provider networks, a default behaviour is to block MAC Movement within the OLT as a security measure to prevent spoofing and theft of service threats. In a POL environment however, there will be a need to configure services to allow this movement such as devices using WiFi services and moving between two different WAP’s that are hosted via 2 different PON cards. The MAC movement feature therefore is implemented to facilitate this requirement for POL applications. The administrator may optionally implement the default behaviour as required for 3rd party network services, contractors, or public facing networks in which MAC movement is not desired.
Access Control List
It is possible to configure access control lists (ACL) which filter network traffic based on MAC or IP address information. These filters are then applied to the various VLAN services configured for on the OLT.
IP filter policies match criteria associated with traffic ingressing or egressing a service. Matching criteria to drop or forward IP traffic include:
- Source IP address and mask
- Destination IP address and mask
- Protocol (such as TCP, UDP, etc.)
- IPv6 Protocol
- Source port/range
- Destination port/range.
- DSCP marking
- ICMP code
- ICMP type
- IPv4 Fragmentation
- TCP-ACK/SYN flags
- Option present
MAC filter policies match criteria that associate traffic with an ingress or egress SAP. Matching criteria to drop or forward MAC traffic include:
- Source MAC address and mask
- Destination MAC address and mask
- Dot1p and mask
- Ethertype
Encapsulation type (802dot2-llc, 802dot2-snap, ethernet_II and any)
802.1xPort Security
The 802.1X capabilities of POL solution complies with both the IEEE 802.1X and the CCSA specification. Each 802.1X-enabled ONT user port is by default in a closed status and successful authentication is needed to open the port. Packets from unauthenticated users are dropped until an 802.1x session is successful after authentication by an external RADIUS or server. Passwords, RADIUS secrets, and other authentication data are encrypted in such a way in the system database that the plain form cannot be derived from the system database when this is not required for normal operation (for example, passwords for PAP local authentication). In cases where it is necessary to retrieve the plain text form, encryption (MD5) is used to avoid unauthorized retrieval. This applies for authentication on all the management interfaces and on all the user interfaces.
PON Card Security
Each PON card can provide storm-control features which protect against broadcast storms and unknown multicast and unicast traffic attacks. The system also supports IP and MAC address binding as well as the following safety functions which throttle traffic on the Ethernet services when a set threshold is crossed:
- IP/MAC anti-spoofing
- anti-DOS attack
- anti-ARP attack
- anti-ICMP attack
- anti-BPDU attack
CPU overload protection
Management Server Security
Our POL Command Center (PCC) is the network management server used in our POL portfolio. It is based on a Redhat Linux Enterprise x86 platform that can optionally run on
a virtual machine. The PCC server provides network administrators with an SSL secured, browser-based GUI for performing installation, maintenance, troubleshooting, and monitoring of the POL network. The Redhat server affords the enterprise organization with a feature rich suite of applications and options for hardening the management interface of the network. First, the management network itself can be configured out-of-band with the end user traffic. This ensures that only network administrators who have
access to the core network (via an entirely separate network segment or VPN connection) may access the management functions of the POL network. PCC also supports the use of the built-in firewall provided by the RedHat OS (iptables), password aging and locking parameters, port security, system control file changes to guard against SYN flood attacks, IP forwarding, and route filters. The administrator can additionally administer a variety of management and security policies for the OLT including:
- RADIUS Authentication
- SNMP (v2 and v3)
- Authorization protocols (MDA5 and SHA)
- Encryption protocols (DES, AES128, AES192, AES256)
- Configurable SNMP trap destinations
- Support for SYSLOG
The Software for both the OLT and ONTs is stored on the management server for upgrade and newly discovered ONTs. There is no port or procedure by which an end user on an ONT could access these files and manipulate their own hardware and firmware combination. The connection between the OLT and management server for these software transfers supports the SFTP protocol and any non-secure protocols such as FTP and TFTP can be optionally disabled. The management traffic between PCC and the OLT can also be further secured with SSHv3 and the use of a dedicated management VLAN which can utilize access control lists to further constrain the number of devices which can access this service.
Conclusion
Enterprise organizations must deploy standardized and robust security policies to defend not only against external threats but also those network attacks that can occur in the LAN segment. The choice to migrate an enterprise LAN to a POL cannot be made without careful consideration of the impact of existing security mechanisms and processes. Fortunately, nearly all the features a network administrator would need to deploy in the LAN environment are already incorporated in our POL solution. By coupling these strategies with the inherent security of fibre infrastructures and PON management systems, a truly secure and future proof network can be realized.
