31.05.2013 01:50, Luca Salvatore wrote: > Thanks for the info. The attack we recently saw was using IP protocol 3 (GGP) > which is not specifically permitted so I'm unsure how it was allowed to > create a session in the first place. The right way is to catch a sample attack packet with flow traceoptions and check why the SRX even bothers to create a session. If you have no policy, it should not (accurate within "no bugs" assumption). But who knows? Only way to know for sure is to trace it. > Does the session limit screening only apply to TCP/UDP? Not sure, but I believe no. It should count all active sessions for a given IP. > Also what is the definition of an invalidated session? 1. Most common case is a session created for "one wing". When, say, a TCP SYN passed from client to server, but no response from the server is yet received. Most probably this is your case. Such sessions have, IIRC, 10 seconds timeout. 2. When a TCP RST is sent by one of the parties and the "tcp-invalidates-session" option is on. 3. I've heard that, when a normal closing condition arises, session is also first marked invalidated for a very short period before it's actually teared down. But I don't know much details about that (can someone on the list elaborate?) However this should not lead to that high value of invalidated sessions counter .
As I understand, this is a sort of a queue where candidates for tear-down are placed. And there is a subroutine (like a scheduler), which scans through the invalidated sessions and decides if it's time to pull a particular one down and return resources to the pool or maybe clear the invalidated state and thus make it active back or for the first time. -- Pavel _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
