1 files changed, 0 insertions, 69 deletions
diff --git a/security/skip/files/patch-bb b/security/skip/files/patch-bb
deleted file mode 100644
index eb3518a56ddf..000000000000
--- a/security/skip/files/patch-bb
+++ /dev/null
@@ -1,69 +0,0 @@
-diff -ur --unidirectional-new-file skipsrc-1.0.orig/doc/README.FreeBSD+NAT work.new/doc/README.FreeBSD+NAT
---- skipsrc-1.0.orig/doc/README.FreeBSD+NAT	Wed Dec 31 16:00:00 1969
-+++ work.new/doc/README.FreeBSD+NAT	Mon Jan 24 12:35:42 2000
-@@ -0,0 +1,65 @@
-+Using SKIP and FreeBSD's NAT (Network Address Translation) together
-+-------------------------------------------------------------------
-+
-+Skip and NAT are two very popular strategies for building secure 
-+networks with FreeBSD.  They are sometimes believed to be incompatable 
-+when applied to the same interface.  They will work together, however,  
-+when correctly configured.  This document addresses the reference 
-+implementation of SKIP (1.0) and natd as implemented through ipfw.
-+
-+The key to understanding the operation of SKIP and NAT in parallel is to 
-+realize that inbound packets traverse the ipfw ruleset twice - once as an 
-+encapsulated packet and once as an de-encapsulated packet with the 
-+original destination address restored.  Outbound packets, on the other
-+hand, make a single pass in the unencapsulated state.  This understanding
-+can be used to advantage in building a nomadic SKIP server.  A nomadic SKIP
-+server allows any host equipped with a SKIP client to connect to the
-+Internet (eg. via a dialup connection to an ISP) and then establish a
-+secure connection to the nomadic SKIP server allowing full access to a
-+Local Area Network.  Because the remote host may have a different IP
-+address each time it connects it is known as a nomad and its KeyID is
-+used for identification rather than the IP address identification normally
-+used to establish authenticity.
-+
-+The primary difficulty in setting up a nomadic server in conjunction with 
-+NAT is not in reaching in to the LAN but in returning a response to the 
-+remote host.  The remote host IP address cannot, by definition, be known 
-+in advance.  Further - authentication of the remote host and 
-+identification of its IP address by the SKIP module does not proceed to 
-+update the routing tables in the kernel.  A LAN host receiving a 
-+connection request has insufficient information to reply to the remote 
-+host either via a static route or by dynamic routing.
-+
-+This leads to the requirement that the nomadic server must be in-line 
-+between the Internet and the LAN so that all packets not destined for the 
-+LAN are routed to the nomadic server by the gateway address in the LAN 
-+host.
-+
-+The second requirement is to prevent NAT from interfering.  NAT does 
-+not bother the SKIP pass as the packet header is directed to the 
-+nat/skiphost.  You can count the inbound SKIP packets as they 
-+can be identified by the SKIP protocol (57).  Use an ipfw rule 
-+before the NAT rule such as:
-+
-+00010 allow skip from any to any in recv fxp0
-+00100 divert 8668 ip from any to any via fxp0
-+
-+assuming that skip is identified as 57 in /etc/protocols.
-+
-+A rule is required for the de-encrypted packets to allow them to be 
-+forwarded to the LAN by the routing mechanism without interference from 
-+NAT during the second pass:
-+
-+00010 allow skip from any to any in recv fxp0
-+00020 allow ip from any to 192.168.0.0/24 in recv fxp0
-+00100 divert 8668 ip from any to any via fxp0
-+
-+Now you can have nomadic hosts connect securely as part of the LAN and 
-+hosts on the LAN can continue to access the Internet through NAT. Of 
-+course, you have to configure the skiphost ACL correctly and setup the 
-+SKIP client on the nomad to match but that's covered in the 
-+documentation. 
-+
-+Jim Flowers <jflowers@ezo.net>
-+#4 ISP on C|NET, #1 in Ohio
-+