[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cipe
Subject:    Re: New Peer when IP changes?
From:       ewheeler () kaico ! com
Date:       2001-05-30 16:13:54
[Download RAW message or body]

Skully --

You might try to deny all incomming udp packets destined for the CIPE port
unless they come from a specific IP.  I realize that UDP is relativily
easy to spoof, but that would at least reduce your exposure from anyone
with your key having access to your cipe tunnel to only those people on
your circuit having access to your cipe tunnel (who, of course, also had
your key).

--Eric

On Tue, 29 May 2001, Saint skullY the Dazed wrote:

> 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.
> 
> --
> Message sent by the cipe-l@inka.de mailing list.
> Unsubscribe: mail majordomo@inka.de, "unsubscribe cipe-l" in body
> Other commands available with "help" in body to the same address.
> CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>
> 


--
Message sent by the cipe-l@inka.de mailing list.
Unsubscribe: mail majordomo@inka.de, "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>

[prev in list] [next in list] [prev in thread] [next in thread]