RE: [Leaf-devel] New VPN/firewall security solution

2002-06-05 Thread Steven Peck

I believe this is it.
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-02.txt
http://www.vpnc.org/draft-ietf-ipsec-nat-t-ike

And oddly enough an interesting FAQ on the scope of the issue
http://www.microsoft.com/windowsxp/pro/techinfo/planning/networking/natf
aq.asp
And pretty much the same thing but not on an MS site
http://www.hometoys.com/htinews/aug01/articles/microsoft/upnp.htm

In brief, it appears to be a way to establish secure end to end
communications across NAT and the Internet specificcaly using the UPnP
standard proposed by Intel.

-sp

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]] On Behalf Of 
 Mike Noyes
 Sent: Tuesday, June 04, 2002 9:50 AM
 To: leaf-devel
 Subject: [Leaf-devel] New VPN/firewall security solution
 
 
 Everyone,
 I just noticed this story on LinuxDevices. Does anyone know 
 anything about the IETF NAT Traversal specification that is mentioned?
 
 New VPN/firewall security solution supports Embedded Linux 
 http://www.linuxdevices.com/news/NS8950961650. html
 
 -- 
 Mike 
 Noyes [EMAIL PROTECTED] 


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm


___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel



Re: [Leaf-devel] New VPN/firewall security solution

2002-06-05 Thread guitarlynn

On Wednesday 05 June 2002 23:01, Steven Peck wrote:
 I believe this is it.
snip
 In brief, it appears to be a way to establish secure end to end
 communications across NAT and the Internet specificcaly using the
 UPnP standard proposed by Intel.

Though SSH doesn't come out and say this, they are basically the
same idea. NAT causes problems with multiple clients doing the 
*same* thing at the same time. Say like multiple IPSec connections
on port 500 leaving the NAT'ed Gateway. What is proposed here is
a Nat-D type added to the approved header method (tunnel and 
transports are the current standard types). The Nat-D header
would indicate the presence of a second added header that 
includes the port number used by the machine requesting the 
service (IPSec for instance). With this NAT'ed port information
added to the packet payload, the gateway(s) will be able to 
indentify and decode the second header and send it to the 
exact machine that requested the information (identified by the
port the connection was initialized on). 

Although this may not be the best method proposed to deal with
NAT, this is a very easy method to implement and will work on
all NAT and Proxy machines that will support identification and 
routing suggested in the docs. In special cases such as the iSCSI
network storage devices, this can be built directly into the device
driver eliminating the need for encryption by a processor because
it is built into the device (driver) itself.

What advantage it would give to us at this time would amount to 
faster thoroughput times and automatic resetting of dropped 
tunnels, assuming that FreeS/WAN supports the changes in any
case.
-- 

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm


___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel