From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001
From: Harald Welte <laforge@gnumonks.org>
Date: Sun, 25 Oct 2015 21:00:20 +0100
Subject: import of old now defunct presentation slides svn repo

---
 2002/firewalling-knf-2002/toc | 100 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 100 insertions(+)
 create mode 100644 2002/firewalling-knf-2002/toc

(limited to '2002/firewalling-knf-2002/toc')

diff --git a/2002/firewalling-knf-2002/toc b/2002/firewalling-knf-2002/toc
new file mode 100644
index 0000000..8df0451
--- /dev/null
+++ b/2002/firewalling-knf-2002/toc
@@ -0,0 +1,100 @@
+- Introduction
+	- since 1995 member of KNF, now 2nd TC, newsmaster + other stuff
+	- learned lots of stuff while playing with KNF and own networks
+	- done weird stuff like UUCP-over-SSL HOWTO :)
+	- now maintainer of linux firewalling code
+
+- Basics
+	- Internet as packet switched network
+	- 7-layer-OSI
+	- Internetworking using IP
+		- unreliable, best effort, no ordering guarantees
+	- Routing within IP
+	- UDP as stateless protocol
+		- same characteristics as IP, but
+			- added ports to multiplex between apps
+			- optional payload checksum
+	- TCP as session layer
+		- providing abstraction of connection
+	 	- reliable (payload checksum, retransmissions)
+		- ordering guarantees
+		- flow control
+	- ICMP as helper
+		- error messages / diagnostics
+		- absolutely neccessary !!
+
+- potential security problems
+	- spoofed packets
+	- connections to internal, private services
+	- difficult to guarantee security on all internal hosts
+	- restrictions the other way around (for outbound connections)
+	- 
+
+- solution 1: packet filters
+	- operates on layer 3
+	- filter packets based on packet header/content
+	- alternatively also generate ICMP errors, RST packets
+
+	- extensions / derivates
+		- stateful firewalling
+		- transparent firewalls (firewalling bridges)
+
+- solution 2: proxies
+	- layer 5+
+	- description
+	- explicit configuration of all clients
+
+	- extensions / derivates
+		- transparent proxies
+		- SOCKS
+			- needs explicit application support
+			- solves authentication problem
+			- not used widely
+			- should be offered in addition to proxies
+			  to give users a chance of running 'weird' prtoocols
+			  without httptunnel.
+
+- comparison
+	- proxy
+		+ no knowledge about protocol headers needed
+		+ configuration extremely easy
+		+ address space separated (no need for NAT)
+		+ integrates easily with other applications like IDS
+		+ easy implementation, just normal programs
+		- seperate proxies needed for almost every protocol
+		- bad performance
+		- uses lots of ressources (i.e. sockets) on gateway
+		- horribly breaks end-to-end
+		- needs configuration of enduser applications, if not
+		  used as transparent proxies
+
+	- packet filter
+		+ total control on lowest per-packet level
+		+ very high performance
+		+ possible to implement failover / load balancing
+		+ NAT as extension solves address space problem 
+		- configuration requires high knowledge on TCP/IP protocols
+		- problems when no state/window tracking is done
+		- support for complex protocols (h.323, SIP, ...) difficult
+		  to implement
+
+	- transparent proxies
+		- use some ideas of packet filtering / NAT to achieve
+		  transparency
+
+	- stateful packet filters
+		- use some ideas of proxies (tracking of higher layer state)
+		  to achieve better security and easier configuration
+
+	- summary:
+		- proxies work for small installations where number of
+		  to-be-supported protocols small and administrative stuff
+		  not very experienced
+		- packet filters without state tracking difficult to be
+		  configured correctly
+		- packet filters with state tracking are a good solution for
+		  most usage scenarios: powerful, but yet easy to configure
+		  right :)
+		- for highest security, they can be combined: imagine a
+		  stateful bridging packet filter in front of proxies :)
+
-- 
cgit v1.2.3