Question on tcp idle reset

[hnasr]

• I was reading through the Configuring TCP Reset for Idle Sessions had a question about the tcp idle reset property (on/off). 

full link https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-16-6/sec-data-zbf-xe-16-6-book/tcp-rst-seg-con.pdf

We know Cisco routers keeps track of connections they see in a local state table. This state is cleared when either party closes the connection. However, routers can also "drop" the knowledge of the state when a connection goes idle for too long (the rationale is both server and client have crashed). The tcp idle-time can be configured to increase that (default 1 hour). I noticed there is another option called cp idle reset which I'm more interested. 

Quote from the doc 

"If you configure the tcp idle reset on command, the TCP RST segment is sent to both ends of the idle session when timeout occurs and the session is cleared."

My question is when the router sends the RST segments to both the client and server, what is source IP address for those two RST packets? Is it the router's IP or does the router "spoofs" the client and server ip addresses in this case?

Also what is the default value (the document doesn't clarify it) 

Thanks

-Hussein

[g.andrasi · Accepted solution]

Hello Hussein,

"We know Cisco routers keeps track of connections they see in a local state table." - this is by default not true, cisco routers are stateless, meaning that they do not track the state of tcp or any other protocol connections that are going through the router (meaning they are not initiated by the router itself, or the router is not the destination of connection). The only cases that i can think of where they do any sort of connection tracking is if NAT is configured, or when a Zone Based Firewall inspect policy has been applied to certain flows.

In my years of being a network engineer at various financial institutions, content providers and retail enterprises i have never seen a router configured with ZBF in a production network... connection tracking is usually the task for a dedicated stateful firewall, and not a router. Of course that doesnt mean that there arent any, just that it is rare, and generally not an industry standard practice.

That being said, here is the default values for a parameter-map:

parameter-map type inspect zbf-in-to-out-parametermap
audit-trail off
alert on
max-incomplete low 2147483647
max-incomplete high 2147483647
one-minute low 2147483647
one-minute high 2147483647
sessions rate low 2147483647 time 60
sessions rate high 2147483647 time 60
udp idle-time 30
udp half-open idle-time 30000
icmp idle-time 10
dns-timeout 5
tcp idle-time 3600
tcp finwait-time 1
tcp synwait-time 30
tcp half-open reset on
tcp half-close reset on
no tcp window-scale-enforcement loose
tcp idle reset on
application-inspect all 
tcp max-incomplete host 4294967295 block-time 0 
sessions maximum 2147483647 
session packet 0 
session packet 0
no log dropped-packets
no icmp-unreachable-allow
no zone-mismatch drop

so tcp idle reset is on by default, but it will only be used, when the inspect command under the policy-map uses the specified parameter-map, or if the parameter-map is global afaik

Regarding your other question with tcp idle reset, yes the router spoofs the client and server addresses when sending the RST packet, so it will be transparent to both sides.

best

g

[hnasr]

Thank you so much for the detailed answer and the correction. 

I see so connection tracking will only happen in the router if firewall capabilities are enabled.

[Joseph W. Doherty]

"I see so connection tracking will only happen in the router if firewall capabilities are enabled."

For just routing, there's no need to track transit sessions.  TCP sessions, to the router, as a host, would be tracked like any other host 

Beyond the basic requirements, additional TCP or beyond TCP session tracking would depend on what the router is trying to accomplish.  For example, earlier, @g.andrasi mentioned NAT (or PAT), but something like various past caching techniques or NetFlow monitoring, track sessions and are not limited to TCP nor for a security purpose.

[Joseph W. Doherty]

At the moment, unable to open your referenced document, so unclear why a router has state information about TCP sessions unless they are not for transit traffic but to the router itself as a host.

For transit traffic, there may be some additional options when providing services beyond just routing.

For router as a host device, such options normally fall under "hardening" the router or "failsafes" for certain services.

TCP options, for a router as a host, might be found in: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp/configuration/15-mt/iap-15-mt-book/iap-tcp.html

[hnasr]

thanks Joseph, appreciate it.

so are idle connections not tracked by default? 

I just updated the link 

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-16-6/sec-data-zbf-xe-16-6-book/tcp-rst-seg-con.pdf

[Joseph W. Doherty]

Ah, what you're looking appears to be in reference to the optional Zone Based Firewall feature.  As @g.andrasi already described, firewalls do tend to keep state information for transit traffic, to support various security options, which may also apply to unintentional issues too, such as one side of a session's host inadvertently crashing.

As to whether long term idle TCP sessions are tracked by default, the would depend on the device.  Insufficient experience with ZBF to say what's its typical default is, but in my past experience, Cisco routers and switches TCP keep alive was not enabled by default.