Customer explains the current issue that security auditors picked up. So the customer has a high end SRX firewall to do the natting in the mobile after the GGSN. The are using source nat with a certain amount of public natted IP addresess. So for example a user with IP 10.10.0.10 connects to somewhere on the internet lets say www.webmail.com. A session is exsit as per normal etc. etc. What happens now this user disconnects from the network. The ip goes back into the pool and some other user joins the network and get that IP. What happens is when this new users get the IP and the previous session still exist they where able to capture the return traffic of the previous user. This obviuosly happens all in a few seconds but apearntly it is a security issue.
So after some though i am trying to get my mind around it and wonder if this is not just how it fundamentally work, because the TCP sesion and connection exist between the client and server. The firewall has visibility into the session etc. So if a session is installed in the session table as the firewall recieve a return packet from the server it will just forward it onto the client. If there is not response from either side(because the client disconnected) of the session the firewall mark it as inactive and after the timeout it will close the session. So lets say the server is still sending data to the clients return flow and at that moment a users disconnects and another users gets assigned the same IP via DHCP. As the firewall only understand that it needs to forward the packet to IP address (internal) it still sees the session open, packet arriving from the server and forward it onto the IP source, in that moment the new device will recieve that data. I cant see how the firewall can in any situation see that the client is not the actual client anymore and then suddendly just close the session or have an idea the excat moment a device leaves the network as there arent really any heartbeats or true connection between client and firewall. I guess this would be been defrent in a proxy scenario where there is client to proxy and proxy to server.
This is a well-known behaviour, and Your GGSN/RADIUS/DHCP server need to re-allocate/re-use same private IP to a new UE after a certain time interval, not less than TIME_WAIT, i.e. 10 mins should be enough.This means You should have a bigger GGSN pool, to accomodate this additonal time interval.
Most modern standard TCP/IP stack implementations either use keepalives or estimate RTT using timetstamps, so the connection should be closed on server side after certain time.
if the customer is using lame or bog-standard TCP/IP stack implementation dating from circa 1981 (when RFC 793 was first published) meaning no keepalives & server sends unidirectionally without verifying that client actually receives the packets, then there is no protection against such stupidity.