Project

General

Profile

Feature #874

fast and robust kill the IKE_SA connection in the radius accounting response.

Added by bronze man about 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
04.03.2015
Due date:
Estimated time:
Resolution:

Description

I want a fast and robust kill the IKE_SA connection in the radius accounting response.
It should have the functional like vici's kill IKE_SA.

I am trying to kill the IKE_SA with vici during responsing of radius accounting start request,and response normally. It is not work and will crush the strongswan process.
Do not response to the radius accounting start request can kill the IKE_SA,but it need about 10s+.

I am trying to kill the IKE_SA with vici during responsing of radius accounting interim updates request,and response normally.
It works,and it is fast and robust.

I think it will be simpler that I can just response a Access-Reject to kill the IKE_SA or using some custom AVPs.
If it works ,I can remove all vici relative code.


Related issues

Related to Bug #838: "RADIUS Response-Authenticator verification failed" error if RADIUS message arrives after charon gave up retransmittingClosed31.01.2015

History

#1 Updated by bronze man about 7 years ago

#838 is relative to this one.

#2 Updated by Tobias Brunner about 7 years ago

  • Status changed from New to Feedback

I want a fast and robust kill the IKE_SA connection in the radius accounting response.

What exactly is your use case here? What is the relation between RADIUS Accounting and the termination of IKE_SAs?

Anyway, there is no standard-compliant way of closing an IKE_SA based on a Accounting-Response RADIUS message. According to RFC 2866, section 4.1 the only valid response to an Accounting-Request message is an Accounting-Response message (or no message at all):

Upon receipt of an Accounting-Request, the server MUST transmit an
Accounting-Response reply if it successfully records the
accounting packet, and MUST NOT transmit any reply if it fails to
record the accounting packet.

So sending an Access-Reject message is not valid.

As far as RADIUS attributes are concerned RFC 2866, section 5.13 says:

No attributes should be found in Accounting-Response packets
except Proxy-State and possibly Vendor-Specific.

While this does not explicitly prohibit a RADIUS server from sending other attributes, the question is what attribute could be used to terminate a connection. I haven't found any particularly useful attribute (Session-Timeout with a value of 0 maybe?). So a more compliant option would probably be to implement a vendor-specific attribute for this. But such an attribute would have to be implemented by the RADIUS server too.

A standard-compliant way of terminating an existing session from a RADIUS server would be the Disconnect-Request message defined in RFC 5176 (the FreeRADIUS wiki has some information and examples on disconnect messages).
However, strongSwan currently does not implement this extension.

Depending on your use case it might be easier to write a custom plugin that terminates IKE_SAs e.g. based on metrics like transmitted data.

#3 Updated by bronze man about 7 years ago

What exactly is your use case here?
I write a accounting system that the user can buy some transfer bytes like 1GB/$0.5, the user connections will be terminated when the user do not have any transfer bytes. I use radius protocol to check every connections transfer bytes every 5 seconds.If I found it do not have any transfer bytes,I will terminated it.

What is the relation between RADIUS Accounting and the termination of IKE_SAs?
I want to termination the IKE_SAs during the response of RADIUS Accounting,but due to #838,it is not so easy.

It can be done,by return the response,and wait 1 second,and user vici terminated the connection.

I write a RADIUS server with golang,I write all of the code.It is not open source.

#4 Updated by Tobias Brunner about 7 years ago

  • Related to Bug #838: "RADIUS Response-Authenticator verification failed" error if RADIUS message arrives after charon gave up retransmitting added

#5 Updated by Tobias Brunner about 7 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF