From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Mon Jul 10 2006 - 12:03:56 ART
Hello,
"tcp intercept watch-timeout" has effect *only* in watch mode.
with intercept mode, timeouts are based on tcp probing algorithm,
which utilizes simple backoff scheme.
Example: simulating tcp connectins to non-existent server.
Case 1: Mode INTERCEPT
<snip>
ip tcp intercept list 199
ip tcp intercept watch-timeout 5
ip tcp intercept max-incomplete high 500
</snip>
Rack1R4#debug ip tcp intercept
TCP intercept debugging is on
Rack1R4#
.Jul 10 14:57:05.241: INTERCEPT: new connection (183.1.45.5:33793 SYN ->
183.1.46.8:80)
.Jul 10 14:57:05.241: INTERCEPT(*): (183.1.45.5:33793 <- ACK+SYN
183.1.46.8:80)
.Jul 10 14:57:06.241: INTERCEPT(*): SYNRCVD retransmit 1
(183.1.45.5:33793<- ACK+SYN
183.1.46.8:80)
.Jul 10 14:57:08.241: INTERCEPT(*): SYNRCVD retransmit 2
(183.1.45.5:33793<- ACK+SYN
183.1.46.8:80)
.Jul 10 14:57:08.257: INTERCEPT: 1st half of connection is established (
183.1.45.5:33793 ACK -> 183.1.46.8:80)
.Jul 10 14:57:08.257: INTERCEPT(*): (183.1.45.5:33793 SYN -> 183.1.46.8:80)
.Jul 10 14:57:09.257: INTERCEPT(*): SYNSENT retransmit 1
(183.1.45.5:33793SYN ->
183.1.46.8:80)
.Jul 10 14:57:11.257: INTERCEPT(*): SYNSENT retransmit 2
(183.1.45.5:33793SYN ->
183.1.46.8:80)
.Jul 10 14:57:15.258: INTERCEPT(*): SYNSENT retransmit 3
(183.1.45.5:33793SYN ->
183.1.46.8:80)
.Jul 10 14:57:23.258: INTERCEPT(*): SYNSENT retransmit 4
(183.1.45.5:33793SYN ->
183.1.46.8:80)
.Jul 10 14:57:39.259: INTERCEPT: SYNSENT retransmitting too long (
183.1.45.5:33793 <-> 183.1.46.8:80)
.Jul 10 14:57:39.259: INTERCEPT(*): (183.1.45.5:33793 <- RST 183.1.46.8:80)
Note how long it takes to finish probing real server. With aggressive mode
backoff timeouts are halved.
Case 2: Mode WATCH: (Client does 3 connection attempts, each
resetted after 5 seconds)
Rack1R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R4(config)#ip tcp inter mode watch
.Jul 10 14:57:53.804: INTERCEPT: new connection (183.1.45.5:29003 SYN ->
183.1.46.8:80)
Rack1R4#
.Jul 10 14:57:58.805: INTERCEPT: SYNSENT timing out (183.1.45.5:29003 <->
183.1.46.8:80)
.Jul 10 14:57:58.805: INTERCEPT(*): (183.1.45.5:29003 RST -> 183.1.46.8:80)
.Jul 10 14:57:59.801: INTERCEPT: new connection (183.1.45.5:29003 SYN ->
183.1.46.8:80)
.Jul 10 14:58:04.801: INTERCEPT: SYNSENT timing out (183.1.45.5:29003 <->
183.1.46.8:80)
.Jul 10 14:58:04.801: INTERCEPT(*): (183.1.45.5:29003 RST -> 183.1.46.8:80)
.Jul 10 14:58:07.801: INTERCEPT: new connection (183.1.45.5:29003 SYN ->
183.1.46.8:80)
.Jul 10 14:58:12.802: INTERCEPT: SYNSENT timing out (183.1.45.5:29003 <->
183.1.46.8:80)
.Jul 10 14:58:12.802: INTERCEPT(*): (183.1.45.5:29003 RST -> 183.1.46.8:80)
HTH
2006/7/10, Victor Cappuccio <cvictor@protokolgroup.com>:
>
> Hi Radoslav,
>
>
> http://www.windowsecurity.com/whitepapers/Secure_IOS_Template_Version_22.htm
> l
>
> Regards
> Victor.-
>
>
>
> -----Mensaje original-----
> De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de
> Radoslav Vasilev
> Enviado el: Lunes, 10 de Julio de 2006 09:52 a.m.
> Para: Cisco certification
> Asunto: TCP intercept in intercept mode
>
> Hi Group,
>
> After checking cisco.com and the arhives, i still can't understand is the
> following at all possible or not:
>
> A router is required to `act as a proxy` between the Internet and a local
> web server. (IEWB lab14, task 9.1)
> This brings us to the idea of intercept mode for the tcp intercept.
>
> let's say the web server is at:
> access-list 102 permit tcp any host 167.1.4.119
>
> ip tcp intercept list 102
>
> ! the default mode anyway
> ip tcp intercept mode intercept
>
>
> now, and what confuses me, is: ``the router should send a reset for any
> tcp
> session that have not reach the established state after 30 seconds``.
>
> This confuses me, because from what i know about this feature, when the
> router is in intercept mode, it receives the initial SYN, replies with
> SYN+ACK to the client/attacker and waits for reply (ACK). So, i beleive
> that
> in this mode the router will never send RST to the client/attacker and for
> the purposes of internal maintenance will delete the table entry when it
> enters aggresive mode (when it need to start deleting old entires, ip tcp
> intercept max-incomplete reached for example).
>
> The IE solution suggest using ``ip tcp intercept watch-timeout``, but on
> CCO
> this command is explecitly stated to be working for the passive (watch)
> mode
> only:
>
> <doc cd>
> Use this command if you have set the TCP intercept to passive watch mode
> and
> you want to change the default time the connection is watched. During
> aggressive mode, the watch timeout time is cut in half.
> </doc cd>
>
> My questions:
> -what is the right behaviour in tcp intercept mode (does the router send
> resets)
> - if it does - why the heck? the http client is either too slow(that's
> highly unlikelly even) or an attacker with spoofed IP so the RST would be
> lost anyway
> - how is the internal maintenace organized in intercept mode - is it
> managed
> with the `ip tcp intercept max-incomplete` settings (or `ip tcp intercept
> one-minute ***``) or is the command `ip tcp intercept watch-timeout
> applicable in intercept mode?
>
> Thanks for your help!
> Rado
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Petr Lapukhov, CCIE #16379 petr@internetworkexpert.comInternetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Outside US: 775-826-4344
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:47 ART