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

Subject: New Peer when IP changes?
From: Saint skullY the Dazed <skully,AT,netlsd,DOT,org>
Date: Wed, 30 May 2001 11:12:45 +0200

Hi. I have a tunnel setup between my home and work using two slackware-current
machines, with linux 2.2.19 and cipe 1.5.2. When I initially set this up, I
was on a DSL connection with a fixed, real IP. However, I canceled my DSL
line and am on a dialup connection again, with only one IP for my network
at home. The machine runnung cipe at home sits behind an OpenBSD box doing
NAT.

I establish the tunnel using pkcipe, so I don't have to worry about setting 
up remote and peer IP's each time. However, I've noticed that if I disconnect
and reconnect the modem (Thus getting a new IP) cipe will happily switch to 
using the new peer *without* having to rerun pkcipe, even though the IP and 
port are completely different, the only thing the same is the key. This 
distresses me greatly as it means that if anyone gets the key for that 
session, they can take control of my cipe tunnel.
  
The options file that pkcipe wrote for the work machine, which has a 
dedicated, real IP:

root@coffin:/var/run/cipe# cat margin
arg=margin
peer=216.27.191.139:1025
me=63.207.125.198:1042
ptpaddr=172.18.0.18
ipaddr=172.18.0.17
key=XXXXXX
 
The same on my home machine:

root@margin:/var/run/cipe# cat coffin
arg=coffin
peer=63.207.125.198:1042
me=216.27.191.139:1025
ptpaddr=172.18.0.17
ipaddr=172.18.0.18
key=XXXXXX

The 216.27.191.139 was the address used on DSL (I'm still using those IPs,
they're just nat'd). From syslog on my work machine, I find the following:

May 29 20:00:26 coffin kernel: cipcb1: new peer 198.144.204.31:10004
May 29 20:00:26 coffin kernel: cipcb1: cipe_sendmsg
May 29 20:00:26 coffin kernel: cipcb1: cipe_recvmsg
May 29 20:00:26 coffin kernel: cipcb1: cipe_sendmsg
May 29 20:00:26 coffin kernel: cipcb1: setkey
May 29 20:00:26 coffin kernel: cipcb1: cipe_recvmsg
May 29 20:00:26 coffin kernel: cipcb1: setkey
May 29 20:00:26 coffin kernel: cipcb1: cipe_sendmsg
May 29 20:00:26 coffin kernel: cipcb1: cipe_recvmsg
May 29 20:00:27 coffin kernel: cipcb1: cipe_sendmsg
May 29 20:00:27 coffin kernel: cipcb1: setkey

Grepping for "new peer" I find the following:

May 29 09:49:13 coffin kernel: cipcb1: new peer 205.162.106.244:10000
May 29 20:00:26 coffin kernel: cipcb1: new peer 198.144.204.31:10004
May 29 20:20:51 coffin kernel: cipcb1: new peer 198.144.204.31:10005
May 29 20:42:49 coffin kernel: cipcb1: new peer 198.144.204.31:10006

(I assume the new ports are from nat timing out the connection and assigning
a differant port for that udp "connection")

I did not bring the connection down or rerun pkcipe between either disconnect.

Needless to say, this is quite a problem. Should a weakness be found in 
cipe's implementation of blowfish or pkcipe's RSA implmentation, an attacker
can easily take over my stream, or cause two machine to fight for it, 
which makes a pretty effective DoS. Perhaps cipe should be changed so it
only accepts packets for that device from the ip in the peer field?

And please, before anyone flames me, I realise that the keylength used is 
320 bits, which is not trivial to brute force. However, having cipe not
renegotiate peer to a different IP is trivial, and is just a little more 
protection in the event that weaknessness are found either in the underlying 
crypto or in cipe's implementation of the crypto.





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