From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 15 Dec 2002 15:27:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 15 Dec 2002 15:27:21 -0500 Received: from 4-090.ctame701-1.telepar.net.br ([200.193.162.90]:6850 "EHLO 4-090.ctame701-1.telepar.net.br") by vger.kernel.org with ESMTP id ; Sun, 15 Dec 2002 15:27:20 -0500 Date: Sun, 15 Dec 2002 18:34:06 -0200 (BRST) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: netdev@oss.sgi.com cc: linux-kernel@vger.kernel.org Subject: RFC: p&p ipsec without authentication Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi, I've got a crazy idea. I know it's not secure, but I think it'll add some security against certain attacks, while being non-effective against some others. The idea I have is letting the ipsec layer do opportunistic encryption even when there are no ipsec keys known for the destination address, ie. negotiate a key when none is in the configuration or DNS. I know this gives absolutely no protection against man-in-the-middle attacks (except maybe being able to detect them), but it should prevent passive sniffing of network traffic, as done by some governments. If this "random" encryption could be turned on with one argument to ip or ifconfig and millions of hosts would use it, sniffing internet traffic might just become impractical (or too expensive) for large organisations. Furthermore, even if just 0.1% of the hosts were to use ipsec authentication, the 3-letter agencies would be faced with the additional challenge of identifying which connections could safely be intercepted with man-in-the-middle attacks and which couldn't. Not to mention the fact that the port number on many communications would be invisible, vastly increasing the difficulty of doing any kind of statistical analysis on the traffic that's traversing the network. Is this idea completely crazy or only slightly ? regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: october@surriel.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 15 Dec 2002 17:03:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 15 Dec 2002 17:03:47 -0500 Received: from ns.indranet.co.nz ([210.54.239.210]:43496 "EHLO mail.acheron.indranet.co.nz") by vger.kernel.org with ESMTP id ; Sun, 15 Dec 2002 17:03:45 -0500 Date: Mon, 16 Dec 2002 10:59:10 +1300 From: Andrew McGregor To: Rik van Riel , netdev@oss.sgi.com cc: linux-kernel@vger.kernel.org Subject: Re: RFC: p&p ipsec without authentication Message-ID: <3050000.1039989550@localhost.localdomain> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b9 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org It's not crazy at all. Perfectly practical, now that lots of people have fast enough machines and slow enough connections that it won't drive them mad with the performance issues :-) Actually, it can be done (fairly) securely against MITM attacks as well. Check out a keying protocol called HIP, most of the resources are linked to from www.hip4inter.net. The basic idea is that each end prove to the other that they know a private key. The MITM protection is quite hard to describe :-) And it can be done (at least on IPv6) with almost zero cost in time for connections that don't support HIP, as well as only one round trip + compute time for those that do. There are four implementations in progress, two for linux. It would be very nice to get the necessary hooks into the mainline kernel. Cool, eh? Andrew --On Sunday, December 15, 2002 18:34:06 -0200 Rik van Riel wrote: > Hi, > > I've got a crazy idea. I know it's not secure, but I think it'll > add some security against certain attacks, while being non-effective > against some others. > > The idea I have is letting the ipsec layer do opportunistic encryption > even when there are no ipsec keys known for the destination address, > ie. negotiate a key when none is in the configuration or DNS. > > I know this gives absolutely no protection against man-in-the-middle > attacks (except maybe being able to detect them), but it should prevent > passive sniffing of network traffic, as done by some governments. > > If this "random" encryption could be turned on with one argument to > ip or ifconfig and millions of hosts would use it, sniffing internet > traffic might just become impractical (or too expensive) for large > organisations. Furthermore, even if just 0.1% of the hosts were to > use ipsec authentication, the 3-letter agencies would be faced with > the additional challenge of identifying which connections could safely > be intercepted with man-in-the-middle attacks and which couldn't. > > Not to mention the fact that the port number on many communications > would be invisible, vastly increasing the difficulty of doing any > kind of statistical analysis on the traffic that's traversing the > network. > > Is this idea completely crazy or only slightly ? > > regards, > > Rik > -- > Bravely reimplemented by the knights who say "NIH". > http://www.surriel.com/ http://guru.conectiva.com/ > Current spamtrap: href=mailto:"october@surriel.com">october@surriel.com - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 16 Dec 2002 04:12:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 16 Dec 2002 04:12:34 -0500 Received: from mail.hometree.net ([212.34.181.120]:25732 "EHLO mail.hometree.net") by vger.kernel.org with ESMTP id ; Mon, 16 Dec 2002 04:12:33 -0500 To: linux-kernel@vger.kernel.org Path: forge.intermeta.de!not-for-mail From: "Henning P. Schmiedehausen" Newsgroups: hometree.linux.kernel Subject: Re: RFC: p&p ipsec without authentication Date: Mon, 16 Dec 2002 09:20:27 +0000 (UTC) Organization: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH Message-ID: References: Reply-To: hps@intermeta.de NNTP-Posting-Host: forge.intermeta.de X-Trace: tangens.hometree.net 1040030427 16130 212.34.181.4 (16 Dec 2002 09:20:27 GMT) X-Complaints-To: news@intermeta.de NNTP-Posting-Date: Mon, 16 Dec 2002 09:20:27 +0000 (UTC) X-Copyright: (C) 1996-2002 Henning Schmiedehausen X-No-Archive: yes X-Newsreader: NN version 6.5.1 (NOV) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Rik van Riel writes: >Hi, >I've got a crazy idea. I know it's not secure, but I think it'll >add some security against certain attacks, while being non-effective >against some others. While the idea itself is nice, it would allow many attackers on your host to "dive" under IDS systems or avoid stateful firewalls which do protocol verification. And IDS system is "a three letter acronym listening on your traffic". And you want to avoid that. =:-) It won't traverse many firewalls either (because they won't let IPSEC pass) and you might get in trouble with NAT and protocols that need NAT fixup. And you basically divide the Internet into "Linux <-> Linux" and "the rest". :-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de D-91054 Buckenhof Fax.: 09131 / 50654-20 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 16 Dec 2002 07:08:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 16 Dec 2002 07:08:00 -0500 Received: from ns.indranet.co.nz ([210.54.239.210]:41675 "EHLO mail.acheron.indranet.co.nz") by vger.kernel.org with ESMTP id ; Mon, 16 Dec 2002 07:07:59 -0500 Date: Tue, 17 Dec 2002 01:06:58 +1300 From: Andrew McGregor To: hps@intermeta.de, linux-kernel@vger.kernel.org Subject: Re: RFC: p&p ipsec without authentication Message-ID: <8360000.1040040418@localhost.localdomain> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b9 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org NAT traversal can be done, in some (limited) cases even without the cooperation of the NAT (although someone on the inside must cooperate). Firewalls do be a problem. I think the best thing here is if you use this kind of thing outside the firewall; I always build networks, even LANs, with the crown jewels behind a firewall from the workstations, especially if they run Windows. Authenticated IPSEC is a nice way to find out if we can to some extent trust them, although it costs cycles. As for compatibility, there are three ways to do it presently in the IETF process (HIP, IKEv2 and FreeSWAN opportunistic mode), and two of them have running code on multiple platforms. Andrew --On Monday, December 16, 2002 09:20:27 +0000 "Henning P. Schmiedehausen" wrote: > Rik van Riel writes: > >> Hi, > >> I've got a crazy idea. I know it's not secure, but I think it'll >> add some security against certain attacks, while being non-effective >> against some others. > > While the idea itself is nice, it would allow many attackers on your > host to "dive" under IDS systems or avoid stateful firewalls which do > protocol verification. And IDS system is "a three letter acronym > listening on your traffic". And you want to avoid that. =:-) > > It won't traverse many firewalls either (because they won't let IPSEC > pass) and you might get in trouble with NAT and protocols that need > NAT fixup. > > And you basically divide the Internet into "Linux <-> Linux" and "the > rest". :-) > > Regards > Henning