<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: First impressions
From: insecure,AT,mail,DOT,od,DOT,ua
Date: Tue, 11 Feb 2003 12:48:20 +0100

Hi cipe folks,

I'd like to share my impressions on my initial cipe
experience. I'd appreciate any comments.

I tried to use pkcipe and got it working, but
then I realized that it's more hassle than it's
worth. I decided to accomplish the same results with
ssh. I run a script similar to this on the 'client'
('client' == initiating machine, mine is on a dynamic
IP, 'server' == one with static IP):

echo "[$hostname] Generating key"
{ echo -n "key "; openssl rand 32 | openssl md5; } >keyfile
echo "[$hostname] Starting remote ciped"
cat keyfile | ssh tunnel,AT,19,DOT,6,DOT,19,DOT,8 start
              ^^^^^^^^^^^^^^^^^^^^^^^^^^ this executes login script
                                         on the 'server'
echo "[$hostname] Starting local ciped"
exec >/dev/null 2>&1 </dev/null
mkdir logdir 2>/dev/null
setsid sh -c './ciped-dynamic 2>&1 | env - multilog t ./logdir &'
sleep 2 # race here!
# No. we don't really need keyfile anymore ;)
rm keyfile

Note that I have to store key on disk, ciped refuses to take
it from e.g. stdin. I mush choose between storing it on disk
permanently (less secure) or rm'img (racy).
This is not optimal. Ideally, I wish to just pipe it through ssh,
NEVER storing it on the disk.

This is the login script on 'server':

echo "[$hostname] Starting cipe tunnel. Enter key:"
cat >keyfile   <============ piped through ssh!
exec >/dev/null 2>&1 </dev/null
mkdir logdir 2>/dev/null
setsid sh -c './ciped-static 2>&1 | env - multilog t ./logdir &'
sleep 2 # race here!
# No. we don't really need keyfile anymore ;)
rm keyfile

Now, ciped-dynamic and ciped-static are very simple:
ciped-dynamic (on 'client')
=============
exec \
env - \
ciped-cb \
  debug \
  -o $PWD/keyfile \
  device=cipcb0 \
  ipaddr=1.9.2.2 \
  ptpaddr=1.9.3.1 \
  maxerr=1 \
  dynip \
  peer=19.6.19.8:1234 \
  ipup=$PWD/pinger \
  maxerr=-1

ciped-static (on 'server')
============
exec \
env - \
ciped-cb \
  -o $PWD/keyfile \
  device=cipcb0 \
  debug \
  ipaddr=1.9.3.1 \
  ptpaddr=1.9.2.2 \
  maxerr=1 \
  me=19.6.19.8:1234 \
  peer=127.0.0.1:9 \
  ipup=$PWD/silent \
  maxerr=-1

Well, this works. I can ping through tunnel in both directions.
But there are some strange things. First, I see corrupted
pongs coming back. How's that can ever be? I thought since
cipe crypts everything, corrupted packets will be dropped
(invalid crypt)? Does this mean that there is a bug?
BTW, I see more of this whenever packet delay/loss increase:
....
64 octets from 1.9.3.1: icmp_seq=2447 ttl=64 time=470.3 ms
64 octets from 1.9.3.1: icmp_seq=2448 ttl=64 time=800.0 ms
64 octets from 1.9.3.1: icmp_seq=2449 ttl=64 time=558.4 ms
64 octets from 1.9.3.1: icmp_seq=2450 ttl=64 time=548.5 ms
64 octets from 1.9.3.1: icmp_seq=2452 ttl=64 time=1958.4 ms
wrong data byte #0 should be 0xf6 but was 0xf5f5 e 49 3e 6e d 2 0
        8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 
22 23 24 25 26 27
        28 29 2a 2b 2c 2d 2e 2f
64 octets from 1.9.3.1: icmp_seq=2453 ttl=64 time=998.4 ms
64 octets from 1.9.3.1: icmp_seq=2455 ttl=64 time=598.4 ms
64 octets from 1.9.3.1: icmp_seq=2456 ttl=64 time=788.4 ms
64 octets from 1.9.3.1: icmp_seq=2457 ttl=64 time=534.5 ms
64 octets from 1.9.3.1: icmp_seq=2458 ttl=64 time=468.4 ms
64 octets from 1.9.3.1: icmp_seq=2459 ttl=64 time=629.8 ms
64 octets from 1.9.3.1: icmp_seq=2460 ttl=64 time=298.5 ms
64 octets from 1.9.3.1: icmp_seq=2461 ttl=64 time=528.5 ms
64 octets from 1.9.3.1: icmp_seq=2462 ttl=64 time=1548.5 ms
wrong data byte #0 should be 0x0 but was 0xffff e 49 3e 6d d 2 0
        8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 
22 23 24 25 26 27
        28 29 2a 2b 2c 2d 2e 2f
64 octets from 1.9.3.1: icmp_seq=2469 ttl=64 time=548.4 ms
64 octets from 1.9.3.1: icmp_seq=2470 ttl=64 time=648.5 ms
64 octets from 1.9.3.1: icmp_seq=2472 ttl=64 time=718.5 ms
64 octets from 1.9.3.1: icmp_seq=2473 ttl=64 time=548.5 ms
64 octets from 1.9.3.1: icmp_seq=2475 ttl=64 time=608.5 ms
64 octets from 1.9.3.1: icmp_seq=2476 ttl=64 time=578.5 ms
64 octets from 1.9.3.1: icmp_seq=2477 ttl=64 time=568.5 ms
64 octets from 1.9.3.1: icmp_seq=2478 ttl=64 time=648.5 ms
64 octets from 1.9.3.1: icmp_seq=2480 ttl=64 time=468.5 ms
64 octets from 1.9.3.1: icmp_seq=2481 ttl=64 time=517.6 ms
64 octets from 1.9.3.1: icmp_seq=2482 ttl=64 time=718.4 ms
64 octets from 1.9.3.1: icmp_seq=2483 ttl=64 time=388.5 ms
64 octets from 1.9.3.1: icmp_seq=2484 ttl=64 time=1208.5 ms
wrong data byte #0 should be 0x16 but was 0x1515 f 49 3e 6f d 2 0
        8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 
22 23 24 25 26 27
        28 29 2a 2b 2c 2d 2e 2f
64 octets from 1.9.3.1: icmp_seq=2485 ttl=64 time=408.5 ms
64 octets from 1.9.3.1: icmp_seq=2486 ttl=64 time=1068.2 ms
wrong data byte #0 should be 0x18 but was 0x1717 f 49 3e d3 83 2 0
        8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 
22 23 24 25 26 27
        28 29 2a 2b 2c 2d 2e 2f
64 octets from 1.9.3.1: icmp_seq=2487 ttl=64 time=524.1 ms

Second problem. I seem to be unable to traceroute thru
the tunnel. I can ping the other end of the tunnel, its
"other side" (it is multihomed, I can ping its other address
at 172.16.x.x) but even where ping works, traceroute -n
to the same address shows nothing at all:

bash-2.03# traceroute -n 1.9.3.1
traceroute to 1.9.3.1 (1.9.3.1), 30 hops max, 40 byte packets
 1  * * *
...

I can only traceroute my side of the tunnel:

bash-2.03# traceroute -n 1.9.2.2
traceroute to 1.9.2.2 (1.9.2.2), 30 hops max, 40 byte packets
 1  1.9.2.2  1.027 ms  0.563 ms  0.45 ms

Despite these problems, I'm happy to have it working.
Thanks guys for this cute tunnel solution!
-- 
vda





<< | Thread Index | >> ]    [ << | Date Index | >> ]