Token-Based Authentication for DoS Protection in Communication Networks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current network architectures face challenges in efficiently authenticating users to prevent Denial-of-Service (DoS) attacks, particularly in the Generic Bootstrapping Architecture (GBA), where excessive legitimate requests overwhelm servers, and existing solutions either burden the network with unnecessary signaling or delay communication initiation.
Innovation Solution
Implementing a 'colour of the day' token system, where each device authenticated with a server receives a unique token that allows service access without needing server validation, reducing signaling and enabling quick detection of malicious requests through hash verification and freshness parameters.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the NAF contacts the BSF to verify each authentication request, then authentication reliability is improved, but network signaling burden and processing time increase
Solution Approach 1:
The patent applies preliminary action by having the UE perform authentication with the BSF before contacting the NAF. The BSF generates authentication credentials (Ks, B-TID) in advance, and the UE stores these for later use. When the UE contacts the NAF, it can present these pre-generated credentials without requiring real-time verification with the BSF, thus reducing authentication delay while maintaining reliability.
Solution Approach 2:
The patent uses the B-TID as an intermediary element that carries authentication information from the BSF to the NAF. Instead of direct communication between NAF and BSF for each request, the B-TID serves as a mediator that encapsulates authentication state, allowing the NAF to verify credentials locally without contacting the BSF, thereby reducing signaling burden and authentication delay.
2Reliability
If rate limiting is applied to prevent DoS attacks, then server resource protection is improved, but legitimate service availability decreases
Solution Approach 1:
The patent implements feedback mechanisms where the NAF monitors authentication outcomes and request patterns. When authentication failures or suspicious patterns are detected, the NAF can adjust its behavior by contacting the BSF for verification or applying localized rate limiting. This feedback loop allows the system to protect resources while maintaining service availability for legitimate users by dynamically adjusting protection measures based on actual threat levels.
3Reliability
If the NAF requests UE-NAF keys from the BSF for each service request, then authentication security is improved, but network processing burden increases
Solution Approach 1:
The patent extracts the authentication verification function from the NAF-BSF communication path and places it in the UE. The UE generates and stores authentication credentials (Ks, B-TID) obtained from the BSF, and uses these credentials to authenticate itself to the NAF independently. This extraction eliminates the need for the NAF to contact the BSF for each service request, significantly reducing network processing burden while maintaining authentication security through the use of cryptographically secure credentials.
Data Source
Figure 1~2
Figure 3
Figure 4~6
AI summary
A method and apparatus for verifying a request for service in a communication network. An authentication node generates a secret and transmits the secret to a node providing a service. The authentication node then receives a request for authentication from a requesting node, and once the requesting node is authenticated, the authorisation node sends an identifier for the requesting node and a first token, which is derived using the secret and the identifier. A service providing node subsequently receives a request for service from the requesting node, the request including the identifier for the requesting node and the first token. The service providing node derives a second token using the identifier and the secret. If the first token and the second token match, then the service providing node allows the request, and if the first token and the second token do not match, then the request is refused.