From: Victor Cappuccio (vcappuccio@gmail.com)
Date: Wed Jul 16 2008 - 15:21:15 ART
Hi Cisco Addicted, for your last question about the TCP intercept
this feature implements software to protect TCP servers from TCP
SYN-flooding attacks, which are a type of denial-of-service attack
by
http://www.cert.org/tech_tips/denial_of_service.html
A "denial-of-service" attack is characterized by an explicit attempt by
attackers to prevent legitimate users of a service from using that service.
Examples include
* attempts to "flood" a network, thereby preventing legitimate network
traffic
* attempts to disrupt connections between two machines, thereby preventing
access to a service
* attempts to prevent a particular individual from accessing a service
* attempts to disrupt service to a specific system or person
so lets do a DOS :P "just 4 education purpose"
Having this topology
R2 R1 R4 BB2
|
R5
R2#traceroute 212.2.12.254
Type escape sequence to abort.
Tracing the route to 212.2.12.254
1 192.168.12.1 0 msec 0 msec 4 msec
2 192.168.134.4 28 msec 32 msec 28 msec
3 212.2.12.254 28 msec * 28 msec
R2#
R5#traceroute 212.2.12.254
Type escape sequence to abort.
Tracing the route to 212.2.12.254
1 192.168.45.4 28 msec 28 msec 28 msec
2 *
212.2.12.254 28 msec *
R5#
R1#conf ter
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#do show ip int brief | ex una
Interface IP-Address OK? Method Status
Protocol
FastEthernet0/0 192.168.173.1 YES NVRAM up up
Serial0/0/0 192.168.134.1 YES manual up up
Serial0/0/1 192.168.12.1 YES NVRAM up up
Loopback0 110.110.1.1 YES NVRAM up up
R1(config)#
So the packets in R1 goes like this
*Aug 3 21:53:58.896: IP: s=212.2.12.254 (Serial0/0/0), d=192.168.12.0
(Serial0/0/1), g=192.168.12.0, len 100, forward
lets modify a little bit the process
R1#conf ter
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0/1
R1(config-if)#ip nat in
R1(config-if)#exit
*Aug 3 21:39:00.928: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0,
changed state to up
R1(config)#int s0/0/0
R1(config-if)#ip nat out
R1(config-if)#exit
R1(config)#ip nat inside source static 192.168.12.0 192.168.45.5
R1(config)#
*Aug 3 22:01:05.580: ipnat_add_static_cfg: id 6, flag 6
*Aug 3 22:01:05.580: id 6, flags 0, domain 0, lookup 0, from_addr C0A80C00,
from_mask FFFFFFFF, from_port 0, to_addr C0A82D05, to_port 0 to_mask FFFFFFFF,
proto 0
*Aug 3 22:01:05.600: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8516]
*Aug 3 22:01:05.600: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8516]
*Aug 3 22:01:05.600: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254
[8516]
R1(config)#
*Aug 3 22:01:07.596: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8517]
*Aug 3 22:01:07.596: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254
[8517]
R1(config)#do u
*Aug 3 22:01:09.596: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8518]
*Aug 3 22:01:09.596: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254
[8518]
R1(config)#do u all
All possible debugging has been turned off
R1(config)#
So we are now translating the thing :)
Now BB2 thinks that the thing comes from R5
*Aug 3 22:36:29.904: IP: tableid=0, s=192.168.45.5 (FastEthernet0/0),
d=212.2.12.254 (FastEthernet0/0), routed via RIB
*Aug 3 22:36:29.904: IP: s=192.168.45.5 (FastEthernet0/0), d=212.2.12.254
(FastEthernet0/0), len 100, rcvd 3
*Aug 3 22:36:29.904: IP: tableid=0, s=212.2.12.254 (local), d=192.168.45.5
(FastEthernet0/0), routed via FIB
*Aug 3 22:36:29.904: IP: s=212.2.12.254 (local), d=192.168.45.5
(FastEthernet0/0), len 100, sending
BB2#
hehehe
now lets configure the TCP intercept to see how it works
again in this cisco link
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur
_c/scprt3/scddenl.htm
A SYN-flooding attack occurs when a hacker floods a server with a barrage of
requests for connection. Because these messages have unreachable return
addresses, the connections cannot be established. The resulting volume of
unresolved open connections eventually overwhelms the server and can cause it
to deny service to valid requests, thereby preventing legitimate users from
connecting to a web site, accessing e-mail, using FTP service, and so on.
Page 27 http://www.faqs.org/rfcs/rfc793.html
The synchronization requires each side to send it's own initial
sequence number and to receive a confirmation of it in acknowledgment
from the other side. Each side must also receive the other side's
initial sequence number and send a confirming acknowledgment.
1) A > B SYN my sequence number is X
2) A < B ACK your sequence number is X
3) A < B SYN my sequence number is Y
4) A > B ACK your sequence number is Y
so lets try this on R2, BB1 and see what is the deal
BB2#debug ip tcp pac
TCP Packet debugging is on
BB2#
rack8>2
[Resuming connection 2 to R2 ... ]
R2#telnet 212.2.12.254
Trying 212.2.12.254
rack8>11
[Resuming connection 11 to bb2 ... ]
*Aug 3 22:40:28.852: tcp0: I LISTEN 192.168.45.5:17199 212.2.12.254:23 seq
1721243964
OPTS 4 SYN WIN 4128
*Aug 3 22:40:28.852: tcp0: O SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1347870184
OPTS 4 ACK 1721243965 SYN WIN 4128
*Aug 3 22:40:28.884: tcp0: I SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1721243965
RST WIN 0
BB2#
*Aug 3 22:40:30.852: tcp0: I LISTEN 192.168.45.5:17199 212.2.12.254:23 seq
1721243964
OPTS 4 SYN WIN 4128
*Aug 3 22:40:30.852: tcp0: O SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1849125975
OPTS 4 ACK 1721243965 SYN WIN 4128
*Aug 3 22:40:30.880: tcp0: I SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1721243965
RST WIN 0
BB2#
rack8>
So BB3 thinks that I comes from R5 :S
So lets configure R4 with this access-list
ip tcp intercept list 102
ip tcp intercept watch-timeout 15
ip tcp intercept mode watch
access-list 102 permit tcp any 212.2.12.0 0.0.0.255
R4#show tcp intercept statistics
Watching new connections using access-list 102
1 incomplete, 0 established connections (total 1)
2 connection requests per minute
R4#
*Aug 3 22:13:40.019: INTERCEPT: server packet passed in SYNRCVD
(192.168.45.5:55622 <- 212.2.12.254:23)
*Aug 3 22:13:41.019: INTERCEPT: SYNRCVD timing out (192.168.45.5:55622 <->
212.2.12.254:23)
*Aug 3 22:13:41.019: INTERCEPT(*): (192.168.45.5:55622 RST ->
212.2.12.254:23)
or we can modify watch time to see the thing faster :)
R4#conf ter
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#no ip tcp intercept watch-timeout 15
R4(config)#ip tcp intercept watch-timeout 5
command accepted, interfaces with mls configured might cause inconsistent
behavior
R4(config)#^Z
R4#show run
*Aug 3 22:15:21.359: %SYS-5-CONFIG_I: Configured from console by console
R4#show run | in intercept
ip tcp intercept list 102
ip tcp intercept watch-timeout 5
ip tcp intercept mode watch
R4#
rack8>2
[Resuming connection 2 to R2 ... ]
% Connection timed out; remote host not responding
R2#
R2#telnet 212.2.12.254
Trying 212.2.12.254
rack8>4
[Resuming connection 4 to R4 ... ]
R4#
R4#
*Aug 3 22:15:33.727: INTERCEPT: new connection (192.168.45.5:46993 SYN ->
212.2.12.254:23)
*Aug 3 22:15:33.731: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN
212.2.12.254:23)
R4#show run | in inter
*Aug 3 22:15:35.727: INTERCEPT: server packet passed in SYNRCVD
(192.168.45.5:46993 <- 212.2.12.254:23)
R4#show tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode
Established:
Client Server State Create Timeout Mode
R4#
*Aug 3 22:15:38.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993 <->
212.2.12.254:23)
*Aug 3 22:15:38.727: INTERCEPT(*): (192.168.45.5:46993 RST ->
212.2.12.254:23)
*Aug 3 22:15:39.727: INTERCEPT: new connection (192.168.45.5:46993 SYN ->
212.2.12.254:23)
R4#
*Aug 3 22:15:39.727: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN
212.2.12.254:23)
R4#show tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode
192.168.45.5:46993 212.2.12.254:23 SYNRCVD 00:00:03 00:00:01 W
Established:
Client Server State Create Timeout Mode
R4#
*Aug 3 22:15:44.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993 <->
212.2.12.254:23)
*Aug 3 22:15:44.727: INTERCEPT(*): (192.168.45.5:46993 RST ->
212.2.12.254:23)
R4#
*Aug 3 22:15:47.727: INTERCEPT: new connection (192.168.45.5:46993 SYN ->
212.2.12.254:23)
*Aug 3 22:15:47.727: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN
212.2.12.254:23)
R4#
*Aug 3 22:15:52.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993 <->
212.2.12.254:23)
*Aug 3 22:15:52.727: INTERCEPT(*): (192.168.45.5:46993 RST ->
212.2.12.254:23)
Enjoy
Victor Cappuccio
On Tue, Jul 15, 2008 at 9:35 PM, Igor Manassypov <imanassypov@rogers.com> wrote:
> they usually say something like 'passively watch traffic'
>
> Cisco Addicted <cisco.addicted@gmail.com> wrote: Dears,
>
> I have some confusion about the TCP intercept mode, I understand the
> difference between the two modes, but don't know one to use this in the lab.
> I mean what will be the keywords to use specific mode (intercept | watch)???
>
>
>
> Thanks gangs.
>
>
>
>
>
>
>
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: Tuesday, July 15, 2008 9:54 PM
> To: Jonathan Greenwood II
> Cc: Cisco Addicted; Peter Stephan; Nate Cielieska; Igor Manassypov; GS
> CCIE-Lab
> Subject: Re: rip passive int with neighbor command
>
>
>
> Actually there is another important point to be added onto this. EIGRP only
> uses multicast to discover neighbors and for periodic keepalives. The
> actual exchange of the topology table is done through unicast. This means
> that by default EIGRP actually uses multicast AND unicast, but if you use
> the neighbor statement it uses JUST unicast. The fact that the neighbor
> statement suppresses the multicast hello/keepalive implies that any other
> neighbors on the segment also need to unicast their hellos/keepalives,
> otherwise they will never discover each other. You can see this operation
> in action if you "debug ip packet detail". Take the following case with R1
> having the address 10.0.0.1 and forming adjacency with the neighbor
> 10.0.0.2.
>
> R1 initializes its EIGRP process.
>
> R1#config t
> Enter configuration commands, one per line. End with CNTL/Z.
> R1(config)#router eigrp 1
> R1(config-router)#no auto-summary
> R1(config-router)#network 0.0.0.0
> R1(config-router)#end
> R1#
>
> Hellos are multicast out all links running EIGRP.
>
> Jul 15 11:39:54.695: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
> len 60, sending broad/multicast, proto=88
> Jul 15 11:39:54.699: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), len
> 60, sending broad/multicast, proto=88
> Jul 15 11:39:54.699: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, rcvd
> 2, proto=88
>
> A hello packet comes in from 10.0.0.2 via multicast and neighbor adjacency
> occurs.
>
> Jul 15 11:39:54.707: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 60,
> rcvd 2, proto=88
> Jul 15 11:39:54.711: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.0.2
> (FastEthernet0/0) is up: new adjacency
>
> The topology is exchanged via unicast.
>
> Jul 15 11:39:54.711: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), routed via RIB
> Jul 15 11:39:54.711: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), len 40, rcvd 3, proto=88
> Jul 15 11:39:54.715: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
> len 60, sending broad/multicast, proto=88
> Jul 15 11:39:54.719: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0),
> len 40, sending, proto=88
> Jul 15 11:39:54.719: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 77,
> rcvd 2, proto=88
> Jul 15 11:39:54.723: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 69,
> rcvd 2, proto=88
> Jul 15 11:39:54.727: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
> len 77, sending broad/multicast, proto=88
> Jul 15 11:39:54.727: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
> len 69, sending broad/multicast, proto=88
> Jul 15 11:39:54.731: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), routed via RIB
> Jul 15 11:39:54.731: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), len 69, rcvd 3, proto=88
> Jul 15 11:39:54.735: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), routed via RIB
> Jul 15 11:39:54.735: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), len 40, rcvd 3, proto=88
> Jul 15 11:39:54.739: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0),
> len 69, sending, proto=88
> Jul 15 11:39:54.747: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), routed via RIB
> Jul 15 11:39:54.747: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), len 69, rcvd 3, proto=88
> Jul 15 11:39:54.751: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), routed via RIB
> Jul 15 11:39:54.755: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), len 40, rcvd 3, proto=88
> Jul 15 11:39:54.755: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0),
> len 40, sending, proto=88
> Jul 15 11:39:54.963: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0),
> len 69, sending, proto=88
> Jul 15 11:39:54.971: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), routed via RIB
> Jul 15 11:39:54.971: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> (FastEthernet0/0), len 40, rcvd 3, proto=88
> Jul 15 11:39:55.139: %SYS-5-CONFIG_I: Configured from console by console
> R1#
>
> Once converged only periodic multicast hellos are exchanged until something
> changes in the topology.
>
> Jul 15 11:39:59.551: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 60,
> rcvd 2, proto=88
> Jul 15 11:39:59.579: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), len
> 60, sending broad/multicast, proto=88
> Jul 15 11:39:59.579: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, rcvd
> 2, proto=88
> Jul 15 11:39:59.687: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
> len 60, sending broad/multicast, proto=88
> Jul 15 11:40:04.202: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
> len 60, sending broad/multicast, proto=88
> Jul 15 11:40:04.495: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), len
> 60, sending broad/multicast, proto=88
> Jul 15 11:40:04.495: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, rcvd
> 2, proto=88
> Jul 15 11:40:04.539: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 60,
> rcvd 2, proto=88
> Jul 15 11:40:08.838: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
> len 60, sending broad/multicast, proto=88
> Jul 15 11:40:09.190: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 60,
> rcvd 2, proto=88
> Jul 15 11:40:09.270: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), len
> 60, sending broad/multicast, proto=88
> Jul 15 11:40:09.270: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, rcvd
> 2, proto=88
>
>
>
>
> HTH,
>
> Brian McGahan, CCIE #8593 (R&S/SP/Security)
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> Online Community: http://www.IEOC.com
> CCIE Blog: http://blog.internetworkexpert.com
>
>
>
> Jonathan Greenwood II wrote:
>
> Peter well said you hit it right on the nail.
>
> On Tue, Jul 15, 2008 at 12:38 PM, Cisco Addicted
>
> wrote:
>
>
>
> Peter,
> Thank you very much for the sharp and bright clarification. Really you
> shot
> the head of this issue.
>
> Regards.
> Moe
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Peter Stephan
> Sent: Tuesday, July 15, 2008 7:42 PM
> To: 'Nate Cielieska'; 'Igor Manassypov'
> Cc: 'Jonathan Greenwood II'; 'GS CCIE-Lab'
> Subject: RE: rip passive int with neighbor command
>
> Just to remember:
>
> In EIGRP:
> If you enable unicast updates on an interface, you DISABLE multicasting
> updates to 224.0.0.10 through that particular interface.
>
> In RIP v2:
> If you enable unicast updates on an interface (through neighbor cmd), you
> 'DO NOT STOP' multicasting updates.
> You use then passive-interface to stop multicasting updates if it was
> required.
>
>
> Don't confuse yourself... just remember in EIGRP you either have unicast or
> multicast, in RIP you can have both (unless you use passive-int).
>
> Cheers,
> Peter.
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Nate
> Cielieska
> Sent: Tuesday, July 15, 2008 8:24 PM
> To: Igor Manassypov
> Cc: Jonathan Greenwood II; GS CCIE-Lab
> Subject: Re: rip passive int with neighbor command
>
> Igor,
>
> When you turn on unicast updates with the "neighbor x.x.x.x" command, this
> does not disable the multicast updates out of that interface. It merely
> sends that particular neighbor a unicast update and sends out a
> 224.0.0.9multicast update as well.. to stop the multicast updates you used
> the passive-interface command. The passive-interface command has no bearing
> on your unicast updates so your updates will be seen on your router..
> meeting your requirements.
>
> Regards,
> Nate
>
> On Tue, Jul 15, 2008 at 10:58 AM, Igor Manassypov
>
> wrote:
>
>
>
> if I configure that interface on which my neighbor sits as passive,
> and I also configure a neighbor command explicitly, are routes going
> to be exchanged?
>
> Jonathan Greenwood II wrote:
> Igor when you use the
> neighbor command you are sending RIP updates via unicast by
> specifiying the IP Address of the neighboring router as opposed to the
> multicast address 224.0.0.9 which all rip enabled interfaces listen
> on. Passive interface with RIP doesn't allow updates to be sent out
> the interface but an interface can still receive updates from my
>
>
> understanding.
>
>
> To actually form the neighbor relationship the interface should not be
> configured for passive interface. You could also peform RIP
> authentication on both sides depending on the requirements/restrictions
>
>
> of
> the question.
>
>
> HTH
>
> Jonathan
>
> On Tue, Jul 15, 2008 at 9:44 AM, Igor Manassypov
> wrote:
>
>
>
> Could someone please clarify rip's neighbor command mixed with a
> passive-interface? For example, if you are asked to make sure that
>
>
> routing
>
>
> updates are only sent to a particular router, I will configure a
> corresponding 'neighbor' entry under my rip process, but to satisfy
> the requirement that only that particular router gets updates I
> would also
>
>
> need
>
>
> to enable the passive interface. As soon as I do that, there are no
> more routing updates coming from that interface even though I have
> an explicit neighbor configured... If I do not use the passive
> interface, then other routers will get updates breaking the
>
>
> requirement...
>
>
>
> ____________________________________________________________________
> ___ 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
>
>
> ______________________________________________________________________
> _ 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
>
>
> _______________________________________________________________________
> 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
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
> Igor M., M.Eng, P.Eng
> Network Architect
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
-- Victor Cappuccio CCIE R/S# 20657 CCSI# 30452 www.vcappuccio.wordpress.com
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART