- play_arrow AAA for Subscriber Management
- play_arrow AAA for Subscriber Management
- play_arrow RADIUS for Subscriber Management
- RADIUS Servers and Parameters for Subscriber Access
- Storage and Reporting of Interface Descriptions to Uniquely Identify Subscribers
- Session Options for Subscriber Access
- RADIUS NAS Port Attributes and Options
- RADIUS Logical Line Identification
- RADIUS Authentication and Accounting Basic Configuration
- RADIUS Reauthentication As an Alternative to RADIUS CoA for DHCP Subscribers
- Configuring RADIUS Reauthentication for DHCP Subscribers
- RADIUS Accounting for Subscriber Access
- Verifying and Managing Subscriber AAA Information
- Session Termination Causes and RADIUS Termination Cause Codes
- AAA Termination Causes and Code Values
- DHCP Termination Causes and Code Values
- L2TP Termination Causes and Code Values
- PPP Termination Causes and Code Values
- VLAN Termination Causes and Code Values
- play_arrow Domain Maps for Subscriber Management
- play_arrow Testing and Troubleshooting AAA
- play_arrow RADIUS Dictionary Files
- Junos OS Release 15.1 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 16.1 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 16.2 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 17.1 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 17.4 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 18.2 Subscriber Management RADIUS Dictionary [DCT]
- Junos OS Release 18.4 Subscriber Management RADIUS Dictionary [DCT]
-
- play_arrow DHCP and DHCPv6 for Subscriber Management
- play_arrow DHCP for Subscriber Management
- DHCP Overview
- DHCP Access Profiles for Subscriber Authentication and Accounting Parameters
- Overrides for Default DHCP Local Server and DHCP Relay Configuration Settings
- Delaying DHCP Offer and Advertise Responses to Load Balance DHCP Servers
- DHCP Options and Selective Traffic Processing
- Using DHCP Option 82 Information
- Default Services for DHCP Subscribers
- DHCP Client Attribute and Address Assignment
- DHCP Lease Times for IP Addresses
- DHCP Leasequery Methods
- DHCP Client Authentication With An External AAA Authentication Service
- Receiving DHCP Options From a RADIUS Server
- Common DHCP Configuration for Interface Groups and Server Groups
- Number of DHCP Clients Per Interface
- Maintaining DHCP Subscribers During Interface Delete Events
- Dynamic Reconfiguration of Clients From a DHCP Local Server
- Understanding Deferred NACK on DHCP Reconfigure Abort
- Conserving IP Addresses Using DHCP Auto Logout
- DHCP Short Cycle Protection
- DHCP Monitoring and Management
-
- play_arrow IPv6 for Subscriber Management
- play_arrow IPv6 for Subscriber Management
- Introduction to IPv6 Addresses
- Migration to IPv6 Using IPv4 and IPv6 Dual Stack
- IPv6 WAN Link Addressing with NDRA
- IPv6 WAN Link Addressing with DHCPv6 IA_NA
- Subscriber LAN Addressing with DHCPv6 Prefix Delegation
- WAN and LAN Addressing Using DHCPv6 IA_NA and DHCPv6 Prefix Delegation
- Designs for IPv6 Addressing in a Subscriber Access Network
- Dual-Stack Access Models in a DHCP Network
- Dual-Stack Access Models in a PPPoE Network
- Best Practices for Configuring IPv4 and IPv6 Dual Stack in a PPPoE Access Network
- Dual Stack for PPPoE Access Networks Using DHCP
- Dual Stack for PPPoE Access Networks Using NDRA
- IP Demultiplexing Interfaces on Packet-Triggered Subscriber Services
- Conservation of IPv4 Addresses for Dual-Stack PPP Subscribers Using On-Demand IPv4 Address Allocation
- Dual Stack Subscribers Monitoring and Management
-
- play_arrow Packet Triggered Subscriber Services
- play_arrow Packet Triggered Subscriber Services
-
- play_arrow Address-Assignment Pools for Subscriber Management
- play_arrow Address-Assignment Pools for Subscriber Management
-
- play_arrow DNS Addresses for Subscriber Management
- play_arrow DNS Addresses for Subscriber Management
-
- play_arrow M:N Subscriber Redundancy
- play_arrow Access Node Control Protocol and the ANCP Agent for Subscriber Services
- play_arrow Access Node Control Protocol and the ANCP Agent for Subscriber Services
-
- play_arrow Diameter Base Protocol and its Applications
- play_arrow Diameter Base Protocol and its Applications
- Diameter Base Protocol
- Gx-Plus for Provisioning Subscribers
- 3GPP Policy and Charging Control for Wireline Provisioning and Accounting
- NASREQ for Authentication and Authorization
- JSRC for Subscriber Provisioning and Accounting
- JSRC and Subscribers on Static Interfaces
- Monitoring and Management Diameter Information
- Tracing Diameter Base Protocol Events for Troubleshooting
- Troubleshooting Diameter Networks
- Monitoring and Managing Static Subscriber Information
- Tracing Static Subscriber Events for Troubleshooting
-
- play_arrow Configuration Statements and Operational Commands
DHCPv6 Client MAC Address Validation to Prevent Session Hijacking
Starting in Junos OS Release 18.2R1, a nonconfigurable mechanism exists for DHCPv6 local servers and relay agents to drop packets from a client with an unknown MAC address to prevent a malicious client from hijacking a session. When a DHCPv6 local server or relay agent receives a solicit message from a client to establish a session, it extracts the client MAC address (link-layer address) from the message and adds it to a local table that maps MAC addresses to client IPv6 addresses or prefixes. The server or relay agent uses this table to compare MAC addresses received in subsequent messages from the client to validate whether the client is known; if not, it is assumed to be malicious and the control packet is dropped. Because the packet has failed MAC validation, the Client MAC validation counter is incremented.
The assumption here is that the client sending the initial solicit message is benign. In this case, client MAC address validation protects against a malicious client trying to hijack a client session that is already established or in the process of being established. The client MAC address validation does not protect against a malicious client that sends the initial solicit message.
When no relay agent is present; the local server shares a link or access node with the client. In this case, the local server extracts the client MAC address directly from the Layer 2 header of the DHCPv6 control packet and validates the address against the table.
When a relay agent is present, validation is performed by the relay agent. RFC 6939, Client Link-Layer Address Option in DHCPv6, enables DHCPv6 relay agents that are connected to the same link as a DHCPv6 client to extract the client MAC address from the Ethernet (Layer 2) header in the received DHCPv6 control packet. The packet includes the client link-layer address as the source MAC address in its Ethernet header. The relay agent validates the MAC address against the value for this client that is stored in its local table. If the address does not match it drops the packet.
If the address is validated by the relay agent and the packet is not dropped, then the relay agent also includes that MAC address in option 79 (Client Link-Layer Address) in the header of the DHCPv6 relay-forward message that the relay agent sends to the local server. When the DHCPv6 local server receives a relay-forward message from a relay agent, the server automatically examines the message for the presence of option 79. When the option is present, the local server extracts the MAC address and validates it against the value stored in the table for this client. If option 79 is not present, the local server cannot perform the validation.
However, because the relay agent has already validated the address, the local server should not discover any address mismatches.
The following scenarios describe possible relay agent configurations and their implications for server validation:
A single Lightweight DHCPv6 Relay Agent (LDRA; Layer 2) is connected between the client and the server. If the LDRA did not add option 79 to the header, then the local server extracts the client MAC address directly from the Layer 2 header of the DHCPv6 control packet and validates the address against the table.
One or more Layer 3 DHCPv6 relay agents are connected between the client and the server. In this case, the server checks for option 79 in the header of the innermost relay-forward message sent by the relay agent. The innermost header is viewed because it is the header modified by the first relay agent reached by the client. Other headers are added by subsequent relay agents in the path. These agents do not add option 79 and they cannot extract the MAC address from the first relay agent’s Layer 2 header, because that agent changes the address to its own address, as does each subsequent relay agent.
A combination of a client-facing Layer 2 (LDRA) relay agent followed by one or more Layer 3 DHCPv6 relay agents is connected between the client and the server. The server checks for option 79 in the innermost header of the relay-forward message sent by the relay agent. If the LDRA did not add option 79 to the header, it is probably not capable of changing the MAC address in the header to its own. Consequently, the server next checks the second innermost header for the option, because the first Layer 3 relay agent may have extracted the MAC address and added option 79 to convey the address.
No configuration is required to enable validation of client
MAC addresses. You can view how many control packets have been dropped
because of a validation failure by issuing the show dhcpv6 server
statistics command.
Benefits of Client MAC address Validation
Client MAC address validation enables you to prevent a DHCPv6 client with an unknown MAC address from hijacking a session established by a known client. Usage of DHCPv6 client MAC addresses is likely to increase as it is convenient for correlating DHCPv4 and DHCPv6 clients in a dual-stack environment.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
