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

To: <cipe-l,AT,inka,DOT,de>
Subject: RE: Feature: Using just one port
From: "Mark Smith" <mark.smith,AT,avcosystems,DOT,co,DOT,uk>
Date: Wed, 18 Jun 2003 18:48:44 +0100
Importance: Normal
In-reply-to: <1055957035.5228.28.camel@monster.omnifarious.org>

> I haven't studied PKCipe much.  It may do this.

It doesn't, to the best of my knowledge.  It's used to negotiate a config
file, and then launch ciped.  After that, pkcipe is no longer part of the
tunnel.  There have been a couple of suggestions recently that would warrant
a slight change to the protocol, but this appears to be more than a small
change.  I haven't seen a post from Olaf for so long that I wonder if he's
had time to keep up with the mailing list at all, or reply.

His previous posts said that he was working on a new model that would use
the Linux cryptography modules, I don't remember the details, but I believe
that such a change may well involve a protocol change.  Certainly, I feel it
would be nice to be able to run multiple tunnels from one daemon over one
host port, just like it would be nice to have compression and no MTU
problems, all in one package.  At the moment there are many versions, I
don't know how many of them are compatible with each other, even if they're
compatible with the plain version.

I've been too busy to work more on pkcipe for win32, but I too am working on
the source.  I still feel a developer list or website or something would
benefit those working on the source, and keep it separate from those wishing
to use cipe and ask questions about it's usage.

Does anyone have any documentation they'd like to share, that might be worth
copying on to the cipe website as a more permanent faq?  If not, does anyone
have anything they could make into one, or just write from scratch?  I think
it would help.  Likewise, cipe is enough of a package now that it may well
deserve it's own newsgroup...

Mark Smith - Avco Systems Ltd
email: mark.smith,AT,avcosystems,DOT,co,DOT,uk
Tel: +44 (0)1784 430996 Fax: +44 (0)1784 431078

> -----Original Message-----
> From: owner-cipe-l,AT,inka,DOT,de [mailto:owner-cipe-l,AT,inka,DOT,de 
> Behalf Of
> Eric M. Hopper
> Sent: 18 June 2003 18:24
> To: Allan Latham
> Cc: cipe-l,AT,inka,DOT,de
> Subject: Re: Feature: Using just one port
> On Tue, 2003-06-17 at 13:57, Allan Latham wrote:
> > Hi Eric
> >
> > the plan calls for the remotes to be direct on the internet
> but there's always
> > a risk that someone will want the remote behind a NAT
> firewall. Most NAT
> > firewalls seem to keep the original port if it doesn't
> conflict with existing
> > connections but of course one can't rely on that!
> >
> > The only alternative to this scheme I could come up with
> was to put the
> > original port in plaintext ahead of the cipe payload in the
> udp packet. It's
> > not intended to interwork with "standard" cipe
> installations so that might be
> > an easier way. And it's NAT safe!
> Yes, that would work, and be no less secure than using the
> peer port #.
> To be extra secure, you'd want that value to be MACed along with the
> encrypted portions of the message.  Both of those schemes
> permit traffic
> analsysis based on always being able to identify which parties are
> speaking in any given packet.  The remote stations could be assigned
> numbers by a traffic analyzer, and a remote station could always be
> associated with a number, no matter where it was.
> To prevent that (and be more efficient), you'd want to make some
> significant changes to the protocol to securely negotiate the
> station's
> identity whenever the it started sending packets from a different
> place.  Then, no further packets would have to contain the station's
> identity, and the station's identity would not be able to be directly
> determined from examining packets.
> Have fun (if at all possible),
> --
> The best we can hope for concerning the people at large is that they
> be properly armed.  -- Alexander Hamilton
> -- Eric Hopper (hopper,AT,omnifarious,DOT,org
http://www.omnifarious.org/~hopper) --

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