ARP request authorization
We advise you not to use ARP authorization, but instead consider using Radius VSA VasExperts-L2-User for subscribers with static IP addresses.
[SSG 7.5+] ARP request authorization mode is designed to tackle the problem of static IP addresses. Subscribers with statically assigned IP addresses don't send DHCP requests, so the VAS Experts DPI cann't authorize such subscribers by DHCP requests. But subscribers with statically assigned IP addresses periodically send ARP requests to their gateway. The VAS Experts DPI can capture such requests to the gateway and send an Access-Request Radius request based on the ARP request content.
The ARP request authorization mode is activated by the bras_arp_auth
configuration option defined in the fastdpi.conf file:
- 0 - ARP request authorization mode is disabled
- 1 - ARP request authorization mode for /30-subnetworks
- 2 - ARP request authorization mode for the gateway
When the autonomous system termination mode is enabled the ARP request authorization is applicable just to such ARP requests that have sender protocol IP address belonging to the terminated autonomous system (with the local and term flags).
ARP request authorization mode for /30-subnetworks
This mode assumes that each static IP address belongs to its /30-subnetwork. When the ARP request containing the target protocol address
field equaled to the /30-subnetwork gateway is received, the VAS Experts DPI sends an authorization requests to the Radius server for the sender hardware address (MAC address of the ARP request source).
ARP request authorization mode for the gateway
In this mode, the Access-Request authorization Radius request is sent if the target protocol address
field contains the gateway address known to the VAS Experts DPI (remember that the gateway addresses are extracted from the DHCP responses and stored in the VAS Experts DPI UDR database).
Radius Access-Request format
User-Name = "a0:b1:c2:d3:00:0a" User-Password = "VasExperts.FastDPI" Calling-Station-Id = "a0:b1:c2:d3:00:0a" Acct-Session-Id = "AF620A00D3C2B1A0" Service-Type = Framed-User NAS-Identifier = "FastPCRF" VasExperts-Service-Type = ARP VasExperts-ARP-SourceIP = 192.168.201.1 VasExperts-ARP-TargetIP = 192.168.1.1
The User-Name attribute is the MAC address of the ARP request source (the sender hardware address
field). The same MAC address is sent in the Calling-Station-Id attribute. The password specified by the radius_user_password
option in the the fastpcrf.conf is the same for all users. This field should not be treated as a subscriber password since it is the system password.
[VAS Expers DPI 8.2+] With a fastpcrf.conf-parameter radius_user_name_arp you can set the User-Name attribute. The parameter specifies a list of identifiers in order of preference: first most preferred, then less preferred. Valid identifier values:
mac
: User-Name = MAC address of the ARP request source in string form "XX:XX:XX:XX:XX:XX"qinq
: if the network is Q-in-Q, then User-Name = "outerVlan.innerVlan"ip
: User-Name = IP address of the ARP request source as a string.
Examples:
# the default radius_user_name_arp parameter # in this case, the User-Name will contain the MAC address, since it is always known for ARP: radius_user_name_arp=mac,qinq # for Q-in-Q networks, you can specify that the User-Name contains the values of qinq tags # in this case, if the ARP request is tagged outerVlan=100, innerVlan=200, then User-Name="100.200" # for untagged ARP requests, User-Name will contain the MAC address of the request source radius_user_name_arp=qinq,mac
The authorization type can be distinguished by the VasExperts-Service-Type VSA-attribute: in case of ARP authorization this attribute will contain the value 6 (ARP).
VasExperts-ARP-SourceIP and VasExperts-ARP-TargetIP VSA-attributes contain values of the ARP request sender protocol address
field (request initiator IP address) and target protocol address
field (target IP address).
Access-Request can contain other attributes described in L3-authorization: NAS-Port-Type, NAS-Port (VLAN number if it is used), NAS-Port-Id (QinQ if it is used) etc.
Authorization response
If Access-Request is authorized, the Radius server will return the Access-Accept containing the Framed-IP-Address attribute, i.e. an authorized IP address. If Framed-IP-Address is not equal to the value of the ARP-requestsender protocol address
field (initiator IP address) then such ARP-request is considered as unauthorized and the VAS Experts DPI drops it.
If the Radius server can not authorize the MAC address then the response should not contain the Framed-IP-Address attribute; in this case the original ARP request is also dropped by the VAS Experts DPI.
In addition to the Framed-IP-Address, Access-Accept can contain the following attributes:
Framed-IP-Netmask
- subscriber subnetwork mask;Session-Timeout
- duration of the authorization, in seconds. If this attribute is not used the authorization will be unlimited (not recommended)VasExperts-DHCP-Gateway
- subscriber gateway
In addition to these attributes, Access-Accept can contain L3 authorization attributes that specify the subscriber properties: policing and activated services, see the L3 authorization attributes.
Access-Reject is processed in the same way as the Access-Accept: if the Framed-IP-Address attribute is used then the APP request source is authorized by the MAC address, Access-Reject must contain the same Framed-IP-Netmask, Session-Timeout and VasExperts-DHCP-Gateway attributes, as described above, it also be specified L3 reject authorization attributes.
The Access-Accept response example:
Framed-IP-Address = 192.168.201.1 Framed-IP-Netmask = 255.255.0.0 Session-Timeout = 3600 VasExperts-DHCP-Gateway = 192.168.1.1 VasExperts-Policing-Profile = "rate_100M" VasExperts-Service-Profile = "1:test1" VasExperts-Enable-Service = "9:on"
"Session-Timeout"
, it should be noted that the lifetime of an entry in the ARP cache is different for different operating systems - from several minutes to 4 hours (for Cisco iOS). Since ARP authorization is performed only at the subscriber request to the gateway, specifying too small Session-Timeout
may lead to the inaccessibility of the Internet for the subscriber: Session-Timeout
has already ended, but there is no ARP request from the subscriber to the gateway yet.