Can you limit policy-timeout statements based on dst/src of traffic?

[Anonymous]

I have a client who uses a web/telnet application.  The default timeout is too short (~10-15 minutes).  On their remote locations I've overcome this issue by using the following statement.

ip policy-timeout tcp telnet 28800

They are now migrating to our hosted environment from which they need similar access.  They are now in a multi-tenant scenario where multiple client's traffic runs through a NV3448.  I'm concerned about implementing the same rule because it is a global change for all traffic traversing the router.  I believe this will negatively impact router performance while being an additional security risk for all clients.

Is there anyway that I can narrow the scope of the policy-timeout to only impact this client's traffic?  Internally each client is on separate VLANs if that helps.

Worst case scenario, if I move the client to their own VRF could I then apply the policy timeout rule to only that VRF's firewall?

Additionally, are my concerns over this being an additional security risk correct?

Thanks,

Look forward to the feedback and discussion.

[jayh · Accepted solution]

To the best of my knowledge the timeout is a global setting.

However, you can set it per port/protocol to limit it to telnet.

I wouldn't worry about it being a security risk for TCP.

TCP is connection-oriented.  Normally, the end host(s) will gracefully tear down the connection with a FIN packet when they close the session.  The purpose of the timeout in a firewall or NAT scenario is to tear down a connection should the end hosts fail to do so.  For example the telnet session is started from a laptop and the battery dies, a user wanders outside of wi-fi range, etc.  Note that any traffic on the session will reset the timer.

It won't affect performance unless all of the following are true:

• You have a lot of users opening telnet connections.
• Most of them abandon the connection without closing the session or leave it open for hours with no activity.
• The number of open policy sessions at any time is near the limit of the box.

There really isn't any performance cost to leaving an idle session open other than a small amount of RAM to maintain the state.  You should be fine at 12 hour timeout.

As far as security risks, telnet itself is unencrypted....

[Anonymous]

Thank you jayh.  I went ahead and implemented and will keep an eye on performance.  I just needed to sound board concerns off of someone.

Thanks for the quick response.