Diameter Application NASREQ
This chapter provides information about Diameter Application NASREQ.
Topics in this chapter include:
Applicability
The information and configuration in this chapter are based on SR OS Release 19.10.R1.
This chapter covers the Diameter NASREQ application in combination with the Diameter base protocol implementation that is available from SR OS Release 16.0.R4 onward (configured in the aaa CLI context as diameter node). The legacy Diameter base implementation (configured in the aaa CLI context as diameter-peer-policy) is supported in maintenance mode only, without any further feature enhancement planned. Nokia recommends using or transitioning to the new Diameter base protocol implementation. See also the Diameter Base Protocol: Establishing a Diameter Peer Connection chapter of this Advanced Configuration Guide
Overview
NASREQ is defined in RFC 7155, Diameter Network Access Server Application, and uses the Diameter base protocol defined in RFC 6733, Diameter Base Protocol. The purpose of NASREQ in SR OS is to provide subscriber authentication and authorization. NASREQ provides functionality that is also available via RADIUS but uses the Diameter protocol instead.
NASREQ complements the other Diameter applications supported in SR OS:
Gx provides advanced authorization capabilities for subscribers and usage monitoring, and interfaces with a Policy and Charging Rules Function (PCRF).
Gy or Diameter Credit Control Application (DCCA) provides on-line charging functionality, and interfaces with an On-line Charging Server (OCS).
NASREQ provides subscriber authentication and authorization, and interfaces with a AAA server.
These three Diameter applications use the Diameter base protocol, which is described in the Diameter Base Protocol: Establishing a Diameter Peer Connection chapter of this Advanced Configuration Guide. That chapter also describes the configuration of the Diameter base protocol, which is very similar for all supported Diameter applications, and is not repeated in this chapter.
When a subscriber connects to the BNG, NASREQ is triggered, as would have been the case with RADIUS authentication. NASREQ trigger shows a sample call flow for NASREQ and Gx applications when an IPoE IPv4 subscriber session connects. The supported NASREQ messages are Authentication and Authorization Request (AAR) and Authentication and Authorization Answer (AAA), and the BNG assumes that the AAA server does not maintain session state. Therefore, there is no need for the BNG to send a message to the AAA server to indicate when the subscriber has ended the session. The BNG negotiates with the AAA server that it expects a stateless behavior by sending the Auth-Session-State AVP with value NO_STATE_MAINTAINED (1) as defined in RFC 6733, and the AAA server must confirm that by sending back the AVP with the same value.
As shown in NASREQ trigger, NASREQ is triggered when the DHCP discover is received, while Gx, using the Credit Control Request (CCR-I) and Credit Control Answer (CCA-I) messages, is triggered at the end, after the IP address allocation.
Supported NASREQ AVPs in AAA are listed in the Triple Play Service Delivery Architecture Guide, and include AVPs for subscriber identification, profiles, service selection, address allocation, and so on.
All the NASREQ AVPs are also supported by RADIUS, and their meaning is described in the RADIUS Attributes Reference Guide.
Some AVPs, such as SLA profile and subscriber profile strings can be obtained from both NASREQ in the authentication phase and from Gx in the authorization phase. In this case, the last received value from Gx is used for the subscriber session creation.
The AAA server authenticates a subscriber based on a password. For IPoE subscribers, the password is configured in the BNG because DHCP cannot provide a subscriber password, and for PPP, the authentication is performed through PAP or CHAP. PPPoE PADI authentication via NASREQ is not supported in SR OS.
Configuration
The configuration of NASREQ authentication is performed in four steps:
Configure a Diameter node
Configure a Diameter application policy.
Assign the Diameter application policy.
Apply a Python policy (optional).
In the first step, the Diameter node configures the Diameter base protocol and is described in the Diameter Base Protocol: Establishing a Diameter Peer Connection chapter. As explained in this chapter, a Diameter peer can support multiple applications, such as NASREQ and Gx:
# show aaa diameter-node "bng-gx.realm-1.com" routing-table
===============================================================================
Routes
===============================================================================
Realm-Name
Application Pref. Id Server-Identifier
-------------------------------------------------------------------------------
realm-2.com
nasreq gx 10 1 dra-1.realm-2.com
realm-2.com
nasreq gx 20 2 dra-2.realm-2.com
-------------------------------------------------------------------------------
No. of routes: 2
===============================================================================
For the example in this chapter, a direct connection exists between the Diameter NASREQ client (BNG) and two NASREQ servers (aaa-1 and aaa-2):
configure
aaa
diameter
node "bng-nasreq.nokia.com" create
peer index 1 "aaa-1.nokia.com" create
address 2001:db8:2:6::1
preference 10
no shutdown
exit
peer index 2 "aaa-2.nokia.com" create
address 172.16.7.2
preference 20
no shutdown
exit
exit
exit
exit
# show aaa diameter-node "bng-nasreq.nokia.com" peers
===============================================================================
Peers
===============================================================================
Host identity Status Default Preference Active
-------------------------------------------------------------------------------
aaa-1.nokia.com I-Open No 10 Yes
aaa-2.nokia.com I-Open No 20 Yes
-------------------------------------------------------------------------------
No. of peers: 2
===============================================================================
# show aaa diameter-node "bng-nasreq.nokia.com" routing-table
===============================================================================
Routes
===============================================================================
Realm-Name
Application Pref. Id Server-Identifier
-------------------------------------------------------------------------------
nokia.com
nasreq 10 1 aaa-1.nokia.com
nokia.com
nasreq 20 2 aaa-2.nokia.com
-------------------------------------------------------------------------------
No. of routes: 2
===============================================================================
When the transport connection for one of the peers is down, the remaining peer is used for authentication. When multiple peers are available, the peer selection is based on the lowest preference value or in case of equal preference, based on the lowest index number. In the example peer aaa-1.nokia.com is used when both peers are up.
In the second step, the Diameter application policy configures the NASREQ application. For example (info detail):
configure
subscriber-mgmt
diameter-application-policy "diam-nasreq-1"
description "Diameter application policy - NASREQ"
application nasreq
diameter-node "bng-nasreq.nokia.com" destination-realm "nokia.com"
on-failure failover enabled handling retry-and-terminate
tx-timer 10
nasreq
mac-format "aa:"
password "YqXTV45qof/gOY1WFhJbKjjkhg==" hash2
user-name-format mac
no user-name-operation
include-avp
no called-station-id
no calling-station-id
circuit-id
no imei
no nas-port
nas-port-id prefix-type none suffix-type none
no nas-port-type
no rat-type
remote-id
no user-location-info
exit
exit
exit
exit
A Diameter application policy handles exact one application: NASREQ, Gx, or Gy. In this example, we use application nasreq and configure application specific parameters in the nasreq context.
A Diameter node is configured in the application policy to select the diameter routing context in which the NASREQ messages should be forwarded to the AAA server: diameter-node "bng-nasreq.nokia.com" destination-realm "nokia.com". The node is identified with its origin host "bng-nasreq.nokia.com" and must be configured in the aaa context. The destination realm specifies the realm of the NASREQ server and is used in the Destination-Realm AVP of the application messages. In the example, client and server are in the same realm.
The on-failure session failure handling specifies the Diameter application behavior when no answer is received on a request or an answer is received with a protocol error in the result code (except for DIAMETER_UNABLE_TO_DELIVER (3002) and DIAMETER_TOO_BUSY (3004) that are handled in the Diameter node). Possible configuration options are:
The subscriber sessions must be authenticated (that is, accepted) in case of failure. NASREQ should not retransmit the AA-Request message.
on-failure failover disabled handling continueThe subscriber sessions must be rejected in case of failure. NASREQ should not retransmit the AA-Request message.
on-failure failover disabled handling terminateNASREQ should retransmit the AA-Request and reject the subscriber session when the second attempt also fails (this is the configuration used in the example):
on-failure failover enabled handling retry-and-terminate
The tx-timer is the time that the Diameter application waits to get an answer from the AAA server before applying the configured failure handling. In the example, no tx-timer is configured, so the default of 10 seconds applies.
The application specific parameters are configured in the nasreq context:
The format of the MAC address to be used in all NASREQ AVPs with a MAC is configured with the mac-format command. The default format is ab:cd:ef:01:02:03
password configures the authentication password to be used for IPoE subscriber sessions. For PPP subscribers sessions, the credentials are provided in the PAP or CHAP authentication.
the AAA server checks the identity of the subscriber based on the User-Name AVP. For PPPoE subscriber sessions, the PAP/CHAP username is copied in the User-Name AVP. For IPoE subscriber sessions, the username can be configured with the command user-name-format. Options for the username format are, for example:
MAC address (with or without giaddr)
circuit-id from the relay agent information (for example, DHCP Option 82 for IPv4)
information from DHCP option 60 and 61 (which contain the Client-id and Vendor-Class information)
and NAS port Id.
For both IPoE and PPPoE subscriber sessions, the username format can optionally be manipulated with the user-name-operation command to add, remove, or replace a domain name.
Several optional AVPs can be included in the NASREQ AA-Request message and are configured in the include-avp context. In the example, circuit-id, remote-id, and nas-port-id are added.
In the third and last mandatory step, the Diameter application policy must be applied using the diameter-auth-policy name command to any of the following:
a VPRN or IES group interface
a local user database (LUDB) IPoE or PPP host
a VPLS capture SAP
a gtp apn policy
A diameter authentication policy is mutually exclusive with a radius authentication policy:
>config>subscr-mgmt>loc-user-db>ipoe>host# auth-policy "auth-policy-1"
MINOR: SVCMGR #1558 cannot configure a nasreq and a radius policy together
The fourth optional configuration step enables the manipulation of AA-Request and AA-Answer NASREQ messages with a Python script. A sample script that copies the User-Name AVP into the Subscription-Id AVP (which is not defined for NASREQ) in AA-Request messages is as follows:
# show python python-script "nasreq-1" source-in-use
===============================================================================
Python script "nasreq-1"
===============================================================================
Admin state : inService
Oper state : inService
Primary URL : ftp://*:*@10.1.1.1/./python/diameter/nasreq-1.py
Secondary URL : (Not Specified)
Tertiary URL : (Not Specified)
Active URL : primary
-------------------------------------------------------------------------------
Source (dumped from memory)
-------------------------------------------------------------------------------
1 from binascii import *
2 from alc import diameter
3
4 def getint_b2a_hex(val):
5 return int(b2a_hex(val),16)
6
7 def byte_to_binary(n):
8 return ''.join(str((n & (1 << i)) and 1) for i in reversed(range(8)))
9
10 def hex_to_binary(h):
11 return ''.join(byte_to_binary(ord(b)) for b in unhexlify(h))
12
13 def checkbitset(byte,index):
14 return ((byte&(1<<index))!=0)
15
16 def checkRequestOrReply():
17 if checkbitset(int(hex_to_binary(b2a_hex(diameter.flags))),7) is True:
18 return 'R'
19 else :
20 return 'A'
21
22 if getint_b2a_hex(diameter.code) == 265 and checkRequestOrReply() == 'R':
23 try:
24 username = diameter.get_avps(1,0)[0][1]
25 if username != "":
26 diameter.set_grouped_avps(443,0,[('@', {(450,0): [('@','\x00\x00\x00\x04')], (444,0): [('@',str(username))]})])
27 except Exception, err: print "Python FAILED to fetch username"
===============================================================================
Configuration to activate the Python script for the example:
configure
python
python-script "nasreq-1" create
description "Diameter NASREQ - AAR: copy User-Name in Subscription-Id"
primary-url "ftp://*:*@10.1.1.1/./python/diameter/nasreq-1.py"
no shutdown
exit
python-policy "py-nasreq-1" create
description "Diameter NASREQ - Python"
diameter aar direction egress script "nasreq-1"
exit
exit
aaa
diamater
node "bng-nasreq.nokia.com" create
python-policy "py-nasreq-1"
---snip---
exit
exit
exit
The Python policy must be configured in the Diameter node and can act on all Diameter base and application messages forwarded or received on any of the peers in the node. The Python policy defines on which messages a script should be activated. In the example, the script "nasreq-1" operates on the AAR messages in the egress direction. In a similar way, Python scripts can also be applied to AAA messages in the ingress direction.
Troubleshooting
The operational state of the Diameter application policy can be shown with the following show command:
# show subscriber-mgmt diameter-application-policy "diam-nasreq-1"
===============================================================================
DIAMETER application policy "diam-nasreq-1"
===============================================================================
Description : Diameter application policy - NASREQ
Session failover : enabled
Failover handling : retry-and-terminate
Peer policy : (Not Specified)
Diameter node : bng-nasreq.nokia.com
Destination-realm : nokia.com
Application : nasreq
Tx timer (s) : 10
Last management change : 11/25/2019 13:33:46
-------------------------------------------------------------------------------
NASREQ
-------------------------------------------------------------------------------
Include AVP : circuit-id
remote-id
nas-port-id
NAS-Port-Id prefix type : none
NAS-Port-Id suffix type : none
User name format : mac
User name operation : no-operation
MAC address format : aa:
Last management change : 11/25/2019 13:13:04
===============================================================================
===============================================================================
Associations
===============================================================================
No interfaces found using diameter-auth-policy "diam-nasreq-1".
-------------------------------------------------------------------------------
Local User Database IPOE Hosts using diameter-auth-policy "diam-nasreq-1"
-------------------------------------------------------------------------------
Local User Database IPOE Host
-------------------------------------------------------------------------------
ludb-1 sub-02-01_diam
-------------------------------------------------------------------------------
No. of Local User Database IPOE Hosts: 1
-------------------------------------------------------------------------------
No Local User Database PPP Hosts found using diameter-auth-policy "diam-nasreq-1".
No associated SAP's found.
===============================================================================
The following show command provides Diameter application message statistics for the NASREQ application policy, that includes transmit and receive counters per message type, transmit failures, retransmissions, and statistics per error category:
# show subscriber-mgmt diameter-application-policy "diam-nasreq-1" statistics
===============================================================================
Diameter node statistics for policy "diam-nasreq-1"
===============================================================================
Message Requests Answers
-------------------------------------------------------------------------------
Authorization-Authentication 85 56
-------------------------------------------------------------------------------
Request message transmission failur* 29
Request message retransmissions 0
Result code Sent Received
-------------------------------------------------------------------------------
(1xxx) Informational 0 0
(2xxx) Success 0 53
(3xxx) Protocol Errors 0 0
(4xxx) Transient Failures 0 3
(5xxx) Permanent Failures 0 0
===============================================================================
* indicates that the corresponding row element may have been truncated.
Diameter debugging is split between node and application level:
debug
diameter
application
policy "diam-nasreq-1"
session-messages
exit
exit
node "bng-nasreq.nokia.com"
peer "aaa-1.nokia.com"
exit
peer "aaa-2.nokia.com"
exit
exit
exit
In this chapter, the Diameter application level debugging for application messages is explained as well as application message routing errors that are reported in the node level debug. When a Python script is active for the node, the debug messages are logged after Python processing.
The session-messages option configured in the diameter application policy debug enables debug output for all Diameter application messages for the specified application policy. For a NASREQ application policy, this includes AA-Request and AA-Answer messages. By default, application error conditions are also logged in the debug output. Debug for application error conditions can be disabled with the debug option no on-error at the application or at the policy debug context.
To enable debug for the Python script that manipulates the NASREQ messages, use this debug configuration:
debug
python
python-script "nasreq-1"
script-all-info
exit
exit
exit
Following is a debug output example of a new IPoE subscriber setup: a DHCP Discover is received on a capture SAP, followed by the Diameter NASREQ AAR and AAA authentication messages. The Python script debug output shows that AVP 443 (Subscription ID) is added which is also visible in the AAR message debug (logged after the Python script is executed):
234756 2019/11/25 16:55:07.994 UTC minor: DEBUG #2001 Base SVCMGR
SVCMGR: RX DHCP Packet
VPLS 10, SAP 1/1/2:*.*
BootRequest to UDP port 67
ciaddr: 0.0.0.0 yiaddr: 0.0.0.0
siaddr: 0.0.0.0 giaddr: 0.0.0.0
chaddr: 00:02:01:00:00:01 xid: 0xf66ff11b
DHCP options:
[82] Relay agent information: len = 21
[1] Circuit-id: CircuitID
[2] Remote-id: RemoteID
[53] Message type: Discover
[255] End
234757 2019/11/25 16:55:07.994 UTC minor: DEBUG #2001 Base Python Output
Python Output: nasreq-1
234758 2019/11/25 16:55:07.994 UTC minor: DEBUG #2001 Base Python Result
Python Result: nasreq-1
Diameter AVP code 443, SET
"('@', '\\x00\\x00\\x01\\xc2@\\x00\\x00\\x0c\\x00\\x00\\x00\\x04\\x00\\x00\\x01\\xbc@\\x00\\x00\\x1900:02:01:00:00:01\\x00\\x00\\x00')"
234759 2019/11/25 16:55:07.995 UTC minor: DEBUG #2001 Base DIAMETER
DIAMETER: Message Transmission
Transmit: "AAR"
Application policy: "diam-nasreq-1"
Node: "bng-nasreq.nokia.com"
Received peer: N/A
Transmit peer: "aaa-1.nokia.com"
Python policy: "py-nasreq-1"
Header
ver 1 len 336 flags RP------ code 265
app-id 1 hbh-id 12691 e2e-id 1731030625
AVPs
session-Id (263) -M------ [42]
data [34] (UTF8String) : bng-nasreq.nokia.com;1572949245;91
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 1 : Nasreq
origin-host (264) -M------ [28]
data [20] (DiameterIdentity) : bng-nasreq.nokia.com
origin-realm (296) -M------ [17]
data [9] (DiameterIdentity) : nokia.com
destination-realm (283) -M------ [17]
data [9] (DiameterIdentity) : nokia.com
auth-request-type (274) -M------ [12]
data [4] (Enumerated) : 3 : AUTHORIZE_AUTHENTICATE
nas-port-id (87) -M------ [21]
data [13] (UTF8String) : 1/1/2:2513.20
origin-state-id (278) -M------ [12]
data [4] (Unsigned32) : 1572949245
user-name (1) -M------ [25]
data [17] (UTF8String) : 00:02:01:00:00:01
user-password (2) -M------ [11]
data [3] (OctetString) : 0x50 57 44
auth-session-state (277) -M------ [12]
data [4] (Enumerated) : 1 : NO_STATE_MAINTAINED
agent-circuit-id (1) VM------ [21]
vendor-id DSL_FORUM
data [9] (OctetString) : 0x43 69 72 63 75 69 74 49 44
agent-remote-id (2) VM------ [20]
vendor-id DSL_FORUM
data [8] (OctetString) : 0x52 65 6d 6f 74 65 49 44
subscription-id (443) -M------ [48]
data [40] (Grouped)
subscription-id-type (450) -M------ [12]
data [4] (Enumerated) : 4 : private
subscription-id-data (444) -M------ [25]
data [17] (UTF8String) : 00:02:01:00:00:01
234760 2019/11/25 16:55:08.008 UTC minor: DEBUG #2001 Base DIAMETER
DIAMETER: Message Reception
Receive: "AAA"
Application policy: "diam-nasreq-1"
Node: "bng-nasreq.nokia.com"
Received peer: "aaa-1.nokia.com"
Transmit peer: N/A
Python policy: "py-nasreq-1"
Header
ver 1 len 372 flags -P------ code 265
app-id 1 hbh-id 12691 e2e-id 1731030625
AVPs
session-Id (263) -M------ [42]
data [34] (UTF8String) : bng-nasreq.nokia.com;1572949245;91
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 1 : Nasreq
origin-host (264) -M------ [23]
data [15] (DiameterIdentity) : aaa-1.nokia.com
origin-realm (296) -M------ [17]
data [9] (DiameterIdentity) : nokia.com
result-code (268) -M------ [12]
data [4] (Unsigned32) : 2001 : DIAM_RESCODE_SUCCESS
auth-session-state (277) -M------ [12]
data [4] (Enumerated) : 1 : NO_STATE_MAINTAINED
alc-subscriber-id-str (11) V------- [21]
vendor-id NOKIA
data [9] (UTF8String) : sub-02-01
alc-subscriber-profile-str (12) V------- [25]
vendor-id NOKIA
data [13] (UTF8String) : sub-profile-1
alc-sla-profile-str (13) V------- [25]
vendor-id NOKIA
data [13] (UTF8String) : sla-profile-1
alc-msap-service-id (31) V------- [16]
vendor-id NOKIA
data [4] (Unsigned32) : 1000
alc-msap-interface (33) V------- [25]
vendor-id NOKIA
data [13] (UTF8String) : group-int-2-1
alc-msap-policy (32) V------- [25]
vendor-id NOKIA
data [13] (UTF8String) : msap-policy-1
framed-pool (88) -------- [23]
data [15] (UTF8String) : pool-pe2-1000-2
framed-ipv6-pool (100) -------- [23]
data [15] (OctetString) : pool-pe2-1000-2
alc-delegated-ipv6-pool (131) V------- [27]
vendor-id NOKIA
data [15] (OctetString) : pool-pe2-1000-2
Let's consider a failure scenario, for example a configuration error in the diameter application policy where the destination realm for the NASREQ server is incorrect: the realm realm-1.com cannot be routed in the node bng-nasreq.nokia.com:
configure
subscriber-mgmt
diameter-application-policy "diam-nasreq-1"
description "Diameter application policy - NASREQ"
application nasreq
diameter-node "bng-nasreq.nokia.com" destination-realm "realm-1.com"
---snip---
# show aaa diameter-node "bng-nasreq.nokia.com" routing-table
===============================================================================
Routes
===============================================================================
Realm-Name
Application Pref. Id Server-Identifier
-------------------------------------------------------------------------------
nokia.com
nasreq 10 1 aaa-1.nokia.com
nokia.com
nasreq 20 2 aaa-2.nokia.com
-------------------------------------------------------------------------------
No. of routes: 2
===============================================================================
In this case, the diameter node level debug displays the routing failure:
244903 2019/11/27 14:26:48.705 UTC minor: DEBUG #2001 Base SVCMGR
SVCMGR: RX DHCP Packet
VPLS 10, SAP 1/1/2:*.*
BootRequest to UDP port 67
ciaddr: 0.0.0.0 yiaddr: 0.0.0.0
siaddr: 0.0.0.0 giaddr: 0.0.0.0
chaddr: 00:02:01:00:00:01 xid: 0xf66ff11b
DHCP options:
[82] Relay agent information: len = 21
[1] Circuit-id: CircuitID
[2] Remote-id: RemoteID
[53] Message type: Discover
[255] End
244904 2019/11/27 14:26:48.705 UTC minor: DEBUG #2001 Base DIAMETER
DIAMETER: Failure
Transmit: "AAR"
Application policy: "diam-nasreq-1"
Node: "bng-nasreq.nokia.com"
Received peer: N/A
Transmit peer: N/A
Python policy: "py-nasreq-1"
Result code: N/A
Error message: "no route to destination"
Failed AVP: N/A
Message:
Header
ver 1 len 288 flags RP------ code 265
app-id 1 hbh-id 2384494 e2e-id 1731030625
AVPs
session-Id (263) -M------ [43]
data [35] (UTF8String) : bng-nasreq.nokia.com;1572949245;121
auth-appl-id (258) -M------ [12]
data [4] (Unsigned32) : 1 : Nasreq
origin-host (264) -M------ [28]
data [20] (DiameterIdentity) : bng-nasreq.nokia.com
origin-realm (296) -M------ [17]
data [9] (DiameterIdentity) : nokia.com
destination-realm (283) -M------ [19]
data [11] (DiameterIdentity) : realm-1.com
auth-request-type (274) -M------ [12]
data [4] (Enumerated) : 3 : AUTHORIZE_AUTHENTICATE
nas-port-id (87) -M------ [21]
data [13] (UTF8String) : 1/1/2:2513.20
origin-state-id (278) -M------ [12]
data [4] (Unsigned32) : 1572949245
user-name (1) -M------ [25]
data [17] (UTF8String) : 00:02:01:00:00:01
user-password (2) -M------ [11]
data [3] (OctetString) : 0x50 57 44
auth-session-state (277) -M------ [12]
data [4] (Enumerated) : 1 : NO_STATE_MAINTAINED
agent-circuit-id (1) VM------ [21]
vendor-id DSL_FORUM
data [9] (OctetString) : 0x43 69 72 63 75 69 74 49 44
agent-remote-id (2) VM------ [20]
vendor-id DSL_FORUM
data [8] (OctetString) : 0x52 65 6d 6f 74 65 49 44
Conclusion
In this chapter the configuration and troubleshooting of the Diameter NASREQ application is described. The NASREQ application provides subscriber authentication and authorization.