Re: IPsec in 2.6
also sprach martin f krafft [EMAIL PROTECTED] [2003.10.09.2316 +0200]: PS: please don't CC me on mailing lists... i am sorry, you didn't. that was the other guy on another list. doh! -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! Most Intelligent Customers Realise Our Software Only Fools Them. [demime 0.97c removed an attachment of type application/pgp-signature]
Re: IPsec in 2.6
also sprach Eugen Leitl [EMAIL PROTECTED] [2003.10.09.1931 +0200]: What is wrong which just exchanging the keys for ad hoc mode? You could cache them and log whenever a key has changed (at least allowing to detect a MITM post facto). ... like SSH, huh? We're really looking for blanket rollout of a low-security service which wouldn't stand a dedicated attacker yet would effectively prevent large-scale screening of cleartext traffic as currently practised by diverse TLAs. I am all for it. This should be implementable in a cousin of isakmpd, no? PS: please don't CC me on mailing lists... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! microsoft windoze - the best solitaire game you can buy. [demime 0.97c removed an attachment of type application/pgp-signature]
Re: IPsec in 2.6
also sprach Eugen Leitl [EMAIL PROTECTED] [2003.10.09.1129 +0200]: Are there technical reasons for this situation? If yes, what is required to enable IPsec default interoperability at least with open source OSses? A curious idea that I've been paying some attention to for a while. One could simply implement a means that tries to connect with IPsec by default and falls back to IP if unsuccessful (keeping a cache of IPsec incapable hosts). The main problem here, of course, the required public key repository, if you don't want to have your keys in DNS records. And also, the expensive SA negotiation and the potential for DoS. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! it is only the modern that ever becomes old-fashioned. -- oscar wilde [demime 0.97c removed an attachment of type application/pgp-signature]
Re: IPsec in 2.6
On Thu, Oct 09, 2003 at 06:57:33PM +0200, martin f krafft wrote: A curious idea that I've been paying some attention to for a while. One could simply implement a means that tries to connect with IPsec by default and falls back to IP if unsuccessful (keeping a cache of That's how Opportunistic Encryption (OE) is supposed to work. It's just it's much too high-threshold for Joe Schmoe systems. Software firewalls are not even NATed, and increasingly cheap NAT allows IPsec tunnelling; at least single-session. IPsec incapable hosts). The main problem here, of course, the required public key repository, if you don't want to have your keys in DNS records. And also, the expensive SA What is wrong which just exchanging the keys for ad hoc mode? You could cache them and log whenever a key has changed (at least allowing to detect a MITM post facto). We're really looking for blanket rollout of a low-security service which wouldn't stand a dedicated attacker yet would effectively prevent large-scale screening of cleartext traffic as currently practised by diverse TLAs. You can always upgrade to higher paranoia layers (like web of trust, or direct exchange of secrets), but right now the entire traffic is open to sniffing and filtering at will. It's a disgrace. negotiation and the potential for DoS. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 0.97c removed an attachment of type application/pgp-signature]
Re: IPsec in 2.6
also sprach Eugen Leitl [EMAIL PROTECTED] [2003.10.09.1129 +0200]: Are there technical reasons for this situation? If yes, what is required to enable IPsec default interoperability at least with open source OSses? A curious idea that I've been paying some attention to for a while. One could simply implement a means that tries to connect with IPsec by default and falls back to IP if unsuccessful (keeping a cache of IPsec incapable hosts). The main problem here, of course, the required public key repository, if you don't want to have your keys in DNS records. And also, the expensive SA negotiation and the potential for DoS. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! it is only the modern that ever becomes old-fashioned. -- oscar wilde [demime 0.97c removed an attachment of type application/pgp-signature]
Re: IPsec in 2.6
On Thu, Oct 09, 2003 at 06:57:33PM +0200, martin f krafft wrote: A curious idea that I've been paying some attention to for a while. One could simply implement a means that tries to connect with IPsec by default and falls back to IP if unsuccessful (keeping a cache of That's how Opportunistic Encryption (OE) is supposed to work. It's just it's much too high-threshold for Joe Schmoe systems. Software firewalls are not even NATed, and increasingly cheap NAT allows IPsec tunnelling; at least single-session. IPsec incapable hosts). The main problem here, of course, the required public key repository, if you don't want to have your keys in DNS records. And also, the expensive SA What is wrong which just exchanging the keys for ad hoc mode? You could cache them and log whenever a key has changed (at least allowing to detect a MITM post facto). We're really looking for blanket rollout of a low-security service which wouldn't stand a dedicated attacker yet would effectively prevent large-scale screening of cleartext traffic as currently practised by diverse TLAs. You can always upgrade to higher paranoia layers (like web of trust, or direct exchange of secrets), but right now the entire traffic is open to sniffing and filtering at will. It's a disgrace. negotiation and the potential for DoS. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 0.97c removed an attachment of type application/pgp-signature]
Re: IPsec in 2.6
also sprach Eugen Leitl [EMAIL PROTECTED] [2003.10.09.1931 +0200]: What is wrong which just exchanging the keys for ad hoc mode? You could cache them and log whenever a key has changed (at least allowing to detect a MITM post facto). .. like SSH, huh? We're really looking for blanket rollout of a low-security service which wouldn't stand a dedicated attacker yet would effectively prevent large-scale screening of cleartext traffic as currently practised by diverse TLAs. I am all for it. This should be implementable in a cousin of isakmpd, no? PS: please don't CC me on mailing lists... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! microsoft windoze - the best solitaire game you can buy. [demime 0.97c removed an attachment of type application/pgp-signature]
