Cisco ACS RADIUS attributes with HP Switches behavior

[B. BELHADJ]

Hello,

The last week I was with the HPE network team to configure HP switches (COMWARE) with our Cisco ACS used for RADIUS services.

We encountered a problem that opened a big discussion and debate, that I appreciated, with a great team of HPE network engineers

1. In the production environment, we have already Cisco switches configured with our Cisco ACS 5.4 and working fine.
2. The only configured RADIUS IETF attributes are:

Attribute	Type	Value
Tunnel-Type	Tagged Enum	[T:1]VLAN
Tunnel-Medium-Type	Tagged Enum	[T:1]802
Tunnel-Private-Grup-ID	Tagged String	[T:1]200
Session-Timeout	Unassigned Integer 32	0
Termination-Action	Enumeration	Default

(cf. Screenshot)

With these configurations IP Phone and Printers are working fine with Cisco switches.

When we add the HP switch to this ACS, the IP Phone and Printers used for testing are successfully authenticated and immediately disconnected!!

But when we delete the “session-timeout” and “Termination-Action” attributes, the IP Phone and the Printer are authenticated and still connected to the network.

The RFC 3580 says that:

   When sent along in an Access-Accept without a Termination-Action

   attribute or with a Termination-Action attribute set to Default, the

   Session-Timeout attribute specifies the maximum number of seconds of

   service provided prior to session termination.

   When sent in an Access-Accept along with a Termination-Action value

   of RADIUS-Request, the Session-Timeout attribute specifies the

   maximum number of seconds of service provided prior to re-

   authentication.  In this case, the Session-Timeout attribute is used

   to load the reAuthPeriod constant within the Reauthentication Timer

   state machine of 802.1X.  When sent with a Termination-Action value

   of RADIUS-Request, a Session-Timeout value of zero indicates the

   desire to perform another authentication (possibly of a different

   type) immediately after the first authentication has successfully

   completed.

   When sent in an Access-Challenge, this attribute represents the

   maximum number of seconds that an IEEE 802.1X Authenticator should

   wait for an EAP-Response before retransmitting.  In this case, the

   Session-Timeout attribute is used to load the suppTimeout constant

   within the backend state machine of IEEE 802.1X.

My questions are:

1. Why Cisco switches are working fine with the “session-timeout=0” and “termination action=Default” attributes?
2. Why we need to delete these parameters for devices (IP Phone and printer) to be working fine with the HP switches?

admin

@Scott Morris - CCDE/4xCCIE/2xJNCIE

@Paul Stewart - CCIE Security

Please help us!

Thank you for your replies.

Best regards.

[Craig Hyps]

A value of 0 should disable the session timeout, but per description it sounds like HP / Comware switch treating it as an immediate timeout.  Suggest using different conditions to match HP switches so that different values can be returned via RADIUS.  Also, Cisco switches have specific setting to request value be sent via RADIUS versus statically set.  Verify HP switch has option set to accept value via RADIUS and its interpretation of value = 0.

[B. BELHADJ]

Hello Chyps,

Thank you for your quick reply.

Just to clarify, you say "A value of 0 should disable the session timeout" ==> But if the session-timeout=0 is used with Access-request, the session will perform another authentication like it described in the RFC 3580

(When sent with a Termination-Action value of RADIUS-Request, a Session-Timeout value of zero indicates the  desire to perform another authentication (possibly of a different type) immediately after the first authentication has successfully completed.)

.

For HP switch, I checked with the HPE engineer and he is confirmed that this option of session timeout is not found like Cisco switch.

I think that the HP switch interprets the session-timeout=0 like disconnect!

Best regards.

[kthiruve]

Hi,

Please get a wireshark trace of these transactions to see the request from ACS and response from Switches.

Same for HP switches for comparison. Once you go through the trace to see the request/response and the continuation of Radius for subsequent sessions you will be able to clearly understand the underlying behavior.

Based on that you can change the values of session timeout for HP switches as needed.

Thanks

Krishnan

[Craig Hyps · Accepted solution]

Upon further review, I have verified that ISE 2.1 does not allow the setting of a Session Timeout = 0.  To disable Session Timeout, simply do not configure a session timeout.  Per Cisco switch configuration guide:

"If the switch is configured to use the RADIUS-supplied timeout, but the Access-Accept message does not include a Session-Timeout attribute, the switch never reauthenticates the supplicant. This behavior is consistent with Cisco's wireless access points."

Based on information, ACS apparently allows a value of zero.  You can verify the session timeout setting on the switch using a command similar to following:

     cat3750x# show auth session interface gi 1/0/1 details

This will display the session timeout value.  If not set, it will indicate value of N/A. For positive values set in RADIUS, here is example from Catalyst 3750X running 15.2(4)E:

     Session timeout:  28800s (server), Remaining: 26156s

As noted, the HP switch appears to be accepting the session timeout of 0 and Default terminate action and immediately forcing reauth on port. This is consistent with your description "successfully authenticated and immediately disconnected".  This seems consistent with the RFC description.

I would start by defining the desired behavior and then sending (or not sending) the RADIUS attributes based on requirement.  If switches behave differently, then you can create different Authorization Profiles applied to each NAD Profile and stack them in the Authorization Policy rule.  This will keep the number of rules the same.

/Craig

[B. BELHADJ]

Hello Chyps,

Thank you so much for your reply.

Best regards.