import of old now defunct presentation slides svn repo

27 files changed, 6378 insertions, 0 deletions

diff --git a/2002/firewalling-knf-2002/abstract b/2002/firewalling-knf-2002/abstract
new file mode 100644
index 0000000..8169aa2
--- /dev/null
+++ b/2002/firewalling-knf-2002/abstract
@@ -0,0 +1,48 @@
+Grundlagen des Firewallings - Sicherheit in IP-Netzwerken
+=========================================================
+
+Was ist eine Firewall?  
+Was macht eine Firewall genau?  
+Was fuer Unterschiede gibt es zwischen Firewalls?
+Wo ist der Unterschied zwischen Paketfiltern und Proxies?
+
+Mit diesen (und anderen) Fragen beschaeftigt sich der KNF-Vortrag ueber die
+Grundlagen des Firewallings.
+
+Ausgehend von einem grundlegenden Wissen ueber TCP/IP Netzwerke und Router
+beschreibt dieser Vortrag die dem Firewalling zugrunde liegenden Konzepte
+und Strategien, sowie deren Moeglichkeiten.
+
+In dem Vortrag wird bewusst nicht auf bestimmte Firewall-Produkte oder
+Implementationen eingegangen, es sind daher auch keinerlei Vorkenntnisse
+in der Anwendung / Administration einer Firewall noetig.
+
+Gliederung:
+
+- Kurzer Ueberblick ueber IP-Routing, TCP, UDP, ICMP
+- Paketfilter
+	- Funktionsweise
+	- traditionelle Paketfilter (ohne state)
+	- stateful firewalling (connection tracking)
+
+- Proxies
+	- Funktionsweise
+	- 'normale' Proxies
+	- transparente Proxies
+
+- Vergleich Paketfilter/Proxy
+	- daraus abgeleitet
+		- Moeglichkeiten
+		- Einsatzbereiche
+
+- Network Address Translation (NAT)
+	- static NAT
+	- static NAPT 
+	- symmetric NAPT
+	- masquerading
+
+Ueber den Vortragenden:
+Harald Welte ist seit 1995 aktives KNF-Mitglied und der derzeitige 
+stellvertretende Technische Kontakt des KNF.  Er ist der Maintainer des
+netfilter/iptables Firewalling-Subsystems im Linux 2.4.x und
+2.5.x Kernel und war massgeblich an dessen Entwicklung beteiligt.
diff --git a/2002/firewalling-knf-2002/firewall.mgp b/2002/firewalling-knf-2002/firewall.mgp
new file mode 100644
index 0000000..d277a35
--- /dev/null
+++ b/2002/firewalling-knf-2002/firewall.mgp
@@ -0,0 +1,312 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+TCP/IP Firewalling Basics
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@sunbeam.franken.de>
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Contents
+
+	Introduction
+
+	Networking Basics
+
+	Potential Security Problems
+
+	Solution 1: Packet Filters
+
+	Solution 2: Proxies
+
+	Comparison
+
+	Summary
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Introduction
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Firewalling Basics
+Networking Basics
+
+	7 layer OSI model used to abstract networking protocols
+		layer 7: application layer: e.g. telnet/ftp
+		layer 6: presentation layer:
+		layer 5: session layer: 
+		layer 4: transport layer: e.g. TCP/UDP
+		layer 3: network layer: e.g. IP
+		layer 2: data link layer: e.g. Ethernet
+		layer 1: physical layer: e.g. Wire
+	Layer 1 + 2 embedded in hardware
+	Layer 3 + 4 implemented in operating system
+	Layer 5+ embedded in application program
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Networking Basics
+
+	Layer 2: Ethernet
+		enables two hosts within same pysical net to exchange packets
+		unreliable
+		adressing granularity: host
+		fixed hardware adresses (MAC adress, 48bit)
+
+	Layer 3: Internet Protocol (IP)
+		enables two hosts in diferent physical networks to exchange packets
+		unreliable, best effort
+			packet reordering
+			packet loss
+		adressing granularity: host
+		logical adresses (IP Adress, 32bit)
+		checksum protects only IP header
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Networking Basics
+
+	Layer 4: User Datagram Protocol (UDP)
+		unreliable, best effort
+		adressing granularity: ports (16bit = 65535)
+		optional payload checksum
+
+	Layer 4: Transmission Control Protocol (TCP)
+		provides connection abstraction
+		reliable
+			ordering guarantee
+			retransmissions correct packet loss
+			flow control
+			payload checksum protects payload from data corruption
+
+	Layer 4: Internet Control Message Protocol (ICMP)
+		used internally by TCP/IP protocol suite
+			error messages (e.g. host unreachable)
+			diagnostics (e.g. ping/pong)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Potential Security Problems
+
+	Security issues arise at interconnection of two networks
+		Traditional Case: IP Router connecting an organization internal network to the Internet
+
+	What Security Problem?
+		organization-internal services exposed to outside network
+		spoofed (forged) packets to circumvent 'security by address'
+		even if all internal services secured by authentication, difficult to guarantee security on all internal hosts
+
+	Why Firewalling?
+		to restrict which internal services are exposed to the outside
+		to restrict which outside services are used by internal users
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Firewalling Basics
+Solution 1: Packet Filters
+
+	Filter individual packets at network interconnection (Router)
+
+	Filter criteria traditionally include
+		IP source + destination address
+		TCP/UDP source + destination port
+		TCP header flags
+
+	Filtering rules determine if
+		packet is allowed to transit interconnection
+		packet is silently dropped
+		packet is dropped and error message returned to sender
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Solution 1: Packet Filters
+
+	Capabilities
+		disallow communication between certain IP adresses
+		disallow communication between certain port numbers
+		disallow malicious packets, like packets
+			using source routing IP option
+			impossible combination of features, like tcp xmas scan
+		generate log of malicious and/or filtered packets
+
+	Limitations
+		scope limited to individual packets
+		no ability to look inside packet payload (HTTP 1.1 virtual hosts)
+		no abstraction of connection, filtering rules needed for both directions
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Solution 1: Packet Filters
+
+	Extensions
+		stateful packet filters (connection tracking)
+			filtering only needed for connection-initiating packets
+			all other packets within connection are accepted as part of an already established connection
+
+		TCP window tracking
+			allow filtering not only on source/dest port but also on  TCP sequence number
+
+		NAT (Network Address Translation)
+			manipulation of source / destination address
+			redirect packets to other hosts
+			'share' one ip address at dialup accounts (masquerading)
+			connect two networks with overlapping addresss ranges
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Solution 2: Proxies
+
+	A proxy operates at layer 5 and above
+
+	Mode of operation
+		client connects to proxy instead of server
+		proxy initiates a second, seperate connection to server
+
+		Proxies are just normal programs implementing a server and a client for a particular application protocol (e.g. HTTP) using operating system mechanisms (like sockets API, winsock, ...)
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Solution 2: Proxies
+
+	Capabilities
+		disallow communication between certain IP adresses
+		disallow communication between certain ports
+		disallow communication based on packet payload
+			e.g. pathnames / filenames within HTTP and FTP
+			e.g. email-adresses within SMTP
+			e.g. hostnames within DNS (www.netzzensur.de)
+			e.g. badwords ('sex' and 'teen' within same file)
+		manipulation of packet payload
+			everything possible...
+
+	Limitations
+		somebody needs to tell client app to connect to proxy instead of server
+		seperate proxies for all used protocols needed
+		not possible to filter on packet options, etc.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Solution 2: Proxies
+
+	Extensions
+		Transparent Proxies
+			accept connections from client independent of dest IP
+			make reply packets to the client look like as sent by server
+			possibly to implement same transparancy towards server
+			no need to tell clients about proxies anymore!
+
+		SOCKS
+			application protocol indepentent proxy
+			one proxy for all application protocols
+			uses seperate protocol between client and proxy
+			needs explicit support from client application
+			integrated username/password authentication 
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Comparison
+
+	Packet Filter
+		pro
+			total control on lowest per-packet level
+			very high performance
+			possible to implement failover / load balancing
+			NAT as extension solves adress space problem
+		contra
+			configuration requires sophisticated knowledge
+			problems when no state / window tracking used
+			support for complex protocols (H.323, SIP) difficult to implement
+	Proxy
+		pro
+			no knowledge about layer3/4 protocol needed
+			configuration very easy
+			address space automatically seperated
+			integrates easily with other applications like IDS
+			easy implementation, just normal application programs
+		contra
+			seperate proxies needed for almost every protocol
+			bad performance
+			uses lots of ressources (e.g. sockets) on gatway
+			horribly breaks end-to-end
+			needs explicit configuration of client apps if not transparent proxy
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Comparison
+
+	Transparent Proxy
+		uses ideas/methods of packet filtering (NAT) to achieve protocol transparence
+		horrible violation of layering
+
+	Stateful Packet Filter
+		uese ideas of proxies (tracking of higher layer state) to achieve better security and easieer configuration
+		horrible violation of layering
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Conclusion
+
+	Conclusion
+		proxies work for small installations where number of used protocols is small and administrative staff not very experienced
+		packet filters without state tracking are difficult to configure correctly
+		packet filters with state tracking are good solution for most usage scenarios: powerful but yet easy to configure correctly
+		for highest security, best of both worlds can be combined
+			imagine a stateful bridging packet filter in front of a proxy :)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Firewalling Basics
+Thanks
+
+	Thanks to
+		the BBS people, Z-Netz, FIDO, ...
+			for heavily increasing my computer usage in 1992
+
+		KNF
+			for bringing me in touch with the internet as early as 1995
+			for providing a playground for technical people
+			for telling me about the existance of Linux!
+
+		Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen
+			for implementing (one of?) the world's best TCP/IP stacks
+
+		Paul 'Rusty' Russell
+			for starting the netfilter/iptables project
+			for trusting me to maintain it today
+
+		Linux User Group Nuernberg (ALIGN, LUG-N)
+			for helping me with my initial Linux problems
+
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 :)
+
diff --git a/2002/ipv6-ccc2002/ipv6-ccc2002.mgp b/2002/ipv6-ccc2002/ipv6-ccc2002.mgp
new file mode 100644
index 0000000..b64103e
--- /dev/null
+++ b/2002/ipv6-ccc2002/ipv6-ccc2002.mgp
@@ -0,0 +1,243 @@
+%include "default.mgp"
+%default 1 bgrad
+%deffont "typewriter" tfont "MONOTYPE.TTF"
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+IPv6 Introduction
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@rfc2460.org>
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+What? Why?
+
+
+	What is IPv6?
+
+		Successor of currently used IP Version 4
+		Specified 1995 in RFC 2460
+
+	Why?
+
+		Address space in IPv4 too small
+		Routing tables too large
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+Advantages
+
+
+	Advantages
+
+		stateless autoconfiguration
+		multicast obligatory
+		IPsec obligatory
+		Mobile IP
+
+		Address renumbering
+		Multihoming
+		Multiple address scopes
+		smaller routing tables through aggregatable allocation
+
+		simplified l3 header
+			64bit aligned
+			no checksum (l4 or l2)
+			no fragmentation at router
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+Disadvantages
+
+	Disadvantages
+		Not widely deployed yet
+		In most cases access only possible using manual tunnel
+		OS support not ideal in most cases
+			W2k: IPv6 available from MSi
+			Windows XP: IPv6 included
+			Linux has support, but some flaws (no IPsec, ndisc not fully implemented, ...)
+			*BSD: full support (KAME)
+			Solaris: full support
+		Application support not ideal in most cases
+			not supported: postfix, current squid, inn, proftpd,
+			supported: bind8/9, apache, openssh, xinetd, rsync, squid-2.5(CVS), exim, zmailer, sendmail, qmail, inn-2.4(CVS), zebra
+
+		Conclusion: Circular dependencies
+			no application support without OS support
+			no good OS support without applications
+			no wide deployment without applications
+			no applications without deployment
+			no deployment without applications
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+Deployment
+
+
+	Experimental (6bone)
+		Experimental 6bone (3ffe::) has been active since 1995.
+		Uses slightly different Addressing Architecture (RFC2471)
+
+	Production (2001::)
+		Initial TLA's and sub-TLA's assigned in Sept 2000
+		Mostly used in education+research
+		Some commercial ISP's in .de are offering production prefixes
+
+	Why isn't IPv6 widely used yet?
+		No immediate need in Europe / North America
+		Big deployment cost at ISP's (Training, Routers, ..)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+Technical: Address Space
+
+	IP Version 6 Addressing Architecture (RFC2373)
+		Format prefix, variable length
+			001: RFC2374 addresses, 1/8 of address space
+			0000 001: Reserved for NSAP (1/128)
+			0000 010: Reserved for IPX (1/128)
+			1111 1110 10: link-local unicast addresses (1/1024)
+			1111 1110 11: site-local unicast addresses (1/1024)
+			1111 1111 flgs scop: multicast addresses
+				flgs (0: well-known, 1:transient)
+				scop (0: reserved, 1: node-local, 2: link-local, 5: site-local, 8: organization-local, e: global scope, f: reserved)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+Technical: Address Space
+
+		Aggregatable Global Unicast Address Format (RFC2374)
+			3bit FP (format prefix = 001)
+			13bit TLA ID - Top-Level Aggregation ID
+			13bit Sub-TLA - Sub-TLA Aggergation ID
+			19bit NLA - Next-Level Aggregation ID
+			16bit SLA - Site-Level Aggregation ID
+			64bit Interface ID - derived from 48bit ethernet MAC
+		Initial subTLA-Assignments
+			2001:0000::/29 - 2001:01f8::/29 IANA
+			2001:0200::/29 - 2001:03f8::/29 APNIC
+			2001:0400::/29 - 2001:05f8::/29 ARIN
+			2001:0600::/29 - 2001:07f8::/29 RIPE
+		loopback ::1
+		unspecified: ::0
+		embedded ipv4
+			IPv4-compatible address: 0::xxxx:xxxx
+			IPv4-mapped IPv4 (IPv4 only node): 0::ffff:xxxx:xxxx
+		anycast
+			allocated from unicast addresses
+			only subnet-router anycast address predefined (prefix::0000)
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+Technical: Header
+
+%font "typewriter"
+%size 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Version| Traffic Class |           Flow Label                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Payload Length        |  Next Header  |   Hop Limit   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +                         Source Address                        +
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +                      Destination Address                      +
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+%font "standard"
+		4bit Version: 6
+		8bit Traffic Class
+		20bit Flow Label
+		16bit Payload Length (incl. extension hdrs)
+		8bit next header (same values like IPv4, RFC1700 et seq.)
+		8bit hop limit (TTL)
+		128bit source address
+		128bit dest address
+		extension headers:
+			hop-by-hop options
+			routing
+			fragment
+			destination options
+			IPsec (AH/ESP)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+Technical: Layer 2 <-> Address mapping
+
+
+	Ethernet: No more ARP, everything within ICMPv6
+	No Broadcast, everything built using multicast.
+
+	all-nodes multicast address ff02::1
+	all-routers multicast address ff02::2
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+Technical: Address Configuration
+
+
+	router discovery
+		routers periodically send router advertisements
+		hosts can send router solicitation to explicitly request RADV
+
+	prefix discovery
+		router includes prefix(es) in ICMPv6 router advertisements
+		other nodes receive prefix advertisements and derive their final address from prefix + EUI64 of MAC address
+
+	neighbour discovery
+		machines can discover it's neighbours without advertising router
+
+
+%page
+IPv6 Introduction
+How to get connected
+
+	In case of static IPv4 address
+		SIT (ipv6-in-ipv4) tunnel possible
+		http://www.join.uni-muenster.de/
+
+	In case of dynamic IPv4 address
+		ppp (ipv6 over ppp) tunnel (pptp, l2tp) possible
+		sitctrl (linux <-> linux)
+		atncp (*NIX), http://www.dhis.org/atncp/
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+IPv6 Introduction
+Further Reading
+
+	http://www.ipv6-net.org/ (deutsches IPv6 forum)
+	http://www.6bone.net/ (ipv6 testing backbone)
+	http://www.freenet6.net/ (free tunnel broker)
+	http://hs247.com/ (list of tunnel brokers)
+
+	http://www.bieringer.de/ (ipv6 for linux)
+	http://www.linux-ipv6.org/ (improved ipv6 for linux)
+	http://www.kame.net/ (ipv6 for *BDS)
+	http://www.join.uni-muenster.de/ (ipv6 at DFN/WiN)
+
+	http://www.gnumonks.org/ (slides of this presentation)
+
+	And of course, all relevant RFC's 
+
diff --git a/2002/ipv6-ccc2002/topics b/2002/ipv6-ccc2002/topics
new file mode 100644
index 0000000..da33a44
--- /dev/null
+++ b/2002/ipv6-ccc2002/topics
@@ -0,0 +1,114 @@
+What is IPv6?
+	Successor of currently used IP Version 4
+	Specified 1995 in RFC?  2460
+Why?
+	Address space in IPv4 too small
+
+Advantages?
+	stateless autoconfiguration
+	multicast obligatorisch
+	IPsec obligatorisch
+	Mobile IP
+	QoS ?
+	
+	Address Renumbering?
+	Multihoming?
+	AddressScopes?
+	smaller routing tables through G
+
+	simplified l3 header
+		64bit aligned
+		no checksum (l4 or l2)
+		no fragmentation at router
+
+Disadvantages
+	Not widely deployed yet
+	In most cases access only possible using manual tunnel
+	OS support not ideal in most cases
+		W2k?
+		Linux has support, but no IPsec in official tree -> USAGI
+		*BSD: full support (KAME
+	Application support not ideal in most cases
+		not supported: 
+		supported: bind8/9, apache
+
+Deployment
+	Experimental 6bone (3ffe::) has been active since 199x.
+	Uses slightly different Addressing Architecture (RFC2471)
+	
+Why isn't it widely used yet?
+	No immediate need in Europe / North America
+	Big deployment cost at ISP's (Training, Routers, ..)
+
+Technical: Address Space
+	IP Version 6 Addressing Architecture (RFC2373)
+		Format prefix, variable length
+			001: RFC2374 addresses, 1/8 of address space
+			0000 001: Reserved for NSAP (1/128)
+			0000 010: Reserved for IPX (1/128)
+			1111 1110 10: link-local unicast addresses (1/1024)
+			1111 1110 11: site-local unicast addresses (1/1024)
+			1111 1111: multicast addresses
+				1111 1111 flgs scop
+					flgs (0: well-known, 1:transient)
+					scop (0: reserved, 1: node-local, 2: link-local, 5: site-local, 8: organization-local, e: global scope, f: reserved)
+	Aggregatable Global Unicast Address Format (RFC2374)
+		3bit FP (format prefix = 001)
+		13bit TLA ID - Top-Level Aggregation ID
+		13bit Sub-TLA - Sub-TLA Aggergation ID
+		19bit NLA - Next-Level Aggregation ID
+		16bit SLA - Site-Level Aggregation ID
+		64bit Interface ID - derived from 48bit ethernet MAC
+
+		2001:0000::/29 - 2001:01f8::/29 IANA
+		2001:0200::/29 - 2001:03f8::/29 APNIC
+		2001:0400::/29 - 2001:05f8::/29 ARIN
+		2001:0600::/29 - 2001:07f8::/29 RIPE
+	loopback
+		::1
+	unspecified:
+		::0
+	embedded ipv4
+		IPv4-compatible address: 0::xxxx:xxxx
+		IPv4-mapped IPv4 (IPv4 only node): 0::ffff:xxxx:xxxx
+	anycast
+		allocated from unicast addresses
+		only subnet-router anycast address predefined (prefix::0000)
+
+
+Technical: Header
+
+	4bit Version: 6
+	8bit Traffic Class
+	20bit Flow Label
+	16bit Payload Length (incl. extension hdrs)
+	8bit next header (same values like IPv4, RF1700 et seq.)
+	8bit hop limit (TTL)
+	128bit source address
+	128bit dest address
+	
+	extension headers:
+		hop-by-hop options
+		routing
+		fragment
+		destination options
+		authentication
+		encapsulating security payload
+
+Technical: Layer 2 <-> Address mapping
+	Ethernet: No more ARP, everything within ICMPv6
+	No Broadcast, everything built using multicast.
+
+	all-nodes multicast address ff02::1
+	all-routers multicast address ff02::2
+	
+	
+Technical: Address Configuration
+	router discovery
+		routers periodically send router advertisements
+		hosts can send router solicitation to explicitly request RADV
+	prefix discovery
+		router includes prefix(es) in ICMPv6 router advertisements
+		other nodes receive prefix advertisements and derive their final address from prefix + EUI64 of MAC address
+
+
diff --git a/2002/netfilter-bof-ols2002/abstract b/2002/netfilter-bof-ols2002/abstract
new file mode 100644
index 0000000..f70cb6a
--- /dev/null
+++ b/2002/netfilter-bof-ols2002/abstract
@@ -0,0 +1,25 @@
+Future directions of linux firewalling
+
+Harald Welte, netfilter core team & Astaro AG
+
+The Linux 2.4.x series provided a fundamental redesign of the packet filtering
+and NAT framework, called netfilter/iptables.  This flexible and modular
+framwork still had it's limitations.  This BOF will discuss the recent and
+upcoming changes during the 2.4.x kernel series, as well as planned and
+partially implemented changes/extensions for the 2.5.x kernel series.
+
+Topics covered:
+
+2.4.x stuff:
+- The newnat API; supporting connection tracking and NAT for complex protocols
+  like H.323
+- Accessing connection tracking table entries from userspace: ctnetlink
+- Packet filtering and even NAT on a bridge
+
+2.5.x stuff:
+- libiptables: Providing a flexible and extensible API towards all iptables
+  features
+- pkttables: Creating a layer-3-protocol independent layer for rule tables;
+  unifying iptables, ip6tables and arptables.
+- nfnetlink: Move all netfilter/iptables related kernel/userspace communication
+  towards netlink
diff --git a/2002/netfilter-curdevel-lk2002/netfilter-curdevel-lk2002.mgp b/2002/netfilter-curdevel-lk2002/netfilter-curdevel-lk2002.mgp
new file mode 100644
index 0000000..987162b
--- /dev/null
+++ b/2002/netfilter-curdevel-lk2002/netfilter-curdevel-lk2002.mgp
@@ -0,0 +1,374 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+The future of Linux packet filtering
+targeted for kernel 2.6 and beyond
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@gnumonks.org>
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Contents
+
+
+	Problems with current 2.4.x netfilter/iptables
+		Solution to code replication
+		Solution for dynamic rulesets
+		Solution for API to GUI's and other management programs
+
+	HA for stateful firewalling
+		What's special about firewalling HA
+		Poor man's failover
+		Real state replication
+
+	Other current work
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Problems with 2.4.x netfilter/iptables
+
+	code replication between iptables/ip6tables/arptables
+		iptables was never meant for other protocols, but people did copy+paste 'ports'
+		replication of
+			core kernel code
+			layer 3 independent matches (mac, interface, ...)
+			userspace library (libiptc)
+			userspace tool (iptables)
+			userspace plugins (libipt_xxx.so)
+
+	doesn't suit the needs for dynamically changing rulesets
+		dynamic rulesets becomming more common due (service selection, IDS)
+		a whole table is created in userspace and sent as blob to kernel
+		for every ruleset the table needs to be copied to userspace and back
+		inside kernel consistency checks on whole table, loop detection
+
+	too extensible for writing any forward-compatible GUI
+		new extensions showing up all the time
+		a frontend would need to know about the options and use of a new extension
+		thus frontends are always incomplete and out-of-date
+		no high-level API other than piping to iptables-restore
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Reducing code replication
+
+	code replication is a real problem: unclean, bugfixes missed
+	we need layer 3 independent layer for
+		submitting rules to the kernel
+		traversing packet-rulesets supporting match/target modules
+		registering matches/targets
+			layer 3 specific (like matching ipv4 address)
+			layer 3 independent (like matching MAC address)
+
+	solution
+		pkt_tables inside kernel
+			pkt_tables_ipv4 registers layer 3 handler with pkt_tables
+			pkt_tables_ipv6 registers layer 3 handler with pkt_tables
+			everybody registering a pkt_table (like iptable_filter) needs to specify the l3 protocol
+		libraries in userspace (see later)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Supporting dynamic rulesets
+
+	atomic table-replacement turned out to be bad idea
+	need new interface for sending individual rules to kernel
+	policy routing has the same problem and good solution: rtnetlink
+	solution: nfnetlink
+		multicast-netlink based packet-orinented socket between kernel and userspace
+		has extra benefit that other userspace processes get notified of rule changes [just like routing daemons]
+		nfnetlink is a low-layer below all kernel/userspace communication
+			pkttnetlink [aka iptnetlink]
+			ctnetlink
+			ulog
+			ip_queue
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Communication with other programs
+
+whole set of libraries
+	libnfnetlink for low-layer communication
+	libpkttnetlink for rule modifications
+		will handle all plugins [which are currently part of iptables]
+		query functions about avaliable matches/targets
+		query functions about parameters
+		query functions for help messages about specific match/parameter of a match
+		generic structure from which rules can be built
+		conversion functions to parse generic structure into in-kernel structure
+		conversion functiosn to perse kernel structure into generic structure
+		functions to convert generic structure in plain text
+	libipq will stay API-compatible to current version
+	libipulog will stay API-compatible to current version
+	libiptc will go away [compatibility layer extremely difficult]
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+HA for netfillter/iptables
+Introduction
+
+What is special about firewall failover?
+
+	Nothing, in case of the stateless packet filter
+		Common IP takeover solutions can be used
+			VRRP
+			Hartbeat
+
+	Distribution of packet filtering ruleset no problem
+		can be done manually
+		or implemented with simple userspace process
+
+	Problems arise with stateful packet filters
+		Connection state only on active node
+		NAT mappings only on active node
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Connection tracking...
+
+	implemented seperately from NAT 
+	enables stateful filtering 
+	implementation
+		hooks into NF_IP_PRE_ROUTING to track packets
+		hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules
+		protocol modules (currently TCP/UDP/ICMP)
+		application helpers currently (FTP,IRC,H.323,talk,SNMP)
+	divides packets in the following four categories
+		NEW - would establish new connection
+		ESTABLISHED - part of already established connection
+		RELATED - is related to established connection
+		INVALID - (multicast, errors...)
+	does _NOT_ filter packets itself
+	can be utilized by iptables using the 'state' match 
+	is used by NAT Subsystem
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Common structures
+	struct ip_conntrack_tuple, representing unidirectional flow
+		layer 3 src + dst 
+		layer 4 protocol
+		layer 4 src + dst
+
+
+	connetions represented as struct ip_conntrack
+		original tuple
+		reply tuple
+		timeout
+		l4 state private data
+		app helper
+		app helper private data
+		expected connections
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for new packet
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple) -> fails
+		new ip_conntrack is allocated
+			fill in original and reply == inverted(original) tuple
+			initialize timer
+			assign app helper if applicable
+			see if we've been expected -> fails
+			call layer 4 helper 'new' function
+
+	...
+
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> fails
+		place struct ip_conntrack in hashtable			
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for packet part of existing connection
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple)
+		assosiate conntrack entry with skb->nfct
+		call l4 protocol helper 'packet' function
+			do l4 state tracking
+			update timeouts as needed [i.e. TCP TIME_WAIT,...]
+
+	...
+	
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> succeds
+		do nothing else
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Poor man's failover
+
+Poor man's failover
+	principle
+		let every node do it's own tracking rather than replicating state
+	two possible implementations
+		connect every node to shared media (i.e. real ethernet)
+			forwarding only turned on on active node
+			slave nodes use promiscuous mode to sniff packets
+		copy all traffic to slave nodes
+			active master needs to copy all traffic to other nodes
+			disadvantage: high load, sync traffic == payload traffic
+			IMHO stupid way of solving the problem 
+	advantages
+		very easy implementation
+			only addition of sniffing mode to conntrack needed
+			existing means of address takeover can be used
+		same load on active master and slave nodes
+		no additional load on active master
+	disadvantages
+		can only be used with real shared media (no switches, ...)
+		can not be used with NAT
+	remaining problem
+		no initial state sync after reboot of slave node!
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Real state replication
+
+Parts needed
+	state replication protocol
+		multicast based
+		sequence numbers for detection of packet loss
+		NACK-based retransmission
+		no security, since private ethernet segment to be used
+	event interface on active node
+		calling out to callback function at all state changes
+	exported interface to manipulate conntrack hash table
+	kernel thread for sending conntrack state protocol messages
+		registers with event interface
+		creates and accumulates state replication packets
+		sends them via in-kernel sockets api
+	kernel thread for receiving conntrack state replication messages
+		receives state replication packets via in-kernel sockets
+		uses conntrack hashtable manipulation interface
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Real state replication
+
+	Flow of events in chronological order:
+		on active node, inside the network RX softirq
+			connection tracking code is analyzing a forwarded packet
+			connection tracking gathers some new state information
+			connection tracking updates local connection tracking database
+			connection tracking sends event message to event API
+		on active node, inside the conntrack-sync kernel thread
+			conntrack sync daemon receives event through event API
+			conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy
+			conntrack sync daemon generates state replication protocol message
+			conntrack sync daemon sends state replication protocol message
+		on slave node(s), inside network RX softirq
+			connection tracking code ignores packets coming from the interface attached to the private conntrac sync network
+			state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread
+		on slave node(s), inside conntrack-sync kernel thread
+			conntrack sync daemon receives state replication message
+			conntrack sync daemon creates/updates conntrack entry
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Neccessary changes to kernel
+
+Neccessary changes to current conntrack core
+
+	event generation (callback functions) for all state changes
+
+	conntrack hashtable manipulation API
+		is needed (and already implemented) for 'ctnetlink' API
+
+	conntrack exemptions
+		needed to _not_ track conntrack state replication packets
+		is needed for other cases as well
+		currently being developed by Jozsef Kadlecsik
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Other current work
+
+	optimizing the conntrack code
+		hash function optimization
+			current hash function not good for even hash bucket count
+			other hash functions in development
+			hash function evaluation tool [cttest] avaliable
+			introduce per-system randomness to prevent hash attack
+		code optimization (locking/timers/...)
+
+	getting our work submitted into the mainstream kernel
+		turns out to be more difficult
+			e.g. newnat api now waiting for three months
+
+	discussions about multiple targets/actions per rule
+		technical implementation easy
+		however, not everybody convinced that it fits into the concept
+
+	using tc for firewalling
+		Jamal Hadi Selim uses iptables targets from within TC
+		leads to discussion of generic classification engine API in kernel
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Thanks
+	The slides and the an according paper of this presentation are available at http://www.gnumonks.org/
+
+	The netfilter homepage http://www.netfilter.org/
+
+	Thanks to
+		the BBS people, Z-Netz, FIDO, ...
+			for heavily increasing my computer usage in 1992
+		KNF
+			for bringing me in touch with the internet as early as 1994
+			for providing a playground for technical people
+			for telling me about the existance of Linux!
+		Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen
+			for implementing (one of?) the world's best TCP/IP stacks
+		Paul 'Rusty' Russell
+			for starting the netfilter/iptables project
+			for trusting me to maintain it today
+		Astaro AG
+			for sponsoring parts of my netfilter work
+
diff --git a/2002/netfilter-curdevel-lsm2002/netfilter-curdevel-lsm2002.mgp b/2002/netfilter-curdevel-lsm2002/netfilter-curdevel-lsm2002.mgp
new file mode 100644
index 0000000..96e12f5
--- /dev/null
+++ b/2002/netfilter-curdevel-lsm2002/netfilter-curdevel-lsm2002.mgp
@@ -0,0 +1,374 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+The future of Linux packet filtering
+targeted for kernel 2.6
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@gnumonks.org>
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Contents
+
+
+	Problems with current 2.4.x netfilter/iptables
+		Solution to code replication
+		Solution for dynamic rulesets
+		Solution for API to GUI's and other management programs
+
+	HA for stateful firewalling
+		What's special about firewalling HA
+		Poor man's failover
+		Real state replication
+
+	Other current work
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Problems with 2.4.x netfilter/iptables
+
+	code replication between iptables/ip6tables/arptables
+		iptables was never meant for other protocols, but people did copy+paste 'ports'
+		replication of
+			core kernel code
+			layer 3 independent matches (mac, interface, ...)
+			userspace library (libiptc)
+			userspace tool (iptables)
+			userspace plugins (libipt_xxx.so)
+
+	doesn't suit the needs for dynamically changing rulesets
+		dynamic rulesets becomming more common due (service selection, IDS)
+		a whole table is created in userspace and sent as blob to kernel
+		for every ruleset the table needs to be copied to userspace and back
+		inside kernel consistency checks on whole table, loop detection
+
+	too extensible for writing any forward-compatible GUI
+		new extensions showing up all the time
+		a frontend would need to know about the options and use of a new extension
+		thus frontends are always incomplete and out-of-date
+		no high-level API other than piping to iptables-restore
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Reducing code replication
+
+	code replication is a real problem: unclean, bugfixes missed
+	we need layer 3 independent layer for
+		submitting rules to the kernel
+		traversing packet-rulesets supporting match/target modules
+		registering matches/targets
+			layer 3 specific (like matching ipv4 address)
+			layer 3 independent (like matching MAC address)
+
+	solution
+		pkt_tables inside kernel
+			pkt_tables_ipv4 registers layer 3 handler with pkt_tables
+			pkt_tables_ipv6 registers layer 3 handler with pkt_tables
+			everybody registering a pkt_table (like iptable_filter) needs to specify the l3 protocol
+		libraries in userspace (see later)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Supporting dynamic rulesets
+
+	atomic table-replacement turned out to be bad idea
+	need new interface for sending individual rules to kernel
+	policy routing has the same problem and good solution: rtnetlink
+	solution: nfnetlink
+		multicast-netlink based packet-orinented socket between kernel and userspace
+		has extra benefit that other userspace processes get notified of rule changes [just like routing daemons]
+		nfnetlink will be low-layer below all kernel/userspace communication
+			pkttnetlink [aka iptnetlink]
+			ctnetlink
+			ulog
+			ip_queue
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Communication with other programs
+
+whole set of libraries
+	libnfnetlink for low-layer communication
+	libpkttnetlink for rule modifications
+		will handle all plugins [which are currently part of iptables]
+		query functions about avaliable matches/targets
+		query functions about parameters
+		query functions for help messages about specific match/parameter of a match
+		generic structure from which rules can be built
+		conversion functions to parse generic structure into in-kernel structure
+		conversion functiosn to perse kernel structure into generic structure
+		functions to convert generic structure in plain text
+	libipq will stay API-compatible to current version
+	libipulog will stay API-compatible to current version
+	libiptc will go away [compatibility layer extremely difficult]
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+HA for netfillter/iptables
+Introduction
+
+What is special about firewall failover?
+
+	Nothing, in case of the stateless packet filter
+		Common IP takeover solutions can be used
+			VRRP
+			Hartbeat
+
+	Distribution of packet filtering ruleset no problem
+		can be done manually
+		or implemented with simple userspace process
+
+	Problems arise with stateful packet filters
+		Connection state only on active node
+		NAT mappings only on active node
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Connection tracking...
+
+	implemented seperately from NAT 
+	enables stateful filtering 
+	implementation
+		hooks into NF_IP_PRE_ROUTING to track packets
+		hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules
+		protocol modules (currently TCP/UDP/ICMP)
+		application helpers currently (FTP,IRC,H.323,talk,SNMP)
+	divides packets in the following four categories
+		NEW - would establish new connection
+		ESTABLISHED - part of already established connection
+		RELATED - is related to established connection
+		INVALID - (multicast, errors...)
+	does _NOT_ filter packets itself
+	can be utilized by iptables using the 'state' match 
+	is used by NAT Subsystem
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Common structures
+	struct ip_conntrack_tuple, representing unidirectional flow
+		layer 3 src + dst 
+		layer 4 protocol
+		layer 4 src + dst
+
+
+	connetions represented as struct ip_conntrack
+		original tuple
+		reply tuple
+		timeout
+		l4 state private data
+		app helper
+		app helper private data
+		expected connections
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for new packet
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple) -> fails
+		new ip_conntrack is allocated
+			fill in original and reply == inverted(original) tuple
+			initialize timer
+			assign app helper if applicable
+			see if we've been expected -> fails
+			call layer 4 helper 'new' function
+
+	...
+
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> fails
+		place struct ip_conntrack in hashtable			
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for packet part of existing connection
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple)
+		assosiate conntrack entry with skb->nfct
+		call l4 protocol helper 'packet' function
+			do l4 state tracking
+			update timeouts as needed [i.e. TCP TIME_WAIT,...]
+
+	...
+	
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> succeds
+		do nothing else
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Poor man's failover
+
+Poor man's failover
+	principle
+		let every node do it's own tracking rather than replicating state
+	two possible implementations
+		connect every node to shared media (i.e. real ethernet)
+			forwarding only turned on on active node
+			slave nodes use promiscuous mode to sniff packets
+		copy all traffic to slave nodes
+			active master needs to copy all traffic to other nodes
+			disadvantage: high load, sync traffic == payload traffic
+			IMHO stupid way of solving the problem 
+	advantages
+		very easy implementation
+			only addition of sniffing mode to conntrack needed
+			existing means of address takeover can be used
+		same load on active master and slave nodes
+		no additional load on active master
+	disadvantages
+		can only be used with real shared media (no switches, ...)
+		can not be used with NAT
+	remaining problem
+		no initial state sync after reboot of slave node!
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Real state replication
+
+Parts needed
+	state replication protocol
+		multicast based
+		sequence numbers for detection of packet loss
+		NACK-based retransmission
+		no security, since private ethernet segment to be used
+	event interface on active node
+		calling out to callback function at all state changes
+	exported interface to manipulate conntrack hash table
+	kernel thread for sending conntrack state protocol messages
+		registers with event interface
+		creates and accumulates state replication packets
+		sends them via in-kernel sockets api
+	kernel thread for receiving conntrack state replication messages
+		receives state replication packets via in-kernel sockets
+		uses conntrack hashtable manipulation interface
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Real state replication
+
+	Flow of events in chronological order:
+		on active node, inside the network RX softirq
+			connection tracking code is analyzing a forwarded packet
+			connection tracking gathers some new state information
+			connection tracking updates local connection tracking database
+			connection tracking sends event message to event API
+		on active node, inside the conntrack-sync kernel thread
+			conntrack sync daemon receives event through event API
+			conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy
+			conntrack sync daemon generates state replication protocol message
+			conntrack sync daemon sends state replication protocol message
+		on slave node(s), inside network RX softirq
+			connection tracking code ignores packets coming from the interface attached to the private conntrac sync network
+			state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread
+		on slave node(s), inside conntrack-sync kernel thread
+			conntrack sync daemon receives state replication message
+			conntrack sync daemon creates/updates conntrack entry
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Neccessary changes to kernel
+
+Neccessary changes to current conntrack core
+
+	event generation (callback functions) for all state changes
+
+	conntrack hashtable manipulation API
+		is needed (and already implemented) for 'ctnetlink' API
+
+	conntrack exemptions
+		needed to _not_ track conntrack state replication packets
+		is needed for other cases as well
+		currently being developed by Jozsef Kadlecsik
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Other current work
+
+	optimizing the conntrack code
+		hash function optimization
+			current hash function not good for even hash bucket count
+			other hash functions in development
+			hash function evaluation tool [cttest] avaliable
+			introduce per-system randomness to prevent hash attack
+		code optimization (locking/timers/...)
+
+	getting our work submitted into the mainstream kernel
+		turns out to be more difficult
+			e.g. newnat api now waiting for three months
+
+	discussions about multiple targets/actions per rule
+		technical implementation easy
+		however, not everybody convinced that it fits into the concept
+
+	using tc for firewalling
+		Jamal Hadi Selim uses iptables targets from within TC
+		leads to discussion of generic classification engine API in kernel
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Thanks
+	The slides and the an according paper of this presentation are available at http://www.gnumonks.org/
+
+	The netfilter homepage http://www.netfilter.org/
+
+	Thanks to
+		the BBS people, Z-Netz, FIDO, ...
+			for heavily increasing my computer usage in 1992
+		KNF
+			for bringing me in touch with the internet as early as 1994
+			for providing a playground for technical people
+			for telling me about the existance of Linux!
+		Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen
+			for implementing (one of?) the world's best TCP/IP stacks
+		Paul 'Rusty' Russell
+			for starting the netfilter/iptables project
+			for trusting me to maintain it today
+		Astaro AG
+			for sponsoring parts of my netfilter work
+
diff --git a/2002/netfilter-failover-ols2002/abstract b/2002/netfilter-failover-ols2002/abstract
new file mode 100644
index 0000000..9cd4ef3
--- /dev/null
+++ b/2002/netfilter-failover-ols2002/abstract
@@ -0,0 +1,31 @@
+How to replicate the fire - HA for netfilter based firewalls.
+
+  With traditional, stateless firewalling (such as ipfwadm, ipchains) there is
+no need for special HA support in the firewalling subsystem.  As long as all
+packet filtering rules and routing table entries are configured in exactly the
+same way, one can use any available tool for IP-Address takeover to accomplish
+the goal of failing over from one node to the other.  
+
+  With Linux 2.4.x netfilter/iptables, the Linux firewalling code moves beyond
+traditional packet filtering.  Netfilter provides a modular connection tracking
+susbsystem which can be employed for stateful firewalling.  The connection
+tracking subsystem gathers information about the state of all current network
+flows (connections).  Packet filtering decisions and NAT information is
+associated with this state information.
+
+  In a high availability scenario, this connection tracking state needs to be
+replicated from the currently active firewall node to all standby slave
+firewall nodes.  Only when all connection tracking state is replicated, the
+slave node will have all necessarry state information at the time a failover
+event occurs.
+
+  The netfilter/iptables does currently not have any functionality for
+replicating connection tracking state accross multiple nodes.  However,
+the author of this presentation, Harald Welte, has started a project for
+connection tracking state replication with netfilter/iptables.  
+
+  The presentation will cover the architectural design and implementation
+of the connection tracking failover sytem.  With respect to the date of 
+the conference, it is to be expected that the project is still a 
+work-in-progress at that time.
+
diff --git a/2002/netfilter-failover-ols2002/biography b/2002/netfilter-failover-ols2002/biography
new file mode 100644
index 0000000..27b77bd
--- /dev/null
+++ b/2002/netfilter-failover-ols2002/biography
@@ -0,0 +1,22 @@
+  <a href="http://www.gnumonks.org/users/laforge/">Harald Welte</a> is one 
+of the five <a href="http://www.netfilter.org/">netfilter/iptables</a> core
+team members, and the current Linux 2.4.x firewalling maintainer.  
+
+  His main interest in computing has always been networking.  In the few time
+left besides netfilter/iptables related work, he's writing obscure documents
+like the <a href="http://www.gnumonks.org/ftp/pub/doc/uucp-over-ssl.html"> UUCP
+over SSL HOWTO</a>.  Other kernel-related projects he has been contributing are
+user mode linux and the international (crypto) kernel patch.
+
+  In the past he has been working as an independent IT Consultant working on
+closed-source projecst for various companies ranging from banks to
+manufacturers of networking gear.  During the year 2001 he was living in
+Curitiba (Brazil), where he got sponsored for his Linux related work by 
+<a href="http://www.conectiva.com/">Conectiva Inc.</a>.
+
+  Starting with February 2002, Harald has been contracted part-time by
+<a href="http://www.astaro.com/">Astaro AG</a>, who are sponsoring him for his
+current netfilter/iptables work.
+
+  Harald is living in Erlangen, Germany.
+
diff --git a/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.mgp b/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.mgp
new file mode 100644
index 0000000..468d974
--- /dev/null
+++ b/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.mgp
@@ -0,0 +1,294 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+How to replicate the fire
+HA for netfilter-based firewalls
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@gnumonks.org>
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Contents
+
+
+	Introduction
+	Connection Tracking Subsystem
+	Packet selection based on IP Tables
+	The Connection Tracking Subsystem
+	The NAT Subsystem
+	Poor man's failover
+	Real state replication
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+HA for netfillter/iptables
+Introduction
+
+What is special about firewall failover?
+
+	Nothing, in case of the stateless packet filter
+		Common IP takeover solutions can be used
+			VRRP
+			Hartbeat
+	
+	Distribution of packet filtering ruleset no problem
+		can be done manually
+		or implemented with simple userspace process
+
+	Problems arise with stateful packet filters
+		Connection state only on active node
+		NAT mappings only on active node
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Connection tracking...
+
+	implemented seperately from NAT 
+	enables stateful filtering 
+	implementation
+		hooks into NF_IP_PRE_ROUTING to track packets
+		hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules
+		protocol modules (currently TCP/UDP/ICMP)
+		application helpers currently (FTP,IRC,H.323,talk,SNMP)
+	divides packets in the following four categories
+		NEW - would establish new connection
+		ESTABLISHED - part of already established connection
+		RELATED - is related to established connection
+		INVALID - (multicast, errors...)
+	does _NOT_ filter packets itself
+	can be utilized by iptables using the 'state' match 
+	is used by NAT Subsystem
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Common structures
+	struct ip_conntrack_tuple, representing unidirectional flow
+		layer 3 src + dst 
+		layer 4 protocol
+		layer 4 src + dst
+
+
+	connetions represented as struct ip_conntrack
+		original tuple
+		reply tuple
+		timeout
+		l4 state private data
+		app helper
+		app helper private data
+		expected connections
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for new packet
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple) -> fails
+		new ip_conntrack is allocated
+			fill in original and reply == inverted(original) tuple
+			initialize timer
+			assign app helper if applicable
+			see if we've been expected -> fails
+			call layer 4 helper 'new' function
+
+	...
+
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> fails
+		place struct ip_conntrack in hashtable			
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for packet part of existing connection
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple)
+		assosiate conntrack entry with skb->nfct
+		call l4 protocol helper 'packet' function
+			do l4 state tracking
+			update timeouts as needed [i.e. TCP TIME_WAIT,...]
+
+	...
+	
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> succeds
+		do nothing else
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Network Address Translation
+
+Overview
+		Previous Linux Kernels only implemented one special case of NAT: Masquerading
+		Linux 2.4.x can do any kind of NAT.
+		NAT subsystem implemented on top of netfilter, iptables and conntrack
+		NAT subsystem registers with all five netfilter hooks
+		'nat' Table registers chains PREROUTING, POSTROUTING and OUTPUT
+		Following targets available within 'nat' Table
+			SNAT changes the packet's source whille passing NF_IP_POST_ROUTING
+			DNAT changes the packet's destination while passing NF_IP_PRE_ROUTING
+			MASQUERADE is a special case of SNAT
+			REDIRECT is a special case of DNAT
+		NAT bindings determined only for NEW packet and saved in ip_conntrack
+		Further packets within connection NATed according NAT bindings
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Poor man's failover
+
+Poor man's failover
+	principle
+		let every node do it's own tracking rather than replicating state
+	two possible implementations
+		connect every node to shared media (i.e. real ethernet)
+			forwarding only turned on on active node
+			slave nodes use promiscuous mode to sniff packets
+		copy all traffic to slave nodes
+			active master needs to copy all traffic to other nodes
+			disadvantage: high load, sync traffic == payload traffic
+			IMHO stupid way of solving the problem 
+	advantages
+		very easy implementation
+			only addition of sniffing mode to conntrack needed
+			existing means of address takeover can be used
+		same load on active master and slave nodes
+		no additional load on active master
+	disadvantages
+		can only be used with real shared media (no switches, ...)
+		can not be used with NAT
+	remaining problem
+		no initial state sync after reboot of slave node!
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Real state replication
+
+Parts needed
+	state replication protocol
+		multicast based
+		sequence numbers for detection of packet loss
+		NACK-based retransmission
+		no security, since private ethernet segment to be used
+	event interface on active node
+		calling out to callback function at all state changes
+	exported interface to manipulate conntrack hash table
+	kernel thread for sending conntrack state protocol messages
+		registers with event interface
+		creates and accumulates state replication packets
+		sends them via in-kernel sockets api
+	kernel thread for receiving conntrack state replication messages
+		receives state replication packets via in-kernel sockets
+		uses conntrack hashtable manipulation interface
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Real state replication
+
+	Flow of events in chronological order:
+		on active node, inside the network RX softirq
+			connection tracking code is analyzing a forwarded packet
+			connection tracking gathers some new state information
+			connection tracking updates local connection tracking database
+			connection tracking sends event message to event API
+		on active node, inside the conntrack-sync kernel thread
+			conntrack sync daemon receives event through event API
+			conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy
+			conntrack sync daemon generates state replication protocol message
+			conntrack sync daemon sends state replication protocol message
+		on slave node(s), inside network RX softirq
+			connection tracking code ignores packets coming from the interface attached to the private conntrac sync network
+			state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread
+		on slave node(s), inside conntrack-sync kernel thread
+			conntrack sync daemon receives state replication message
+			conntrack sync daemon creates/updates conntrack entry
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Neccessary changes to kernel
+
+Neccessary changes to current conntrack core
+
+	event generation (callback functions) for all state changes
+
+	conntrack hashtable manipulation API
+		is needed (and already implemented) for 'ctnetlink' API
+
+	conntrack exemptions
+		needed to _not_ track conntrack state replication packets
+		is needed for other cases as well
+		currently being developed by Jozsef Kadlecsik
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Thanks
+
+	Thanks to
+		the BBS people, Z-Netz, FIDO, ...
+			for heavily increasing my computer usage in 1992
+
+		KNF
+			for bringing me in touch with the internet as early as 1994
+			for providing a playground for technical people
+			for telling me about the existance of Linux!
+
+		Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen
+			for implementing (one of?) the world's best TCP/IP stacks
+
+		Paul 'Rusty' Russell
+			for starting the netfilter/iptables project
+			for trusting me to maintain it today
+
+		Astaro AG
+			for sponsoring parts of my netfilter work
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Availability of slides / Links
+
+The slides and the an according paper of this presentation are available at 
+	http://www.gnumonks.org/
+
+The netfilter homepage
+	http://www.netfilter.org/
+
diff --git a/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.tex b/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.tex
new file mode 100644
index 0000000..bf8d142
--- /dev/null
+++ b/2002/netfilter-failover-ols2002/netfilter-failover-ols2002.tex
@@ -0,0 +1,504 @@
+\documentclass[twocolumn]{article}
+\usepackage{ols}
+\begin{document}
+
+\date{}
+
+\title{\Large \bf How to replicate the fire - HA for netfilter based firewalls}
+
+\author{
+Harald Welte\\
+{\em Netfilter Core Team + Astaro AG}\\
+{\normalsize laforge@gnumonks.org/laforge@astaro.com, http://www.gnumonks.org/}
+}
+
+\maketitle
+
+\thispagestyle{empty}
+
+\subsection*{Abstract}
+  With traditional, stateless firewalling (such as ipfwadm, ipchains) there is
+no need for special HA support in the firewalling subsystem.  As long as all
+packet filtering rules and routing table entries are configured in exactly the
+same way, one can use any available tool for IP-Address takeover to accomplish
+the goal of failing over from one node to the other.  
+
+  With Linux 2.4.x netfilter/iptables, the Linux firewalling code moves beyond
+traditional packet filtering.  Netfilter provides a modular connection tracking
+susbsystem which can be employed for stateful firewalling.  The connection
+tracking subsystem gathers information about the state of all current network
+flows (connections).  Packet filtering decisions and NAT information is
+associated with this state information.
+
+  In a high availability scenario, this connection tracking state needs to be
+replicated from the currently active firewall node to all standby slave
+firewall nodes.  Only when all connection tracking state is replicated, the
+slave node will have all necessarry state information at the time a failover
+event occurs.
+
+  The netfilter/iptables does currently not have any functionality for
+replicating connection tracking state accross multiple nodes.  However,
+the author of this presentation, Harald Welte, has started a project for
+connection tracking state replication with netfilter/iptables.  
+
+  The presentation will cover the architectural design and implementation
+of the connection tracking failover sytem.  With respect to the date of 
+the conference, it is to be expected that the project is still a 
+work-in-progress at that time.
+
+\section{Failover of stateless firewalls}
+
+There are no special precautions when installing a highly available
+stateless packet filter.  Since there is no state kept, all information
+needed for filtering is the ruleset and the individual, seperate packets.
+
+Building a set of highly available stateless packet filters can thus be
+achieved by using any traditional means of IP-address takeover, such 
+as Hartbeat or VRRPd.
+
+The only remaining issue is to make sure the firewalling ruleset is
+exactly the same on both machines.  This should be ensured by the firewall
+administrator every time he updates the ruleset.  
+
+If this is not applicable, because a very dynamic ruleset is employed, one
+can build a very easy solution using iptables-supplied tools iptables-save
+and iptables-restore.  The output of iptables-save can be piped over ssh
+to iptables-restore on a different host.
+
+Limitations
+\begin{itemize}
+\item
+no state tracking
+\item
+not possible in combination with NAT
+\item
+no counter consistency of per-rule packet/byte counters
+\end{itemize}
+
+\section{Failover of stateful firewalls}
+
+Modern firewalls implement state tracking (aka connection tracking) in order
+to keep some state about the currently active sessions.  The amount of
+per-connection state kept at the firewall depends on the particular
+implementation.
+
+As soon as {\bf any} state is kept at the packet filter, this state information
+needs to be replicated to the slave/backup nodes within the failover setup.
+
+In Linux 2.4.x, all relevant state is kept within the {\it connection tracking
+subsystem}.  In order to understand how this state could possibly be
+replicated, we need to understand the architecture of this conntrack subsystem.
+
+\subsection{Architecture of the Linux Connection Tracking Subsystem}
+
+Connection tracking within Linux is implemented as a netfilter module, called
+ip\_conntrack.o.  
+
+Before describing the connection tracking subsystem, we need to describe a
+couple of definitions and primitives used throughout the conntrack code.
+
+A connection is represented within the conntrack subsystem using {\it struct
+ip\_conntrack}, also called {\it connection tracking entry}.
+
+Connection tracking is utilizing {\it conntrack tuples}, which are tuples
+consisting out of (srcip, srcport, dstip, dstport, l4prot).  A connection is
+uniquely identified by two tuples:  The tuple in the original direction
+(IP\_CT\_DIR\_ORIGINAL) and the tuple for the reply direction
+(IP\_CT\_DIR\_REPLY).
+
+Connection tracking itself does not drop packets\footnote{well, in some rare
+cases in combination with NAT it needs to drop. But don't tell anyone, this is
+secret.} or impose any policy.  It just associates every packet with a
+connection tracking entry, which in turn has a particular state.  All other
+kernel code can use this state information\footnote{state information is
+internally represented via the {\it struct sk\_buff.nfct} structure member of a
+packet.}.
+
+\subsubsection{Integration of conntrack with netfilter} 
+
+If the ip\_conntrack.o module is registered with netfilter, it attaches to the
+NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING, NF\_IP\_LOCAL\_IN and
+NF\_IP\_LOCAL\_OUT hooks.
+
+Because forwarded packets are the most common case on firewalls, I will only
+describe how connection tracking works for forwarded packets.  The two relevant
+hooks for forwarded packets are NF\_IP\_PRE\_ROUTING and NF\_IP\_POST\_ROUTING.
+
+Every time a packet arrives at the NF\_IP\_PRE\_ROUTING hook, connection
+tracking creates a conntrack tuple from the packet.  It then compares this
+tuple to the original and reply tuples of all already-seen connections
+\footnote{Of course this is not implemented as a linear search over all existing connections.} to find out if this just-arrived packet belongs to any existing
+connection.  If there is no match, a new conntrack table entry (struct
+ip\_conntrack) is created.
+
+Let's assume the case where we have already existing connections but are
+starting from scratch.
+
+The first packet comes in, we derive the tuple from the packet headers, look up
+the conntrack hash table, don't find any matching entry.  As a result, we
+create a new struct ip\_conntrack.  This struct ip\_conntrack is filled with
+all necessarry data, like the original and reply tuple of the connection.
+How do we know the reply tuple?  By inverting the source and destination
+parts of the original tuple.\footnote{So why do we need two tuples, if they can
+be derived from each other?  Wait until we discuss NAT.}
+Please note that this new struct ip\_conntrack is {\bf not} yet placed
+into the conntrack hash table.
+
+The packet is now passed on to other callback functions which have registered
+with a lower priority at NF\_IP\_PRE\_ROUTING.  It then continues traversal of
+the network stack as usual, including all respective netfilter hooks.
+
+If the packet survives (i.e. is not dropped by the routing code, network stack,
+firewall ruleset, ...), it re-appears at NF\_IP\_POST\_ROUTING.  In this case,
+we can now safely assume that this packet will be sent off on the outgoing
+interface, and thus put the connection tracking entry which we created at
+NF\_IP\_PRE\_ROUTING into the conntrack hash table.  This process is called
+{\it confirming the conntrack}.
+
+The connection tracking code itself is not monolithic, but consists out of a
+couple of seperate modules\footnote{They don't actually have to be seperate
+kernel modules; e.g. TCP, UDP and ICMP tracking modules are all part of
+the linux kernel module ip\_conntrack.o}.  Besides the conntrack core, there
+are two important kind of modules: Protocol helpers and application helpers.
+
+Protocol helpers implement the layer-4-protocol specific parts.  They currently
+exist for TCP, UDP and ICMP (an experimental helper for GRE exists).
+
+\subsubsection{TCP connection tracking}
+
+As TCP is a connection oriented protocol, it is not very difficult to imagine
+how conntection tracking for this protocol could work.  There are well-defined
+state transitions possible, and conntrack can decide which state transitions
+are valid within the TCP specification.  In reality it's not all that easy,
+since we cannot assume that all packets that pass the packet filter actually
+arrive at the receiving end, ...
+
+It is noteworthy that the standard connection tracking code does {\bf not}
+do TCP sequence number and window tracking.  A well-maintained patch to add
+this feature exists almost as long as connection tracking itself.  It will
+be integrated with the 2.5.x kernel.  The problem with window tracking is
+it's bad interaction with connection pickup.  The TCP conntrack code is able to
+pick up already existing connections, e.g. in case your firewall was rebooted.
+However, connection pickup is conflicting with TCP window tracking:  The TCP
+window scaling option is only transferred at connection setup time, and we
+don't know about it in case of pickup...
+
+\subsubsection{ICMP tracking}
+
+ICMP is not really a connection oriented protocol.  So how is it possible to
+do connection tracking for ICMP?
+
+The ICMP protocol can be split in two groups of messages
+
+\begin{itemize}
+\item
+ICMP error messages, which sort-of belong to a different connection
+ICMP error messages are associated {\it RELATED} to a different connection.
+(ICMP\_DEST\_UNREACH, ICMP\_SOURCE\_QUENCH, ICMP\_TIME\_EXCEEDED,
+ICMP\_PARAMETERPROB, ICMP\_REDIRECT). 
+\item
+ICMP queries, which have a request->reply character.  So what the conntrack
+code does, is let the request have a state of {\it NEW}, and the reply 
+{\it ESTABLISHED}.  The reply closes the connection immediately.
+(ICMP\_ECHO, ICMP\_TIMESTAMP, ICMP\_INFO\_REQUEST, ICMP\_ADDRESS)
+\end{itemize}
+
+\subsubsection{UDP connection tracking}
+
+UDP is designed as a connectionless datagram protocol. But most common
+protocols using UDP as layer 4 protocol have bi-directional UDP communication.
+Imagine a DNS query, where the client sends an UDP frame to port 53 of the
+nameserver, and the nameserver sends back a DNS reply packet from it's  UDP
+port 53 to the client.
+
+Netfilter trats this as a connection. The first packet (the DNS request) is
+assigned a state of {\it NEW}, because the packet is expected to create a new
+'connection'. The dns servers' reply packet is marked as {\it ESTABLISHED}.
+
+\subsubsection{conntrack application helpers}
+
+More complex application protocols involving multiple connections need special
+support by a so-called ``conntrack application helper module''.  Modules in
+the stock kernel come for FTP and IRC(DCC).  Netfilter CVS currently contains
+patches for PPTP, H.323, Eggdrop botnet, tftp ald talk.  We're still lacking
+a lot of protocols (e.g. SIP, SMB/CIFS) - but they are unlikely to appear
+until somebody really needs them and either develops them on his own or
+funds development.
+
+\subsubsection{Integration of connection tracking with iptables}
+
+As stated earlier, conntrack doesn't impose any policy on packets.  It just
+determines the relation of a packet to already existing connections.  To base
+packet filtering decision on this sate information, the iptables {\it state}
+match can be used.  Every packet is within one of the following categories:
+
+\begin{itemize}
+\item
+{\bf NEW}: packet would create a new connection, if it survives
+\item
+{\bf ESTABLISHED}: packet is part of an already established connection 
+(either direction)
+\item
+{\bf RELATED}: packet is in some way related to an already established connection, e.g. ICMP errors or FTP data sessions
+\item
+{\bf INVALID}: conntrack is unable to derive conntrack information from this packet.  Please note that all multicast or broadcast packets fall in this category.
+\end{itemize}
+
+
+\subsection{Poor man's conntrack failover}
+
+When thinking about failover of stateful firewalls, one usually thinks about
+replication of state.  This presumes that the state is gathered at one
+firewalling node (the currently active node), and replicated to several other
+passive standby nodes.  There is, howeve, a very different approach to
+replication:  concurrent state tracking on all firewalling nodes. 
+
+The basic assumption of this approach is: In a setup where all firewalling
+nodes receive exactly the same traffic, all nodes will deduct the same state
+information.
+
+The implementability of this approach is totally dependent on fulfillment of
+this assumption.   
+
+\begin{itemize}
+\item
+{\it All packets need to be seen by all nodes}.  This is not always true, but
+can be achieved by using shared media like traditional ethernet (no switches!!) 
+and promiscuous mode on all ethernet interfaces.
+\item
+{\it All nodes need to be able to process all packets}.  This cannot be
+universally guaranteed.  Even if the hardware (CPU, RAM, Chipset, NIC's) and
+software (Linux kernel) are exactly the same, they might behave different,
+especially under high load.  To avoid those effects, the hardware should be
+able to deal with way more traffic than seen during operation.  Also, there
+should be no userspace processes (like proxes, etc.) running on the firewalling
+nodes at all.  WARNING: Nobody guarantees this behaviour.  However, the poor
+man is usually not interested in scientific proof but in usability in his
+particular practical setup.
+\end{itemize}
+
+However, even if those conditions are fulfilled, ther are remaining issues:
+\begin{itemize}
+\item
+{\it No resynchronization after reboot}.  If a node is rebooted (because of
+a hardware fault, software bug, software update, ..) it will loose all state
+information until the event of the reboot.  This means, the state information
+of this node after reboot will not contain any old state, gathered before the
+reboot.  The effect depend on the traffic.  Generally, it is only assured that
+state information about all connections initiated after the reboot will be
+present.  If there are short-lived connections (like http), the state
+information on the just rebooted node will approximate the state information of
+an older node.  Only after all sessions active at the time of reboot have
+terminated, state information is guaranteed to be resynchronized.
+\item
+{\it Only possible with shared medium}.  The practical implication is that no
+switched ethernet (and thus no full duplex) can be used.
+\end{itemize}
+
+The major advantage of the poor man's approach is implementation simplicity.
+No state transfer mechanism needs to be developed.  Only very little changes
+to the existing conntrack code would be needed in order to be able to
+do tracking based on packets received from promiscuous interfaces.  The active
+node would have packet forwarding turned on, the passive nodes off.
+
+I'm not proposing this as a real solution to the failover problem.  It's
+hackish, buggy and likely to break very easily.  But considering it can be
+implemented in very little programming time, it could be an option for very
+small installations with low reliability criteria.
+
+\subsection{Conntrack state replication}
+
+The preferred solution to the failover problem is, without any doubt, 
+replication of the connection tracking state.
+
+The proposed conntrack state replication soltution consists out of several
+parts:
+\begin{itemize}
+\item
+A connection tracking state replication protocol
+\item
+An event interface generating event messages as soon as state information
+changes on the active node
+\item
+An interface for explicit generation of connection tracking table entries on
+the standby slaves
+\item
+Some code (preferrably a kernel thread) running on the active node, receiving
+state updates by the event interface and generating conntrack state replication
+protocol messages
+\item
+Some code (preferrably a kernel thread) running on the slave node(s), receiving
+conntrack state replication protocol messages and updating the local conntrack
+table accordingly
+\end{itemize}
+
+Flow of events in chronological order:
+\begin{itemize}
+\item
+{\it on active node, inside the network RX softirq} 
+\begin{itemize}
+\item
+	connection tracking code is analyzing a forwarded packet
+\item
+	connection tracking gathers some new state information
+\item
+	connection tracking updates local connection tracking database
+\item
+	connection tracking sends event message to event API
+\end{itemize}
+\item
+{\it on active node, inside the conntrack-sync kernel thread}
+	\begin{itemize}
+	\item
+	conntrack sync daemon receives event through event API
+	\item
+	conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy
+	\item
+	conntrack sync daemon generates state replication protocol message
+	\item
+	conntrack sync daemon sends state replication protocol message
+(private network between firewall nodes)
+	\end{itemize}
+\item
+{\it on slave node(s), inside network RX softirq}
+	\begin{itemize}
+	\item
+	connection tracking code ignores packets coming from the interface attached to the private conntrac sync network
+	\item
+	state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread
+	\end{itemize}
+\item
+{\it on slave node(s), inside conntrack-sync kernel thread}
+	\begin{itemize}
+	\item
+	conntrack sync daemon receives state replication message
+	\item
+	conntrack sync daemon creates/updates conntrack entry
+	\end{itemize}
+\end{itemize}
+
+
+\subsubsection{Connection tracking state replication protocol}
+
+
+  In order to be able to replicate the state between two or more firewalls, a
+state replication protocol is needed.  This protocol is used over a private
+network segment shared by all nodes for state replication.  It is designed to
+work over IP unicast and IP multicast transport.  IP unicast will be used for
+direct point-to-point communication between one active firewall and one
+standby firewall.  IP multicast will be used when the state needs to be
+replicated to more than one standby firewall.
+
+
+  The principle design criteria of this protocol are:
+\begin{itemize}
+\item
+	{\bf reliable against data loss}, as the underlying UDP layer does only
+	provide checksumming against data corruption, but doesn't employ any
+	means against data loss
+\item
+	{\bf lightweight}, since generating the state update messages is
+	already a very expensive process for the sender, eating additional CPU,
+	memory and IO bandwith.
+\item
+	{\bf easy to parse}, to minimize overhead at the receiver(s)
+\end{itemize}
+
+The protocol does not employ any security mechanism like encryption,
+authentication or reliability against spoofing attacks.  It is
+assumed that the private conntrack sync network is a secure communications
+channel, not accessible to any malicious 3rd party.
+
+To achieve the reliability against data loss, an easy sequence numbering
+scheme is used.  All protocol messages are prefixed by a seuqence number,
+determined by the sender.  If the slave detects packet loss by discontinuous
+sequence numbers, it can request the retransmission of the missing packets
+by stating the missing sequence number(s).  Since there is no acknowledgement
+for sucessfully received packets, the sender has to keep a reasonably-sized
+backlog of recently-sent packets in order to be able to fulfill retransmission
+requests.
+
+The different state replication protocol messages types are:
+\begin{itemize}
+\item
+{\bf NF\_CTSRP\_NEW}: New conntrack entry has been created (and
+confirmed\footnote{See the above description of the conntrack code for what is
+meant by {\it confirming} a conntrack entry})
+\item
+{\bf NF\_CTSRP\_UPDATE}: State information of existing conntrack entry has
+changed
+\item
+{\bf NF\_CTSRP\_EXPIRE}: Existing conntrack entry has been expired
+\end{itemize}
+
+To uniquely identify (and later reference) a conntrack entry, a
+{\it conntrack\_id} is assigned to every conntrack entry transferred
+using a NF\_CTSRP\_NEW message.  This conntrack\_id must be saved at the
+receiver(s) together with the conntrack entry, since it is used by the sender
+for subsequent NF\_CTSRP\_UPDATE and NF\_CTSRP\_EXPIRE messages.  
+
+The protocol itself does not care about the source of this conntrack\_id,
+but since the current netfilter connection tracking implementation does never
+change the addres of a conntrack  entry, the memory address of the entry can be
+used, since it comes for free.
+
+
+\subsubsection{Connection tracking state syncronization sender}
+
+Maximum care needs to be taken for the implementation of the ctsyncd sender.
+
+The normal workload of the active firewall node is likely to be already very
+high, so generating and sending the conntrack state replication messages needs
+to be highly efficient.
+
+\begin{itemize}
+\item
+	{\bf NF\_CTSRP\_NEW} will be generated at the NF\_IP\_POST\_ROUTING
+	hook, at the time ip\_conntrack\_confirm() is called.  Delaying
+	this message until conntrack confirmation happens saves us from
+	replicating otherwise unneeded state information.
+\item
+	{\bf NF\_CTSRP\_UPDATE} need to be created automagically by the 
+	conntrack core.  It is not possible to have any failover-specific
+	code within conntrack protocol and/or application helpers.
+	The easiest way involving the least changes to the conntrack core
+	code is to copy parts of the conntrack entry before calling any
+	helper functions, and then use memcmp() to find out if the helper
+	has changed any information.
+\item
+	{\bf NF\_CTSRP\_EXPIRE} can be added very easily to the existing
+	conntrack destroy function.
+\end{itemize}
+
+
+\subsubsection{Connection tracking state syncronization receiver}
+
+Impmentation of the receiver is very straightforward.
+
+Apart from dealing with lost CTSRP packets, it just needs to call the
+respective conntrack add/modify/delete functions offered by the core.
+
+
+\subsubsection{Necessary changes within netfilter conntrack core}
+
+To be able to implement the described conntrack state replication mechanism,
+the following changes to the conntrack core are needed:
+\begin{itemize}
+\item
+	Ability to exclude certain packets from being tracked.  This is a
+	long-wanted feature on the TODO list of the netfilter project and will
+	be implemented by having a ``prestate'' table in combination with a
+	``NOTRACK'' target.
+\item
+	Ability to register callback functions to be called every time a new
+	conntrack entry is created or an existing entry modified.
+\item
+	Export an API to add externally add, modify and remove conntrack
+	entries.  Since the needed ip\_conntrack\_lock is exported,
+	implementation could even reside outside the conntrack core code.
+\end{itemize}
+
+Since the number of changes is very low, it is very likely that the
+modifications will go into the mainstream kernel without any big hazzle.
+
+\end{document}
diff --git a/2002/netfilter-failover-ols2002/ols.sty b/2002/netfilter-failover-ols2002/ols.sty
new file mode 100644
index 0000000..5e5fe49
--- /dev/null
+++ b/2002/netfilter-failover-ols2002/ols.sty
@@ -0,0 +1,56 @@
+
+% TEMPLATE for Usenix papers, specifically to meet requirements of
+%  TCL97 committee.
+% originally a template for producing IEEE-format articles using LaTeX.
+%   written by Matthew Ward, CS Department, Worcester Polytechnic Institute.
+% adapted by David Beazley for his excellent SWIG paper in Proceedings,
+%   Tcl 96
+% turned into a smartass generic template by De Clarke, with thanks to
+%   both the above pioneers
+% use at your own risk.  Complaints to /dev/null.
+% make it two column with no page numbering, default is 10 point
+
+% adapted for Ottawa Linux Symposium
+
+% include following in document.
+%\documentclass[twocolumn]{article}
+%\usepackage{usits,epsfig}
+\pagestyle{empty}
+
+%set dimensions of columns, gap between columns, and space between paragraphs
+%\setlength{\textheight}{8.75in}
+\setlength{\textheight}{9.0in}
+\setlength{\columnsep}{0.25in}
+\setlength{\textwidth}{6.45in}
+\setlength{\footskip}{0.0in}
+\setlength{\topmargin}{0.0in}
+\setlength{\headheight}{0.0in}
+\setlength{\headsep}{0.0in}
+\setlength{\oddsidemargin}{0in}
+%\setlength{\oddsidemargin}{-.065in}
+%\setlength{\oddsidemargin}{-.17in}
+\setlength{\parindent}{0pc}
+\setlength{\parskip}{\baselineskip}
+
+% started out with art10.sty and modified params to conform to IEEE format
+% further mods to conform to Usenix standard
+
+\makeatletter
+%as Latex considers descenders in its calculation of interline spacing,
+%to get 12 point spacing for normalsize text, must set it to 10 points
+\def\@normalsize{\@setsize\normalsize{12pt}\xpt\@xpt
+\abovedisplayskip 10pt plus2pt minus5pt\belowdisplayskip \abovedisplayskip
+\abovedisplayshortskip \z@ plus3pt\belowdisplayshortskip 6pt plus3pt
+minus3pt\let\@listi\@listI} 
+
+%need a 12 pt font size for subsection and abstract headings
+\def\subsize{\@setsize\subsize{12pt}\xipt\@xipt}
+
+%make section titles bold and 12 point, 2 blank lines before, 1 after
+\def\section{\@startsection {section}{1}{\z@}{24pt plus 2pt minus 2pt}
+{12pt plus 2pt minus 2pt}{\large\bf}}
+
+%make subsection titles bold and 11 point, 1 blank line before, 1 after
+\def\subsection{\@startsection {subsection}{2}{\z@}{12pt plus 2pt minus 2pt}
+{12pt plus 2pt minus 2pt}{\subsize\bf}}
+\makeatother
diff --git a/2002/netfilter-future-lk2002/abstract b/2002/netfilter-future-lk2002/abstract
new file mode 100644
index 0000000..177d436
--- /dev/null
+++ b/2002/netfilter-future-lk2002/abstract
@@ -0,0 +1,33 @@
+Linux packet filtering in the 2.6.x kernel series
+
+The Linux 2.4.x provided a complete rewrite of the firewalling subsystem,
+called netfilter/iptables.  It was a major improvement about the previous
+ipchains subsystem.  The major advantages are it's modularity and flexibility.
+
+However, as wity any project, as soon as you are sort-of finished, you become
+aware of potential improvements and extensions.
+
+The firewalling subsystem within the Linux kernel will undergo some fundamental design changes during the 2.5.x development kernel series.
+
+Some of the changes from 2.4.x are:
+
+- Have an independent pkt_tables subsystem, as a layer3 independent replacement
+  for iptables, ip6tables and arptables.  This will allow adding support for
+  other layer 3 protocols very easily
+- Move all kernel/userspace communication to netlink sockets.  There will be
+  a generic nfnetlink layer, with pkttnetlink (for managing pkt_tables) and
+  ctnetlink (for manipulating the connection tracking database from userspace).
+- Change the internal data structure of an ip_table to a linked list of chains,
+  which in turn are a linked lists out of rules, which are linked lists out of
+  matches + targets.  This way it is _way_ more performant in the case of 
+  dynamic firewalling rulesets.
+- Provide a generic high-level API to userspace applications for manipulation
+  of packet filtering rules.  This will enable generic GUI's, which need no
+  changes in case new matches or targets are added.
+
+Optionally, the netfilter core team is planning to have support for connection
+tracking state replication - something necessarry for failover of stateful
+firewalls.
+
+The talk assumes prior knowledge about the netfilter/iptables architecture.
+
diff --git a/2002/netfilter-future-lk2002/netfilter-future-lk2002.mgp b/2002/netfilter-future-lk2002/netfilter-future-lk2002.mgp
new file mode 100644
index 0000000..96e12f5
--- /dev/null
+++ b/2002/netfilter-future-lk2002/netfilter-future-lk2002.mgp
@@ -0,0 +1,374 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+The future of Linux packet filtering
+targeted for kernel 2.6
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@gnumonks.org>
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Contents
+
+
+	Problems with current 2.4.x netfilter/iptables
+		Solution to code replication
+		Solution for dynamic rulesets
+		Solution for API to GUI's and other management programs
+
+	HA for stateful firewalling
+		What's special about firewalling HA
+		Poor man's failover
+		Real state replication
+
+	Other current work
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Problems with 2.4.x netfilter/iptables
+
+	code replication between iptables/ip6tables/arptables
+		iptables was never meant for other protocols, but people did copy+paste 'ports'
+		replication of
+			core kernel code
+			layer 3 independent matches (mac, interface, ...)
+			userspace library (libiptc)
+			userspace tool (iptables)
+			userspace plugins (libipt_xxx.so)
+
+	doesn't suit the needs for dynamically changing rulesets
+		dynamic rulesets becomming more common due (service selection, IDS)
+		a whole table is created in userspace and sent as blob to kernel
+		for every ruleset the table needs to be copied to userspace and back
+		inside kernel consistency checks on whole table, loop detection
+
+	too extensible for writing any forward-compatible GUI
+		new extensions showing up all the time
+		a frontend would need to know about the options and use of a new extension
+		thus frontends are always incomplete and out-of-date
+		no high-level API other than piping to iptables-restore
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Reducing code replication
+
+	code replication is a real problem: unclean, bugfixes missed
+	we need layer 3 independent layer for
+		submitting rules to the kernel
+		traversing packet-rulesets supporting match/target modules
+		registering matches/targets
+			layer 3 specific (like matching ipv4 address)
+			layer 3 independent (like matching MAC address)
+
+	solution
+		pkt_tables inside kernel
+			pkt_tables_ipv4 registers layer 3 handler with pkt_tables
+			pkt_tables_ipv6 registers layer 3 handler with pkt_tables
+			everybody registering a pkt_table (like iptable_filter) needs to specify the l3 protocol
+		libraries in userspace (see later)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Supporting dynamic rulesets
+
+	atomic table-replacement turned out to be bad idea
+	need new interface for sending individual rules to kernel
+	policy routing has the same problem and good solution: rtnetlink
+	solution: nfnetlink
+		multicast-netlink based packet-orinented socket between kernel and userspace
+		has extra benefit that other userspace processes get notified of rule changes [just like routing daemons]
+		nfnetlink will be low-layer below all kernel/userspace communication
+			pkttnetlink [aka iptnetlink]
+			ctnetlink
+			ulog
+			ip_queue
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Communication with other programs
+
+whole set of libraries
+	libnfnetlink for low-layer communication
+	libpkttnetlink for rule modifications
+		will handle all plugins [which are currently part of iptables]
+		query functions about avaliable matches/targets
+		query functions about parameters
+		query functions for help messages about specific match/parameter of a match
+		generic structure from which rules can be built
+		conversion functions to parse generic structure into in-kernel structure
+		conversion functiosn to perse kernel structure into generic structure
+		functions to convert generic structure in plain text
+	libipq will stay API-compatible to current version
+	libipulog will stay API-compatible to current version
+	libiptc will go away [compatibility layer extremely difficult]
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+HA for netfillter/iptables
+Introduction
+
+What is special about firewall failover?
+
+	Nothing, in case of the stateless packet filter
+		Common IP takeover solutions can be used
+			VRRP
+			Hartbeat
+
+	Distribution of packet filtering ruleset no problem
+		can be done manually
+		or implemented with simple userspace process
+
+	Problems arise with stateful packet filters
+		Connection state only on active node
+		NAT mappings only on active node
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Connection tracking...
+
+	implemented seperately from NAT 
+	enables stateful filtering 
+	implementation
+		hooks into NF_IP_PRE_ROUTING to track packets
+		hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules
+		protocol modules (currently TCP/UDP/ICMP)
+		application helpers currently (FTP,IRC,H.323,talk,SNMP)
+	divides packets in the following four categories
+		NEW - would establish new connection
+		ESTABLISHED - part of already established connection
+		RELATED - is related to established connection
+		INVALID - (multicast, errors...)
+	does _NOT_ filter packets itself
+	can be utilized by iptables using the 'state' match 
+	is used by NAT Subsystem
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Common structures
+	struct ip_conntrack_tuple, representing unidirectional flow
+		layer 3 src + dst 
+		layer 4 protocol
+		layer 4 src + dst
+
+
+	connetions represented as struct ip_conntrack
+		original tuple
+		reply tuple
+		timeout
+		l4 state private data
+		app helper
+		app helper private data
+		expected connections
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for new packet
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple) -> fails
+		new ip_conntrack is allocated
+			fill in original and reply == inverted(original) tuple
+			initialize timer
+			assign app helper if applicable
+			see if we've been expected -> fails
+			call layer 4 helper 'new' function
+
+	...
+
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> fails
+		place struct ip_conntrack in hashtable			
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for packet part of existing connection
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple)
+		assosiate conntrack entry with skb->nfct
+		call l4 protocol helper 'packet' function
+			do l4 state tracking
+			update timeouts as needed [i.e. TCP TIME_WAIT,...]
+
+	...
+	
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> succeds
+		do nothing else
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Poor man's failover
+
+Poor man's failover
+	principle
+		let every node do it's own tracking rather than replicating state
+	two possible implementations
+		connect every node to shared media (i.e. real ethernet)
+			forwarding only turned on on active node
+			slave nodes use promiscuous mode to sniff packets
+		copy all traffic to slave nodes
+			active master needs to copy all traffic to other nodes
+			disadvantage: high load, sync traffic == payload traffic
+			IMHO stupid way of solving the problem 
+	advantages
+		very easy implementation
+			only addition of sniffing mode to conntrack needed
+			existing means of address takeover can be used
+		same load on active master and slave nodes
+		no additional load on active master
+	disadvantages
+		can only be used with real shared media (no switches, ...)
+		can not be used with NAT
+	remaining problem
+		no initial state sync after reboot of slave node!
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Real state replication
+
+Parts needed
+	state replication protocol
+		multicast based
+		sequence numbers for detection of packet loss
+		NACK-based retransmission
+		no security, since private ethernet segment to be used
+	event interface on active node
+		calling out to callback function at all state changes
+	exported interface to manipulate conntrack hash table
+	kernel thread for sending conntrack state protocol messages
+		registers with event interface
+		creates and accumulates state replication packets
+		sends them via in-kernel sockets api
+	kernel thread for receiving conntrack state replication messages
+		receives state replication packets via in-kernel sockets
+		uses conntrack hashtable manipulation interface
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Real state replication
+
+	Flow of events in chronological order:
+		on active node, inside the network RX softirq
+			connection tracking code is analyzing a forwarded packet
+			connection tracking gathers some new state information
+			connection tracking updates local connection tracking database
+			connection tracking sends event message to event API
+		on active node, inside the conntrack-sync kernel thread
+			conntrack sync daemon receives event through event API
+			conntrack sync daemon aggregates multiple event messages into a state replication protocol message, removing possible redundancy
+			conntrack sync daemon generates state replication protocol message
+			conntrack sync daemon sends state replication protocol message
+		on slave node(s), inside network RX softirq
+			connection tracking code ignores packets coming from the interface attached to the private conntrac sync network
+			state replication protocol messages is appended to socket receive queue of conntrack-sync kernel thread
+		on slave node(s), inside conntrack-sync kernel thread
+			conntrack sync daemon receives state replication message
+			conntrack sync daemon creates/updates conntrack entry
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Neccessary changes to kernel
+
+Neccessary changes to current conntrack core
+
+	event generation (callback functions) for all state changes
+
+	conntrack hashtable manipulation API
+		is needed (and already implemented) for 'ctnetlink' API
+
+	conntrack exemptions
+		needed to _not_ track conntrack state replication packets
+		is needed for other cases as well
+		currently being developed by Jozsef Kadlecsik
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Other current work
+
+	optimizing the conntrack code
+		hash function optimization
+			current hash function not good for even hash bucket count
+			other hash functions in development
+			hash function evaluation tool [cttest] avaliable
+			introduce per-system randomness to prevent hash attack
+		code optimization (locking/timers/...)
+
+	getting our work submitted into the mainstream kernel
+		turns out to be more difficult
+			e.g. newnat api now waiting for three months
+
+	discussions about multiple targets/actions per rule
+		technical implementation easy
+		however, not everybody convinced that it fits into the concept
+
+	using tc for firewalling
+		Jamal Hadi Selim uses iptables targets from within TC
+		leads to discussion of generic classification engine API in kernel
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Thanks
+	The slides and the an according paper of this presentation are available at http://www.gnumonks.org/
+
+	The netfilter homepage http://www.netfilter.org/
+
+	Thanks to
+		the BBS people, Z-Netz, FIDO, ...
+			for heavily increasing my computer usage in 1992
+		KNF
+			for bringing me in touch with the internet as early as 1994
+			for providing a playground for technical people
+			for telling me about the existance of Linux!
+		Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen
+			for implementing (one of?) the world's best TCP/IP stacks
+		Paul 'Rusty' Russell
+			for starting the netfilter/iptables project
+			for trusting me to maintain it today
+		Astaro AG
+			for sponsoring parts of my netfilter work
+
diff --git a/2002/netfilter-internals-lsm2002/abstract b/2002/netfilter-internals-lsm2002/abstract
new file mode 100644
index 0000000..1cc18b0
--- /dev/null
+++ b/2002/netfilter-internals-lsm2002/abstract
@@ -0,0 +1,49 @@
+Linux 2.4.x netfilter/iptables firewalling internals (lt-690870524)
+
+  The Linux 2.4.x kernel series has introduced a totally new kernel firewalling subsystem.  It is much more than a plain successor of ipfwadm or ipchains.
+
+  The netfilter/iptables project has a very modular design and it's
+sub-projects can be split in several parts: netfilter, iptables, connection
+tracking, NAT and packet mangling.
+
+  While most users will already have learned how to use the basic functions
+of netfilter/iptables in order to convert their old ipchains firewalls to
+iptables, there's more advanced but less used functionality in
+netfilter/iptables.
+
+  The presentation covers the design principles behind the netfilter/iptables
+implementation.  This knowledge enables us to understand how the individual
+parts of netfilter/iptables fit together, and for which potential applications
+this is useful.
+
+Topics covered:
+
+- overview about the internal netfilter/iptables architecture
+	- the netfilter hooks inside the network protocol stacks
+	- packet selection with IP tables
+	- how is connection tracking and NAT integrated into the framework
+- the connection tracking system
+	- how good does it track the TCP state?
+	- how does it track ICMP and UDP state at all?
+	- layer 4 protocol helpers (GRE, ...)
+	- application helpers (ftp, irc, h323, ...)
+	- restrictions/limitations
+- the NAT system
+	- how does it interact with connection tracking?
+	- layer 4 protocol helpers
+	- application helpers (ftp, irc, ...)
+- misc
+	- how far is IPv6 firewalling with ip6tables?
+	- advances in failover/HA of stateful firewalls
+	- ivisible firewalls with iptables on a bridge
+	- userspace packet queueing with QUEUE
+	- userspace packet logging with ULOG
+
+Requirements:  
+- knowledge about the TCP/IP protocol family
+- knowledge about general firewalling and packet filtering concepts
+- prior experience with linux packet filters
+
+Audience:
+- firewall administrators
+- network developers
diff --git a/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.mgp b/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.mgp
new file mode 100644
index 0000000..fb8b444
--- /dev/null
+++ b/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.mgp
@@ -0,0 +1,520 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+Linux 2.4.x netfilter/iptables 
+firewalling internals
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@gnumonks.org>
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Contents
+
+
+	Introduction
+	Netfilter hooks in protocol stacks
+	Packet selection based on IP Tables
+	The Connection Tracking Subsystem
+	The NAT Subsystem based on netfilter + iptables 
+	Packet filtering using the 'filter' table
+	Packet mangling using the 'mangle' table
+	Advanced netfilter concepts
+	Current development and Future
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+netfilter/iptables in Linux 2.4
+Introduction
+
+Why did we need netfilter/iptables?
+Because ipchains...
+
+		has no infrastructure for passing packets to userspace
+		makes transparent proxying extremely difficult
+		has interface address dependent Packet filter rules
+		has Masquerading implemented as part of packet filtering
+		code is too complex and intermixed with core ipv4 stack
+		is neither modular nor extensible
+		only barely supports one special case of NAT (masquerading)
+		has only stateless packet filtering
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Introduction 
+
+Who's behind netfilter/iptables
+		Paul 'Rusty' Russel
+			co-author of iptables in Linux 2.2
+			was paid by Watchguard for about one Year of development
+		James Morris
+			userspace queuing (kernel, library and tools)
+			REJECT target
+		Marc Boucher
+			NAT and packet filtering controlled by one command
+			Mangle table
+		Harald Welte 
+			Conntrack+NAT helper infrastructure (newnat)
+			Userspace packet logging (ULOG)
+			PPTP and IRC conntrack/NAT helpers
+		Jozsef Kadlecsik
+			TCP window tracking
+			H.323 conntrack + NAT helper
+			Continued newnat development
+		Non-core team contributors
+			http://www.netfilter.org/scoreboard/
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Netfilter Hooks
+
+What is netfilter?
+
+		System of callback functions within network stack
+		Callback function to be called for every packet traversing certain point (hook) within network stack
+		Protocol independent framework
+		Hooks in layer 3 stacks (IPv4, IPv6, DECnet, ARP)
+		Multiple kernel modules can register with each of the hooks
+		Asynchronous packet handling in userspace (ip_queue)
+
+Traditional packet filtering, NAT, ... is implemented on top of this framework
+
+Can be used for other stuff interfacing with the core network stack, like DECnet routing daemon.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Netfilter Hooks
+
+Netfilter architecture in IPv4
+%font "courier"
+
+   --->[1]--->[ROUTE]--->[3]--->[4]--->
+                 |            ^
+                 |            |
+                 |         [ROUTE]
+                 v            |
+                [2]          [5]
+                 |            ^
+                 |            |
+                 v            |
+
+%font "standard"
+1=NF_IP_PRE_ROUTING
+2=NF_IP_LOCAL_IN
+3=NF_IP_FORWARD
+4=NF_IP_POST_ROUTING
+5=NF_IP_LOCAL_OUT
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Netfilter Hooks
+
+Netfilter Hooks
+
+	Any kernel module may register a callback function at any of the hooks
+
+	The module has to return one of the following constants
+
+		NF_ACCEPT	 continue traversal as normal
+		NF_DROP		 drop the packet, do not continue
+		NF_STOLEN	 I've taken over the packet do not continue
+		NF_QUEUE	 enqueue packet to userspace
+		NF_REPEAT	 call this hook again
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP tables
+
+Packet selection using IP tables
+
+		The kernel provides generic IP tables support
+
+		Each kernel module may create it's own IP table
+
+		The three major parts of 2.4 firewalling subsystem are implemented using IP tables
+			Packet filtering table 'filter'
+			NAT table 'nat'
+			Packet mangling table 'mangle'
+
+		Can potentially be used for other stuff, i.e. IPsec SPDB
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Managing chains and tables
+
+	An IP table consists out of multiple chains
+	A chain consists out of a list of rules
+	Every single rule in a chain consists out of
+		match[es] (rule executed if all matches true)
+		target (what to do if the rule is matched)
+
+%size 4
+matches and targets can either be builtin or implemented as kernel modules
+
+%size 6
+	The userspace tool iptables is used to control IP tables
+		handles all different kinds of IP tables 
+		supports a plugin/shlib interface for target/match specific options
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Basic iptables commands
+
+	To build a complete iptables command, we must specify
+		which table to work with
+		which chain in this table to use
+		an operation (insert, add, delete, modify)
+		one or more matches (optional)
+		a target
+
+The syntax is
+%font "typewriter"
+%size 3
+iptables -t table -Operation chain -j target match(es)
+%font "standard"
+%size 5
+
+Example:
+%font "typewriter"
+%size 3
+iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp
+%font "standard"
+%size 5
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Matches
+		Basic matches
+			-p			protocol (tcp/udp/icmp/...)
+			-s			source address (ip/mask)
+			-d			destination address (ip/mask)
+			-i			incoming interface
+			-o			outgoing interface
+
+		Match extensions (examples)
+			tcp/udp		TCP/udp source/destination port
+			icmp			ICMP code/type
+			ah/esp		AH/ESP SPID match
+			mac		 	source MAC address
+			mark 		nfmark
+			length		match on length of packet
+			limit			rate limiting (n packets per timeframe)
+			owner	 	owner uid of the socket sending the packet
+			tos			TOS field of IP header
+			ttl			TTL field of IP header
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Targets 
+	very dependent on the particular table.
+
+	Table specific targets will be discussed later
+
+	Generic Targets, always available
+		ACCEPT		accept packet within chain
+		DROP		silently drop packet
+		QUEUE		enqueue packet to userspace
+		LOG		log packet via syslog
+		ULOG		log packet via ulogd
+		RETURN		return to previous (calling) chain
+		foobar		jump to user defined chain
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+netfilter/iptables in Linux 2.4
+Packet Filtering
+
+Overview
+
+	Implemented as 'filter' table
+	Registers with three netfilter hooks
+
+		NF_IP_LOCAL_IN (packets destined for the local host)
+		NF_IP_FORWARD (packets forwarded by local host)
+		NF_IP_LOCAL_OUT (packets from the local host)
+
+Each of the three hooks has attached one chain (INPUT, FORWARD, OUTPUT)
+
+Every packet passes exactly one of the three chains. Note that this is very different compared to the old 2.2.x ipchains behaviour.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Packet Filtering
+
+Targets available within 'filter' table
+
+	Builtin Targets to be used in filter table
+		ACCEPT	accept the packet
+		DROP	silently drop the packet 
+		QUEUE	enqueue packet to userspace
+		RETURN	return to previous (calling) chain
+		foobar	user defined chain
+
+	Targets implemented as loadable modules 
+		REJECT	drop the packet but inform sender
+		MIRROR	change source/destination IP and resend
+		LOG  	log via syslog
+		ULOG	log via userspace
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Connection Tracking Subsystem
+
+	Connection tracking...
+
+		implemented seperately from NAT 
+		enables stateful filtering 
+		implementation
+			hooks into NF_IP_PRE_ROUTING to track packets
+			hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules
+			protocol modules (currently TCP/UDP/ICMP)
+			application helpers currently (FTP,IRC,H.323,talk,SNMP)
+		divides packets in the following four categories
+			NEW - would establish new connection
+			ESTABLISHED - part of already established connection
+			RELATED - is related to established connection
+			INVALID - (multicast, errors...)
+		does _NOT_ filter packets itself
+		can be utilized by iptables using the 'state' match 
+		is used by NAT Subsystem
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Common structures
+	struct ip_conntrack_tuple, representing unidirectional flow
+		layer 3 src + dst 
+		layer 4 protocol
+		layer 4 src + dst
+
+
+	connetions represented as struct ip_conntrack
+		original tuple
+		reply tuple
+		timeout
+		l4 state private data
+		app helper
+		app helper private data
+		expected connections
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for new packet
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple) -> fails
+		new ip_conntrack is allocated
+			fill in original and reply == inverted(original) tuple
+			initialize timer
+			assign app helper if applicable
+			see if we've been expected -> fails
+			call layer 4 helper 'new' function
+
+	...
+
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> fails
+		place struct ip_conntrack in hashtable			
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+HA for netfillter/iptables
+Connection Tracking Subsystem
+
+Flow of events for packet part of existing connection
+	packet enters NF_IP_PRE_ROUTING
+		tuple is derived from packet
+		lookup conntrack hash table with hash(tuple)
+		assosiate conntrack entry with skb->nfct
+		call l4 protocol helper 'packet' function
+			do l4 state tracking
+			update timeouts as needed [i.e. TCP TIME_WAIT,...]
+
+	...
+	
+	packet enters NF_IP_POST_ROUTING
+		do hashtable lookup for packet -> succeds
+		do nothing else
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Network Address Translation
+
+Overview
+
+		Previous Linux Kernels only implemented one special case of NAT: Masquerading
+		Linux 2.4.x can do any kind of NAT.
+		NAT subsystem implemented on top of netfilter, iptables and conntrack
+		NAT subsystem registers with all five netfilter hooks
+		'nat' Table registers chains PREROUTING, POSTROUTING and OUTPUT
+		Following targets available within 'nat' Table
+			SNAT changes the packet's source whille passing NF_IP_POST_ROUTING
+			DNAT changes the packet's destination while passing NF_IP_PRE_ROUTING
+			MASQUERADE is a special case of SNAT
+			REDIRECT is a special case of DNAT
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Network Address Translation
+
+	Source NAT
+		SNAT Example:
+%font "typewriter"
+%size 3
+iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -s 10.0.0.0/8
+%font "standard"
+%size 4
+
+		MASQUERADE Example:
+%font "typewriter"
+%size 3
+iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0
+%font "standard"
+%size 5
+
+	Destination NAT
+		DNAT example
+%font "typewriter"
+%size 3
+iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -p tcp --dport 80 -i eth1
+%font "standard"
+%size 4
+
+		REDIRECT example
+%font "typewriter"
+%size 3
+iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80
+%font "standard"
+%size 5
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Packet Mangling
+
+	Purpose of mangle table
+		packet manipulation except address manipulation
+
+	Integration with netfilter
+		'mangle' table hooks in all five netfilter hooks
+		priority: after conntrack
+
+	Targets specific to the 'mangle' table:
+		DSCP - manipulate DSCP field
+		IPV4OPTSSTRIP - strip IPv4 options
+		MARK - change the nfmark field of the skb
+		TCPMSS - set TCP MSS option
+		TOS - manipulate the TOS bits 
+		TTL - set / increase / decrease TTL field
+
+Simple example:
+%font "typewriter"
+%size 3
+iptables -t mangle -A PREROUTING -j MARK --set-mark 10 -p tcp --dport 80
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Advanced Netfilter concepts
+
+%size 4
+	Userspace logging
+		flexible replacement for old syslog-based logging
+		packets to userspace via multicast netlink sockets
+		easy-to-use library (libipulog)
+		plugin-extensible userspace logging daemon (ulogd)
+		Can even be used to directly log into MySQL
+
+	Queuing
+		reliable asynchronous packet handling 
+		packets to userspace via unicast netlink socket
+		easy-to-use library (libipq)
+		provides Perl bindings
+		experimental queue multiplex daemon (ipqmpd)
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Current Development and Future
+
+Netfilter (although it proved very stable) is still work in progress. 
+
+	Areas of current development
+		infrastructure for conntrack manipulation from userspace
+		failover of stateful firewalls
+		making iptables layer3 independent (pkttables)
+		new userspace library (libiptables) to hide plugins from apps
+		more matches and targets for advanced functions (pool, hashslot)
+		more conntrack and NAT modules (RPC, SNMP, SMB, ...)
+		better IPv6 support (conntrack, more matches / targets)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Future of Linux packet filtering
+Thanks
+	The slides and the an according paper of this presentation are available at http://www.gnumonks.org/
+
+	The netfilter homepage http://www.netfilter.org/
+
+	Thanks to
+		the BBS people, Z-Netz, FIDO, ...
+			for heavily increasing my computer usage in 1992
+		KNF
+			for bringing me in touch with the internet as early as 1994
+			for providing a playground for technical people
+			for telling me about the existance of Linux!
+		Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen
+			for implementing (one of?) the world's best TCP/IP stacks
+		Paul 'Rusty' Russell
+			for starting the netfilter/iptables project
+			for trusting me to maintain it today
+		Astaro AG
+			for sponsoring parts of my netfilter work
+
diff --git a/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.tex b/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.tex
new file mode 100644
index 0000000..c3a28ea
--- /dev/null
+++ b/2002/netfilter-internals-lsm2002/netfilter-internals-lsm2002.tex
@@ -0,0 +1,537 @@
+\documentclass{article}
+\usepackage{german}
+\usepackage{fancyheadings}
+\usepackage{a4}
+
+\setlength{\oddsidemargin}{0in}
+\setlength{\evensidemargin}{0in}
+\setlength{\topmargin}{0.0in}
+\setlength{\headheight}{0in}
+\setlength{\headsep}{0in}
+\setlength{\textwidth}{6.5in}
+\setlength{\textheight}{9.5in}
+\setlength{\parindent}{0in}
+\setlength{\parskip}{0.05in}
+
+
+\begin{document}
+\title{Linux 2.4.x netfilter/iptables firewalling internals}
+
+\author{Harald Welte\\
+        laforge@gnumonks.org\\
+	\copyright{}2002 H. Welte}
+
+\date{25. April 2002}
+
+\maketitle
+
+\setcounter{section}{0}
+\setcounter{subsection}{0}
+\setcounter{subsubsection}{0}
+
+\section{Introduction}
+The Linux 2.4.x kernel series has introduced a totally new kernel firewalling
+subsystem.  It is much more than a plain successor of ipfwadm or ipchains.
+
+The netfilter/iptables project has a very modular design and it's
+sub-projects can be split in several parts: netfilter, iptables, connection
+tracking, NAT and packet mangling.
+
+While most users will already have learned how to use the basic functions
+of netfilter/iptables in order to convert their old ipchains firewalls to
+iptables, there's more advanced but less used functionality in
+netfilter/iptables.
+
+The presentation covers the design principles behind the netfilter/iptables
+implementation.  This knowledge enables us to understand how the individual
+parts of netfilter/iptables fit together, and for which potential applications
+this is useful.
+
+\section{Internal netfilter/iptables architecture}
+
+\subsection{Netfilter hooks in protocol stacks}
+
+One of the major motivations behind the redesign of the linux packet
+filtering and NAT system during the 2.3.x kernel series was the widespread
+firewall specific code parts within the core IPv4 stack.  Ideally the core
+IPv4 stack (as used by regular hosts and routers) shouldn't contain any
+firewalling specific code, resulting in no unwanted interaction and less
+code complexity.  This desire lead to the invention of {\it netfilter}.
+
+\subsubsection{Architecture of netfilter}
+
+Netfilter is basically a system of callback functions within the network
+stack.  It provides a non-portable API towards in-kernel networking
+extensions.
+  
+What we call {\it netfilter hook} is a well-defined call-out point within a
+layer three protocol stack, such as IPv4, IPv6 or DECnet.  Any layer three
+network stack can define an arbitrary number of hooks, usually placed at
+strategic points within the packet flow.
+
+Any other kernel code can now subsequently register callback functions for
+any of these hooks.  As in most sytems will be more than one callback
+function registered for a particular hook, a {\it priority} is specified upon
+registration of the callback function.  This priority defines the order in
+which the individual callback functions at a particular hook are called.
+
+The return value of any registered callback functions can be:
+\begin{itemize}
+\item
+{\bf NF\_ACCEPT}: continue traversal as usual
+\item
+{\bf NF\_DROP}: drop the packet; do not continue traversal
+\item
+{\bf NF\_STOLEN}: callback function has taken over the packet; do not continue
+\item
+{\bf NF\_QUEUE}: enqueue the packet to userspace
+\item
+{\bf NF\_REPEAT}: call this hook again
+\end{itemize}
+
+\subsubsection{Netfilter hooks within IPv4}
+
+The IPv4 stack provides five netfilter hooks, which are placed at the
+following peculiar places within the code:
+
+\begin{verbatim}
+   --->[1]--->[ROUTE]--->[3]--->[4]--->
+                 |            ^
+                 |            |
+                 |         [ROUTE]
+                 v            |
+                [2]          [5]
+                 |            ^
+                 |            |
+                 v            |
+
+                local processes
+\end{verbatim}
+
+Packets received on any network interface arrive at the left side of the
+diagram.  After the verification of the IP header checksum, the
+NF\_IP\_PRE\_ROUTING [1] hook is traversed.  
+
+If they ``survive'' (i.e.  NF\_ACCEPT is returned), the packet enters the
+routing code.  Where we continue from here depends on the destintion of the
+packet.
+
+Packets with a local destination (i.e. packets where the destination address is
+one of the own IP addresses of the host) traverse the NF\_IP\_LOCAL\_IN [2]
+hook.  If all callback function return NF\_ACCEPT, the packet is finally passed
+to the socket code, which eventually passes the packet to a local process.
+
+Packets with a remote destination (i.e. packets which are forwarded by the
+local machine) traverse the NF\_IP\_FORWARD [3] hook.  If they ``survive'',
+they finally pass the NF\_IP\_POST\_ROUTING [4] hook and are sent off the
+outgoing network interface.
+
+Locally generated packets first traverse the NF\_IP\_LOCAL\_OUT [5] hook, then
+enter the routing code, and finally go through the NF\_IP\_POST\_ROUTING [4]
+hook before being sent off the outgoing network interface.
+
+\subsubsection{Netfilter hooks within IPv6}
+
+As the IPv4 and IPv6 protocols are very similar, the netfilter hooks within the
+IPv6 stack are placed at exactly the same locations as in the IPv4 stack.  The
+only change are the hook names: NF\_IP6\_PRE\_ROUTING, NF\_IP6\_LOCAL\_IN,
+NF\_IP6\_FORWARD, NF\_IP6\_POST\_ROUTING, NF\_IP6\_LOCAL\_OUT.
+
+\subsubsection{Netfilter hooks within DECnet}
+
+There are seven decnet hooks.  The first five hooks (NF\_DN\_PRE\_ROUTING,
+NF\_DN\_LOCAL\_IN, NF\_DN\_FORWARD, NF\_DN\_LOCAL\_OUT, NF\_DN\_POST\_ROUTING)
+are prretty much the same as in IPv4.  The last two hooks (NF\_DN\_HELLO,
+NF\_DN\_ROUTE) are used in conjunction with DECnet Hello and Routing packets.
+
+\subsubsection{Netfilter hooks within ARP}
+
+Recent kernels\footnote{IIRC, starting with 2.4.19-pre3} have added support for netfilter hooks within the ARP code.
+There are two hooks: NF\_ARP\_IN and NF\_ARP\_OUT, for incoming and outgoing
+ARP packets respectively.
+
+\subsubsection{Netfilter hooks within IPX}
+
+There have been experimental patches to add netfilter hooks to the IPX code,
+but they never got integrated into the kernel source.
+
+\subsection{Packet selection using IP Tables}
+
+The IP tables core (ip\_tables.o) provides a generic layer for evaluation
+of rulesets.  
+
+An IP table consists out of an arbitrary number of {\it chains}, which in turn
+consist out of a linear list of {\it rules}, which again consist out of any
+number of {\it matches} and one {\it target}.
+
+{\it Chains} can further be devided into two classes: Either {\it builtin
+chains} or {\it user-defined chains}.  Builtin chains are always present, they
+are created upon table registration.  They are also the entry points for table
+iteration.  User defined chains are created at runtime upon user interaction.
+
+{\it Matches} specify the matching criteria, there can be zero or more matches
+
+{\it Targets} specify the action which is to be executed in case {\bf all}
+matches match.  There can only be a single target per rule.
+
+Matches and targets can either be {\it builtin} or {\it linux kernel modules}.
+
+There are two special targets:
+\begin{itemize}
+\item
+By using a chain name as target, it is possible to jump to the respective chain
+in case the matches match.
+\item
+By using the RETURN target, it is possible to return to the previous (calling)
+chain
+\end{itemize}
+
+The IP tables core handles the following functions
+\begin{itemize}
+\item
+Registering and unregistering tables
+\item
+Registering and unregistering matches and targets (can be implemented as linux kernel modules)
+\item
+Kernel / userspace interface for manipulation of IP tables
+\item
+Traversal of IP tables
+\end{itemize}
+
+\subsubsection{Packet filtering unsing the ``filter'' table}
+
+Traditional packet filtering (i.e. the successor to ipfwadm/ipchains) takes
+place in the ``filter'' table.  Packet filtering works like a sieve: A packet
+is (in the end) either dropped or accepted - but never modified.
+
+The ``filter'' table is implemented in the {\it iptable\_filter.o} module
+and contains three builtin chains:
+
+\begin{itemize}
+\item
+{\bf INPUT} attaches to NF\_IP\_LOCAL\_IN
+\item
+{\bf FORWARD} attaches to NF\_IP\_FORWARD
+\item
+{\bf OUTPUT} attaches to NF\_IP\_LOCAL\_OUT
+\end{itemize}
+
+The placement of the chains / hooks is done in such way, that evey concievable
+packet always traverses only one of the built-in chains.  Packets destined for
+the local host traverse only INPUT, packets forwarded only FORWARD and
+locally-originated packets only OUTPUT.
+
+\subsubsection{Packet mangling using the ``mangle'' table} 
+
+As stated above, operations which would modify a packet do not belong in the
+``filter'' table.   The ``mangle'' table is available for all kinds of packet
+manipulation - but not manipulation of addresses (which is NAT).
+
+The mangle table attaches to all five netfilter hooks and provides the
+respectiva builtin chains (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING)
+\footnote{This has changed through recent 2.4.x kernel series, old kernels may
+only support three (PREROUTING, POSTROUTING, OUTPUT) chains.}.
+
+\subsection{Connection Tracking Subsystem}
+
+Traditional packet filters can only match on matching criteria within the
+currently processed packet, like source/destination IP address, port numbers,
+TCP flags, etc.  As most applications have a notion of connections or at least
+a request/response style protocol, there is a lot of information which can not
+be derived from looking at a single packet.
+
+Thus, modern (stateful) packet filters attempt to track connections (flows)
+and their respective protocol states for all traffic through the packet
+filter.
+
+Connection tracking within linux is implemented as a netfilter module, called
+ip\_conntrack.o.  
+
+Before describing the connection tracking subsystem, we need to describe a couple of definitions and primitives used throughout the conntrack code.
+
+A connection is represented within the conntrack subsystem using {\it struct
+ip\_conntrack}, also called {\it connection tracking entry}.
+
+Connection tracking is utilizing {\it conntrack tuples}, which are tuples
+consisting out of (srcip, srcport, dstip, dstport, l4prot).  A connection is
+uniquely identified by two tuples:  The tuple in the original direction
+(IP\_CT\_DIR\_ORIGINAL) and the tuple for the reply direction
+(IP\_CT\_DIR\_REPLY).
+
+Connection tracking itself does not drop packets\footnote{well, in some rare
+cases in combination with NAT it needs to drop. But don't tell anyone, this is
+secret.} or impose any policy.  It just associates every packet with a
+connection tracking entry, which in turn has a particular state.  All other
+kernel code can use this state information\footnote{state information is
+internally represented via the {\it struct sk\_buff.nfct} structure member of a
+packet.}.
+
+\subsubsection{Integration of conntrack with netfilter} 
+
+If the ip\_conntrack.o module is registered with netfilter, it attaches to the
+NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING, NF\_IP\_LOCAL\_IN and
+NF\_IP\_LOCAL\_OUT hooks.
+
+Because forwarded packets are the most common case on firewalls, I will only
+describe how connection tracking works for forwarded packets.  The two relevant
+hooks for forwarded packets are NF\_IP\_PRE\_ROUTING and NF\_IP\_POST\_ROUTING.
+
+Every time a packet arrives at the NF\_IP\_PRE\_ROUTING hook, connection
+tracking creates a conntrack tuple from the packet.  It then compares this
+tuple to the original and reply tuples of all already-seen connections
+\footnote{Of course this is not implemented as a linear search over all existing connections.} to find out if this just-arrived packet belongs to any existing
+connection.  If there is no match, a new conntrack table entry (struct
+ip\_conntrack) is created.
+
+Let's assume the case where we have already existing connections but are
+starting from scratch.
+
+The first packet comes in, we derive the tuple from the packet headers, look up
+the conntrack hash table, don't find any matching entry.  As a result, we
+create a new struct ip\_conntrack.  This struct ip\_conntrack is filled with
+all necessarry data, like the original and reply tuple of the connection.
+How do we know the reply tuple?  By inverting the source and destination
+parts of the original tuple.\footnote{So why do we need two tuples, if they can
+be derived from each other?  Wait until we discuss NAT.}
+Please note that this new struct ip\_conntrack is {\bf not} yet placed
+into the conntrack hash table.
+
+The packet is now passed on to other callback functions which have registered
+with a lower priority at NF\_IP\_PRE\_ROUTING.  It then continues traversal of
+the network stack as usual, including all respective netfilter hooks.
+
+If the packet survives (i.e. is not dropped by the routing code, network stack,
+firewall ruleset, ...), it re-appears at NF\_IP\_POST\_ROUTING.  In this case,
+we can now safely assume that this packet will be sent off on the outgoing
+interface, and thus put the connection tracking entry which we created at
+NF\_IP\_PRE\_ROUTING into the conntrack hash table.  This process is called
+{\it confirming the conntrack}.
+
+The connection tracking code itself is not monolithic, but consists out of a
+couple of seperate modules\footnote{They don't actually have to be seperate
+kernel modules; e.g. TCP, UDP and ICMP tracking modules are all part of
+the linux kernel module ip\_conntrack.o}.  Besides the conntrack core, there
+are two important kind of modules: Protocol helpers and application helpers.
+
+Protocol helpers implement the layer-4-protocol specific parts.  They currently
+exist for TCP, UDP and ICMP (an experimental helper for GRE exists).
+
+\subsubsection{TCP connection tracking}
+
+As TCP is a connection oriented protocol, it is not very difficult to imagine
+how conntection tracking for this protocol could work.  There are well-defined
+state transitions possible, and conntrack can decide which state transitions
+are valid within the TCP specification.  In reality it's not all that easy,
+since we cannot assume that all packets that pass the packet filter actually
+arrive at the receiving end, ...
+
+It is noteworthy that the standard connection tracking code does {\bf not}
+do TCP sequence number and window tracking.  A well-maintained patch to add
+this feature exists almost as long as connection tracking itself.  It will
+be integrated with the 2.5.x kernel.  The problem with window tracking is
+it's bad interaction with connection pickup.  The TCP conntrack code is able to
+pick up already existing connections, e.g. in case your firewall was rebooted.
+However, connection pickup is conflicting with TCP window tracking:  The TCP
+window scaling option is only transferred at connection setup time, and we
+don't know about it in case of pickup...
+
+\subsubsection{ICMP tracking}
+
+ICMP is not really a connection oriented protocol.  So how is it possible to
+do connection tracking for ICMP?
+
+The ICMP protocol can be split in two groups of messages
+
+\begin{itemize}
+\item
+ICMP error messages, which sort-of belong to a different connection
+ICMP error messages are associated {\it RELATED} to a different connection.
+(ICMP\_DEST\_UNREACH, ICMP\_SOURCE\_QUENCH, ICMP\_TIME\_EXCEEDED,
+ICMP\_PARAMETERPROB, ICMP\_REDIRECT). 
+\item
+ICMP queries, which have a request->reply character.  So what the conntrack
+code does, is let the request have a state of {\it NEW}, and the reply 
+{\it ESTABLISHED}.  The reply closes the connection immediately.
+(ICMP\_ECHO, ICMP\_TIMESTAMP, ICMP\_INFO\_REQUEST, ICMP\_ADDRESS)
+\end{itemize}
+
+\subsubsection{UDP connection tracking}
+
+UDP is designed as a connectionless datagram protocol. But most common
+protocols using UDP as layer 4 protocol have bi-directional UDP communication.
+Imagine a DNS query, where the client sends an UDP frame to port 53 of the
+nameserver, and the nameserver sends back a DNS reply packet from it's  UDP
+port 53 to the client.
+
+Netfilter trats this as a connection. The first packet (the DNS request) is
+assigned a state of {\it NEW}, because the packet is expected to create a new
+'connection'. The dns servers' reply packet is marked as {\it ESTABLISHED}.
+
+\subsubsection{conntrack application helpers}
+
+More complex application protocols involving multiple connections need special
+support by a so-called ``conntrack application helper module''.  Modules in
+the stock kernel come for FTP and IRC(DCC).  Netfilter CVS currently contains
+patches for PPTP, H.323, Eggdrop botnet, tftp ald talk.  We're still lacking
+a lot of protocols (e.g. SIP, SMB/CIFS) - but they are unlikely to appear
+until somebody really needs them and either develops them on his own or
+funds development.
+
+\subsubsection{Integration of connection tracking with iptables}
+
+As stated earlier, conntrack doesn't impose any policy on packets.  It just
+determines the relation of a packet to already existing connections.  To base
+packet filtering decision on this sate information, the iptables {\it state}
+match can be used.  Every packet is within one of the following categories:
+
+\begin{itemize}
+\item
+{\bf NEW}: packet would create a new connection, if it survives
+\item
+{\bf ESTABLISHED}: packet is part of an already established connection 
+(either direction)
+\item
+{\bf RELATED}: packet is in some way related to an already established connection, e.g. ICMP errors or FTP data sessions
+\item
+{\bf INVALID}: conntrack is unable to derive conntrack information from this packet.  Please note that all multicast or broadcast packets fall in this category.
+\end{itemize}
+
+\subsection{NAT Subsystem}
+
+The NAT (Network Address Translation)  subsystem is probably the worst
+documented subsystem within the whole framework.  This has two reasons:  NAT is
+nasty and complicated.  The Linux 2.4.x NAT implementation is easy to use, so
+nobody needs to know the nasty details.
+
+Nonetheless, as I was traditionally concentrating most on the conntrack and NAT
+systems, I will give a short overview.
+
+NAT uses almost all of the previously described subsystems:
+\begin{itemize}
+\item
+IP tables to specify which packets to NAT in which particular way. NAT
+registers a ``nat'' table with PREROUTING, POSTROUTING and OUTPUT chains. 
+\item
+Connection tracking to associate NAT state with the connection.
+\item
+Netfilter to do the actuall packet manipulation transparent to the rest of the
+kernel.  NAT registers with NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING,
+NF\_IP\_LOCAL\_IN and NF\_IP\_LOCAL\_OUT.
+\end{itemize}
+
+The NAT implementation supports all kinds of different nat; Source NAT,
+Destination NAT, NAT to address/port ranges, 1:1 NAT, ...
+
+This fundamental design principle is still frequently misunderstood:\\
+The information about which NAT mappings apply to a certain connection
+is only gathered once - with the first packet of every connection.
+
+So let's start to look at the life of a poor to-be-nat'ed packet.
+For ease of understanding, I have chosen to describe the most frequently
+used NAT scenario:  Source NAT of a forwarded packet.  Let's assume the
+packet has an original source address of 1.1.1.1, an original destination
+address of 2.2.2.2, and is going to be SNAT'ed to 9.9.9.9.  Let's further
+ignore the fact that there are port numbers.
+
+Once upon a time, our poor packet arrives at NF\_IP\_PRE\_ROUTING, where
+conntrack has registered with highest priority.  This means that a conntrack
+entry with the following two tuples is created:
+\begin{verbatim}
+IP_CT_DIR_ORIGINAL: 1.1.1.1 -> 2.2.2.2
+IP_CT_DIR_REPLY: 2.2.2.2 -> 1.1.1.1
+\end{verbatim}
+After conntrack, the packet traverses the PREROUTING chain of the ``nat''
+IP table.  Since only destination NAT happens at PREROUTING, no action
+occurs.  After it's lengthy way through the rest of the network stack,
+the packet arrives at the NF\_IP\_POST\_ROUTING hook, where it traverses
+the POSTROUTING chain of the ``nat'' table.  Here it hits a SNAT rule,
+causing the following actions:
+\begin{itemize}
+\item
+Fill in a {\it struct ip\_nat\_manip}, indicating the new source address
+and the type of NAT (source NAT at POSTROUTING).  This struct is part of the
+conntrack entry.
+\item
+Automatically derive the inverse NAT transormation for the reply packets:
+Destination NAT at PREROUTING.  Fill in another {\it struct ip\_nat\_manip}.
+\item
+Alter the REPLY tuple of the conntrack entry to
+\begin{verbatim}
+IP_CT_DIR_REPLY: 2.2.2.2 -> 9.9.9.9
+\end{verbatim}
+\item
+Apply the SNAT transformation to the packet
+\end{itemize}
+
+Every other packt within this connection, independent of its direction,
+will only execute the last step.  Since all NAT information is connected
+with the conntrack entry, there is no need to do anything but to apply
+the same transormations to all packets witin the same connection.
+
+\subsection{IPv6 Firewalling with ip6tables}
+
+Yes, Linux 2.4.x comes with a usable, though incomplete system to secure
+your IPv6 network.
+
+The parts ported to IPv6 are
+\begin{itemize}
+\item
+IP tables (called IP6 tables)
+\item
+The ``filter'' table
+\item
+The ``mangle'' table
+\item
+The userspace library (libip6tc)
+\item
+The command line tool (ip6tables)
+\end{itemize}
+
+Due to the lack of conntrack and NAT\footnote{for god's sake we don't have NAT
+with IPv6}, only traditional, stateless packet filtering is possible.  Apart
+from the obvious matches/targets, ip6tables can match on
+\begin{itemize}
+\item
+{\it EUI64 checker}; verifies if the MAC address of the sender is the same as in the EUI64 64 least significant bits of the source IPv6 address
+\item
+{\it frag6 match}, matches on IPv6 fragmentation header
+\item
+{\it route6 match}, matches on IPv6 routing header
+\item
+{\it ahesp6 match}, matches on SPIDs within AH or ESP over IPv6 packets
+\end{itemize}
+
+However, the ip6tables code doesn't seem to be used very widely (yet?). 
+So please expect some potential remaining issues, since it is not tested
+as heavily as iptables.
+
+\subsection{Recent Development}
+
+Please refer to the spoken word at the presentation.  Development at the 
+time this paper was written can be quite different from development at the
+time the presentation is held.
+
+\section{Thanks}
+
+I'd like to thank
+\begin{itemize}
+\item
+{\it Linus Torvalds} for starting this interesting UNIX-like kernel
+\item
+{\it Alan Cox, David Miller, Alexey Kuznetesov, Andi Kleen} for building 
+(one of?) the world's best TCP/IP stacks.
+\item
+{\it Paul ``Rusty'' Russell} for starting the netfilter/iptables project
+\item
+{\it The Netfilter Core Team} for continuing the netfilter/iptables effort
+\item
+{\it Astaro AG} for partially funding my current netfilter/iptables work
+\item
+{\it Conectiva Inc.} for partially funding parts of my past netfilter/iptables
+work and for inviting me to live in Brazil
+\item
+{\it samba.org and Kommunikationsnetz Franken e.V.} for hosting the netfilter
+homepage, CVS, mailing lists, ...
+\end{itemize}
+
+\end{document}
diff --git a/2002/netfilter-internals-lt2002/abstract b/2002/netfilter-internals-lt2002/abstract
new file mode 100644
index 0000000..1cc18b0
--- /dev/null
+++ b/2002/netfilter-internals-lt2002/abstract
@@ -0,0 +1,49 @@
+Linux 2.4.x netfilter/iptables firewalling internals (lt-690870524)
+
+  The Linux 2.4.x kernel series has introduced a totally new kernel firewalling subsystem.  It is much more than a plain successor of ipfwadm or ipchains.
+
+  The netfilter/iptables project has a very modular design and it's
+sub-projects can be split in several parts: netfilter, iptables, connection
+tracking, NAT and packet mangling.
+
+  While most users will already have learned how to use the basic functions
+of netfilter/iptables in order to convert their old ipchains firewalls to
+iptables, there's more advanced but less used functionality in
+netfilter/iptables.
+
+  The presentation covers the design principles behind the netfilter/iptables
+implementation.  This knowledge enables us to understand how the individual
+parts of netfilter/iptables fit together, and for which potential applications
+this is useful.
+
+Topics covered:
+
+- overview about the internal netfilter/iptables architecture
+	- the netfilter hooks inside the network protocol stacks
+	- packet selection with IP tables
+	- how is connection tracking and NAT integrated into the framework
+- the connection tracking system
+	- how good does it track the TCP state?
+	- how does it track ICMP and UDP state at all?
+	- layer 4 protocol helpers (GRE, ...)
+	- application helpers (ftp, irc, h323, ...)
+	- restrictions/limitations
+- the NAT system
+	- how does it interact with connection tracking?
+	- layer 4 protocol helpers
+	- application helpers (ftp, irc, ...)
+- misc
+	- how far is IPv6 firewalling with ip6tables?
+	- advances in failover/HA of stateful firewalls
+	- ivisible firewalls with iptables on a bridge
+	- userspace packet queueing with QUEUE
+	- userspace packet logging with ULOG
+
+Requirements:  
+- knowledge about the TCP/IP protocol family
+- knowledge about general firewalling and packet filtering concepts
+- prior experience with linux packet filters
+
+Audience:
+- firewall administrators
+- network developers
diff --git a/2002/netfilter-internals-lt2002/biography b/2002/netfilter-internals-lt2002/biography
new file mode 100644
index 0000000..27b77bd
--- /dev/null
+++ b/2002/netfilter-internals-lt2002/biography
@@ -0,0 +1,22 @@
+  <a href="http://www.gnumonks.org/users/laforge/">Harald Welte</a> is one 
+of the five <a href="http://www.netfilter.org/">netfilter/iptables</a> core
+team members, and the current Linux 2.4.x firewalling maintainer.  
+
+  His main interest in computing has always been networking.  In the few time
+left besides netfilter/iptables related work, he's writing obscure documents
+like the <a href="http://www.gnumonks.org/ftp/pub/doc/uucp-over-ssl.html"> UUCP
+over SSL HOWTO</a>.  Other kernel-related projects he has been contributing are
+user mode linux and the international (crypto) kernel patch.
+
+  In the past he has been working as an independent IT Consultant working on
+closed-source projecst for various companies ranging from banks to
+manufacturers of networking gear.  During the year 2001 he was living in
+Curitiba (Brazil), where he got sponsored for his Linux related work by 
+<a href="http://www.conectiva.com/">Conectiva Inc.</a>.
+
+  Starting with February 2002, Harald has been contracted part-time by
+<a href="http://www.astaro.com/">Astaro AG</a>, who are sponsoring him for his
+current netfilter/iptables work.
+
+  Harald is living in Erlangen, Germany.
+
diff --git a/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.mgp b/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.mgp
new file mode 100644
index 0000000..9487ff4
--- /dev/null
+++ b/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.mgp
@@ -0,0 +1,466 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+Linux 2.4.x netfilter/iptables 
+firewalling internals
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@gnumonks.org>
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Contents
+
+
+	Introduction
+	Netfilter hooks in protocol stacks
+	Packet selection based on IP Tables
+	The Connection Tracking Subsystem
+	The NAT Subsystem based on netfilter + iptables 
+	Packet filtering using the 'filter' table
+	Packet mangling using the 'mangle' table
+	Advanced netfilter concepts
+	Current development and Future
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+netfilter/iptables in Linux 2.4
+Introduction
+
+Why did we need netfilter/iptables?
+Because ipchains...
+
+		has no infrastructure for passing packets to userspace
+		makes transparent proxying extremely difficult
+		has interface address dependent Packet filter rules
+		has Masquerading implemented as part of packet filtering
+		code is too complex and intermixed with core ipv4 stack
+		is neither modular nor extensible
+		only barely supports one special case of NAT (masquerading)
+		has only stateless packet filtering
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Introduction 
+
+Who's behind netfilter/iptables
+		Paul 'Rusty' Russel
+			co-author of iptables in Linux 2.2
+			was paid by Watchguard for about one Year of development
+		James Morris
+			userspace queuing (kernel, library and tools)
+			REJECT target
+		Marc Boucher
+			NAT and packet filtering controlled by one command
+			Mangle table
+		Harald Welte 
+			Conntrack+NAT helper infrastructure (newnat)
+			Userspace packet logging (ULOG)
+			PPTP and IRC conntrack/NAT helpers
+		Jozsef Kadlecsik
+			TCP window tracking
+			H.323 conntrack + NAT helper
+			Continued newnat development
+		Non-core team contributors
+			http://www.netfilter.org/scoreboard/
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Netfilter Hooks
+
+What is netfilter?
+
+		System of callback functions within network stack
+		Callback function to be called for every packet traversing certain point (hook) within network stack
+		Protocol independent framework
+		Hooks in layer 3 stacks (IPv4, IPv6, DECnet, ARP)
+		Multiple kernel modules can register with each of the hooks
+		Asynchronous packet handling in userspace (ip_queue)
+
+Traditional packet filtering, NAT, ... is implemented on top of this framework
+
+Can be used for other stuff interfacing with the core network stack, like DECnet routing daemon.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Netfilter Hooks
+
+Netfilter architecture in IPv4
+%font "courier"
+
+   --->[1]--->[ROUTE]--->[3]--->[4]--->
+                 |            ^
+                 |            |
+                 |         [ROUTE]
+                 v            |
+                [2]          [5]
+                 |            ^
+                 |            |
+                 v            |
+
+%font "standard"
+1=NF_IP_PRE_ROUTING
+2=NF_IP_LOCAL_IN
+3=NF_IP_FORWARD
+4=NF_IP_POST_ROUTING
+5=NF_IP_LOCAL_OUT
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Netfilter Hooks
+
+Netfilter Hooks
+
+	Any kernel module may register a callback function at any of the hooks
+
+	The module has to return one of the following constants
+
+		NF_ACCEPT	 continue traversal as normal
+		NF_DROP		 drop the packet, do not continue
+		NF_STOLEN	 I've taken over the packet do not continue
+		NF_QUEUE	 enqueue packet to userspace
+		NF_REPEAT	 call this hook again
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP tables
+
+Packet selection using IP tables
+
+		The kernel provides generic IP tables support
+
+		Each kernel module may create it's own IP table
+
+		The three major parts of 2.4 firewalling subsystem are implemented using IP tables
+			Packet filtering table 'filter'
+			NAT table 'nat'
+			Packet mangling table 'mangle'
+
+		Can potentially be used for other stuff, i.e. IPsec SPDB
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Managing chains and tables
+
+	An IP table consists out of multiple chains
+	A chain consists out of a list of rules
+	Every single rule in a chain consists out of
+		match[es] (rule executed if all matches true)
+		target (what to do if the rule is matched)
+
+%size 4
+matches and targets can either be builtin or implemented as kernel modules
+
+%size 6
+	The userspace tool iptables is used to control IP tables
+		handles all different kinds of IP tables 
+		supports a plugin/shlib interface for target/match specific options
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Basic iptables commands
+
+	To build a complete iptables command, we must specify
+		which table to work with
+		which chain in this table to use
+		an operation (insert, add, delete, modify)
+		one or more matches (optional)
+		a target
+
+The syntax is
+%font "typewriter"
+%size 3
+iptables -t table -Operation chain -j target match(es)
+%font "standard"
+%size 5
+
+Example:
+%font "typewriter"
+%size 3
+iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp
+%font "standard"
+%size 5
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Matches
+		Basic matches
+			-p			protocol (tcp/udp/icmp/...)
+			-s			source address (ip/mask)
+			-d			destination address (ip/mask)
+			-i			incoming interface
+			-o			outgoing interface
+
+		Match extensions (examples)
+			tcp/udp		TCP/udp source/destination port
+			icmp			ICMP code/type
+			ah/esp		AH/ESP SPID match
+			mac		 	source MAC address
+			mark 		nfmark
+			length		match on length of packet
+			limit			rate limiting (n packets per timeframe)
+			owner	 	owner uid of the socket sending the packet
+			tos			TOS field of IP header
+			ttl			TTL field of IP header
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Targets 
+	very dependent on the particular table.
+
+	Table specific targets will be discussed later
+
+	Generic Targets, always available
+		ACCEPT		accept packet within chain
+		DROP		silently drop packet
+		QUEUE		enqueue packet to userspace
+		LOG		log packet via syslog
+		ULOG		log packet via ulogd
+		RETURN		return to previous (calling) chain
+		foobar		jump to user defined chain
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+netfilter/iptables in Linux 2.4
+Packet Filtering
+
+Overview
+
+	Implemented as 'filter' table
+	Registers with three netfilter hooks
+
+		NF_IP_LOCAL_IN (packets destined for the local host)
+		NF_IP_FORWARD (packets forwarded by local host)
+		NF_IP_LOCAL_OUT (packets from the local host)
+
+Each of the three hooks has attached one chain (INPUT, FORWARD, OUTPUT)
+
+Every packet passes exactly one of the three chains. Note that this is very different compared to the old 2.2.x ipchains behaviour.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Packet Filtering
+
+Targets available within 'filter' table
+
+	Builtin Targets to be used in filter table
+		ACCEPT	accept the packet
+		DROP	silently drop the packet 
+		QUEUE	enqueue packet to userspace
+		RETURN	return to previous (calling) chain
+		foobar	user defined chain
+
+	Targets implemented as loadable modules 
+		REJECT	drop the packet but inform sender
+		MIRROR	change source/destination IP and resend
+		LOG  	log via syslog
+		ULOG	log via userspace
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Connection Tracking Subsystem
+
+	Connection tracking...
+
+		implemented seperately from NAT 
+		enables stateful filtering 
+		implementation
+			hooks into NF_IP_PRE_ROUTING to track packets
+			hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules
+			protocol modules (currently TCP/UDP/ICMP)
+			application helpers currently (FTP,IRC,H.323,talk,SNMP)
+		divides packets in the following four categories
+			NEW - would establish new connection
+			ESTABLISHED - part of already established connection
+			RELATED - is related to established connection
+			INVALID - (multicast, errors...)
+		does _NOT_ filter packets itself
+		can be utilized by iptables using the 'state' match 
+		is used by NAT Subsystem
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Network Address Translation
+
+Overview
+
+		Previous Linux Kernels only implemented one special case of NAT: Masquerading
+		Linux 2.4.x can do any kind of NAT.
+		NAT subsystem implemented on top of netfilter, iptables and conntrack
+		NAT subsystem registers with all five netfilter hooks
+		'nat' Table registers chains PREROUTING, POSTROUTING and OUTPUT
+		Following targets available within 'nat' Table
+			SNAT changes the packet's source whille passing NF_IP_POST_ROUTING
+			DNAT changes the packet's destination while passing NF_IP_PRE_ROUTING
+			MASQUERADE is a special case of SNAT
+			REDIRECT is a special case of DNAT
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Network Address Translation
+
+	Source NAT
+		SNAT Example:
+%font "typewriter"
+%size 3
+iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -s 10.0.0.0/8
+%font "standard"
+%size 4
+
+		MASQUERADE Example:
+%font "typewriter"
+%size 3
+iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0
+%font "standard"
+%size 5
+
+	Destination NAT
+		DNAT example
+%font "typewriter"
+%size 3
+iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -p tcp --dport 80 -i eth1
+%font "standard"
+%size 4
+
+		REDIRECT example
+%font "typewriter"
+%size 3
+iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80
+%font "standard"
+%size 5
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Packet Mangling
+
+	Purpose of mangle table
+		packet manipulation except address manipulation
+
+	Integration with netfilter
+		'mangle' table hooks in all five netfilter hooks
+		priority: after conntrack
+
+	Targets specific to the 'mangle' table:
+		DSCP - manipulate DSCP field
+		IPV4OPTSSTRIP - strip IPv4 options
+		MARK - change the nfmark field of the skb
+		TCPMSS - set TCP MSS option
+		TOS - manipulate the TOS bits 
+		TTL - set / increase / decrease TTL field
+
+Simple example:
+%font "typewriter"
+%size 3
+iptables -t mangle -A PREROUTING -j MARK --set-mark 10 -p tcp --dport 80
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Advanced Netfilter concepts
+
+%size 4
+	Userspace logging
+		flexible replacement for old syslog-based logging
+		packets to userspace via multicast netlink sockets
+		easy-to-use library (libipulog)
+		plugin-extensible userspace logging daemon (ulogd)
+		Can even be used to directly log into MySQL
+
+	Queuing
+		reliable asynchronous packet handling 
+		packets to userspace via unicast netlink socket
+		easy-to-use library (libipq)
+		provides Perl bindings
+		experimental queue multiplex daemon (ipqmpd)
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Current Development and Future
+
+Netfilter (although it proved very stable) is still work in progress. 
+
+	Areas of current development
+		infrastructure for conntrack manipulation from userspace
+		failover of stateful firewalls
+		making iptables layer3 independent (pkttables)
+		new userspace library (libiptables) to hide plugins from apps
+		more matches and targets for advanced functions (pool, hashslot)
+		more conntrack and NAT modules (RPC, SNMP, SMB, ...)
+		better IPv6 support (conntrack, more matches / targets)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Thanks
+
+	Thanks to
+		the BBS people, Z-Netz, FIDO, ...
+			for heavily increasing my computer usage in 1992
+
+		KNF
+			for bringing me in touch with the internet as early as 1994
+			for providing a playground for technical people
+			for telling me about the existance of Linux!
+
+		Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen
+			for implementing (one of?) the world's best TCP/IP stacks
+
+		Paul 'Rusty' Russell
+			for starting the netfilter/iptables project
+			for trusting me to maintain it today
+
+		Astaro AG
+			for sponsoring parts of my netfilter work
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Availability of slides / Links
+
+The slides and the an according paper of this presentation are available at 
+	http://www.gnumonks.org/
+
+The netfilter homepage
+	http://www.netfilter.org/
+
diff --git a/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.tex b/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.tex
new file mode 100644
index 0000000..c3a28ea
--- /dev/null
+++ b/2002/netfilter-internals-lt2002/netfilter-internals-lt2002.tex
@@ -0,0 +1,537 @@
+\documentclass{article}
+\usepackage{german}
+\usepackage{fancyheadings}
+\usepackage{a4}
+
+\setlength{\oddsidemargin}{0in}
+\setlength{\evensidemargin}{0in}
+\setlength{\topmargin}{0.0in}
+\setlength{\headheight}{0in}
+\setlength{\headsep}{0in}
+\setlength{\textwidth}{6.5in}
+\setlength{\textheight}{9.5in}
+\setlength{\parindent}{0in}
+\setlength{\parskip}{0.05in}
+
+
+\begin{document}
+\title{Linux 2.4.x netfilter/iptables firewalling internals}
+
+\author{Harald Welte\\
+        laforge@gnumonks.org\\
+	\copyright{}2002 H. Welte}
+
+\date{25. April 2002}
+
+\maketitle
+
+\setcounter{section}{0}
+\setcounter{subsection}{0}
+\setcounter{subsubsection}{0}
+
+\section{Introduction}
+The Linux 2.4.x kernel series has introduced a totally new kernel firewalling
+subsystem.  It is much more than a plain successor of ipfwadm or ipchains.
+
+The netfilter/iptables project has a very modular design and it's
+sub-projects can be split in several parts: netfilter, iptables, connection
+tracking, NAT and packet mangling.
+
+While most users will already have learned how to use the basic functions
+of netfilter/iptables in order to convert their old ipchains firewalls to
+iptables, there's more advanced but less used functionality in
+netfilter/iptables.
+
+The presentation covers the design principles behind the netfilter/iptables
+implementation.  This knowledge enables us to understand how the individual
+parts of netfilter/iptables fit together, and for which potential applications
+this is useful.
+
+\section{Internal netfilter/iptables architecture}
+
+\subsection{Netfilter hooks in protocol stacks}
+
+One of the major motivations behind the redesign of the linux packet
+filtering and NAT system during the 2.3.x kernel series was the widespread
+firewall specific code parts within the core IPv4 stack.  Ideally the core
+IPv4 stack (as used by regular hosts and routers) shouldn't contain any
+firewalling specific code, resulting in no unwanted interaction and less
+code complexity.  This desire lead to the invention of {\it netfilter}.
+
+\subsubsection{Architecture of netfilter}
+
+Netfilter is basically a system of callback functions within the network
+stack.  It provides a non-portable API towards in-kernel networking
+extensions.
+  
+What we call {\it netfilter hook} is a well-defined call-out point within a
+layer three protocol stack, such as IPv4, IPv6 or DECnet.  Any layer three
+network stack can define an arbitrary number of hooks, usually placed at
+strategic points within the packet flow.
+
+Any other kernel code can now subsequently register callback functions for
+any of these hooks.  As in most sytems will be more than one callback
+function registered for a particular hook, a {\it priority} is specified upon
+registration of the callback function.  This priority defines the order in
+which the individual callback functions at a particular hook are called.
+
+The return value of any registered callback functions can be:
+\begin{itemize}
+\item
+{\bf NF\_ACCEPT}: continue traversal as usual
+\item
+{\bf NF\_DROP}: drop the packet; do not continue traversal
+\item
+{\bf NF\_STOLEN}: callback function has taken over the packet; do not continue
+\item
+{\bf NF\_QUEUE}: enqueue the packet to userspace
+\item
+{\bf NF\_REPEAT}: call this hook again
+\end{itemize}
+
+\subsubsection{Netfilter hooks within IPv4}
+
+The IPv4 stack provides five netfilter hooks, which are placed at the
+following peculiar places within the code:
+
+\begin{verbatim}
+   --->[1]--->[ROUTE]--->[3]--->[4]--->
+                 |            ^
+                 |            |
+                 |         [ROUTE]
+                 v            |
+                [2]          [5]
+                 |            ^
+                 |            |
+                 v            |
+
+                local processes
+\end{verbatim}
+
+Packets received on any network interface arrive at the left side of the
+diagram.  After the verification of the IP header checksum, the
+NF\_IP\_PRE\_ROUTING [1] hook is traversed.  
+
+If they ``survive'' (i.e.  NF\_ACCEPT is returned), the packet enters the
+routing code.  Where we continue from here depends on the destintion of the
+packet.
+
+Packets with a local destination (i.e. packets where the destination address is
+one of the own IP addresses of the host) traverse the NF\_IP\_LOCAL\_IN [2]
+hook.  If all callback function return NF\_ACCEPT, the packet is finally passed
+to the socket code, which eventually passes the packet to a local process.
+
+Packets with a remote destination (i.e. packets which are forwarded by the
+local machine) traverse the NF\_IP\_FORWARD [3] hook.  If they ``survive'',
+they finally pass the NF\_IP\_POST\_ROUTING [4] hook and are sent off the
+outgoing network interface.
+
+Locally generated packets first traverse the NF\_IP\_LOCAL\_OUT [5] hook, then
+enter the routing code, and finally go through the NF\_IP\_POST\_ROUTING [4]
+hook before being sent off the outgoing network interface.
+
+\subsubsection{Netfilter hooks within IPv6}
+
+As the IPv4 and IPv6 protocols are very similar, the netfilter hooks within the
+IPv6 stack are placed at exactly the same locations as in the IPv4 stack.  The
+only change are the hook names: NF\_IP6\_PRE\_ROUTING, NF\_IP6\_LOCAL\_IN,
+NF\_IP6\_FORWARD, NF\_IP6\_POST\_ROUTING, NF\_IP6\_LOCAL\_OUT.
+
+\subsubsection{Netfilter hooks within DECnet}
+
+There are seven decnet hooks.  The first five hooks (NF\_DN\_PRE\_ROUTING,
+NF\_DN\_LOCAL\_IN, NF\_DN\_FORWARD, NF\_DN\_LOCAL\_OUT, NF\_DN\_POST\_ROUTING)
+are prretty much the same as in IPv4.  The last two hooks (NF\_DN\_HELLO,
+NF\_DN\_ROUTE) are used in conjunction with DECnet Hello and Routing packets.
+
+\subsubsection{Netfilter hooks within ARP}
+
+Recent kernels\footnote{IIRC, starting with 2.4.19-pre3} have added support for netfilter hooks within the ARP code.
+There are two hooks: NF\_ARP\_IN and NF\_ARP\_OUT, for incoming and outgoing
+ARP packets respectively.
+
+\subsubsection{Netfilter hooks within IPX}
+
+There have been experimental patches to add netfilter hooks to the IPX code,
+but they never got integrated into the kernel source.
+
+\subsection{Packet selection using IP Tables}
+
+The IP tables core (ip\_tables.o) provides a generic layer for evaluation
+of rulesets.  
+
+An IP table consists out of an arbitrary number of {\it chains}, which in turn
+consist out of a linear list of {\it rules}, which again consist out of any
+number of {\it matches} and one {\it target}.
+
+{\it Chains} can further be devided into two classes: Either {\it builtin
+chains} or {\it user-defined chains}.  Builtin chains are always present, they
+are created upon table registration.  They are also the entry points for table
+iteration.  User defined chains are created at runtime upon user interaction.
+
+{\it Matches} specify the matching criteria, there can be zero or more matches
+
+{\it Targets} specify the action which is to be executed in case {\bf all}
+matches match.  There can only be a single target per rule.
+
+Matches and targets can either be {\it builtin} or {\it linux kernel modules}.
+
+There are two special targets:
+\begin{itemize}
+\item
+By using a chain name as target, it is possible to jump to the respective chain
+in case the matches match.
+\item
+By using the RETURN target, it is possible to return to the previous (calling)
+chain
+\end{itemize}
+
+The IP tables core handles the following functions
+\begin{itemize}
+\item
+Registering and unregistering tables
+\item
+Registering and unregistering matches and targets (can be implemented as linux kernel modules)
+\item
+Kernel / userspace interface for manipulation of IP tables
+\item
+Traversal of IP tables
+\end{itemize}
+
+\subsubsection{Packet filtering unsing the ``filter'' table}
+
+Traditional packet filtering (i.e. the successor to ipfwadm/ipchains) takes
+place in the ``filter'' table.  Packet filtering works like a sieve: A packet
+is (in the end) either dropped or accepted - but never modified.
+
+The ``filter'' table is implemented in the {\it iptable\_filter.o} module
+and contains three builtin chains:
+
+\begin{itemize}
+\item
+{\bf INPUT} attaches to NF\_IP\_LOCAL\_IN
+\item
+{\bf FORWARD} attaches to NF\_IP\_FORWARD
+\item
+{\bf OUTPUT} attaches to NF\_IP\_LOCAL\_OUT
+\end{itemize}
+
+The placement of the chains / hooks is done in such way, that evey concievable
+packet always traverses only one of the built-in chains.  Packets destined for
+the local host traverse only INPUT, packets forwarded only FORWARD and
+locally-originated packets only OUTPUT.
+
+\subsubsection{Packet mangling using the ``mangle'' table} 
+
+As stated above, operations which would modify a packet do not belong in the
+``filter'' table.   The ``mangle'' table is available for all kinds of packet
+manipulation - but not manipulation of addresses (which is NAT).
+
+The mangle table attaches to all five netfilter hooks and provides the
+respectiva builtin chains (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING)
+\footnote{This has changed through recent 2.4.x kernel series, old kernels may
+only support three (PREROUTING, POSTROUTING, OUTPUT) chains.}.
+
+\subsection{Connection Tracking Subsystem}
+
+Traditional packet filters can only match on matching criteria within the
+currently processed packet, like source/destination IP address, port numbers,
+TCP flags, etc.  As most applications have a notion of connections or at least
+a request/response style protocol, there is a lot of information which can not
+be derived from looking at a single packet.
+
+Thus, modern (stateful) packet filters attempt to track connections (flows)
+and their respective protocol states for all traffic through the packet
+filter.
+
+Connection tracking within linux is implemented as a netfilter module, called
+ip\_conntrack.o.  
+
+Before describing the connection tracking subsystem, we need to describe a couple of definitions and primitives used throughout the conntrack code.
+
+A connection is represented within the conntrack subsystem using {\it struct
+ip\_conntrack}, also called {\it connection tracking entry}.
+
+Connection tracking is utilizing {\it conntrack tuples}, which are tuples
+consisting out of (srcip, srcport, dstip, dstport, l4prot).  A connection is
+uniquely identified by two tuples:  The tuple in the original direction
+(IP\_CT\_DIR\_ORIGINAL) and the tuple for the reply direction
+(IP\_CT\_DIR\_REPLY).
+
+Connection tracking itself does not drop packets\footnote{well, in some rare
+cases in combination with NAT it needs to drop. But don't tell anyone, this is
+secret.} or impose any policy.  It just associates every packet with a
+connection tracking entry, which in turn has a particular state.  All other
+kernel code can use this state information\footnote{state information is
+internally represented via the {\it struct sk\_buff.nfct} structure member of a
+packet.}.
+
+\subsubsection{Integration of conntrack with netfilter} 
+
+If the ip\_conntrack.o module is registered with netfilter, it attaches to the
+NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING, NF\_IP\_LOCAL\_IN and
+NF\_IP\_LOCAL\_OUT hooks.
+
+Because forwarded packets are the most common case on firewalls, I will only
+describe how connection tracking works for forwarded packets.  The two relevant
+hooks for forwarded packets are NF\_IP\_PRE\_ROUTING and NF\_IP\_POST\_ROUTING.
+
+Every time a packet arrives at the NF\_IP\_PRE\_ROUTING hook, connection
+tracking creates a conntrack tuple from the packet.  It then compares this
+tuple to the original and reply tuples of all already-seen connections
+\footnote{Of course this is not implemented as a linear search over all existing connections.} to find out if this just-arrived packet belongs to any existing
+connection.  If there is no match, a new conntrack table entry (struct
+ip\_conntrack) is created.
+
+Let's assume the case where we have already existing connections but are
+starting from scratch.
+
+The first packet comes in, we derive the tuple from the packet headers, look up
+the conntrack hash table, don't find any matching entry.  As a result, we
+create a new struct ip\_conntrack.  This struct ip\_conntrack is filled with
+all necessarry data, like the original and reply tuple of the connection.
+How do we know the reply tuple?  By inverting the source and destination
+parts of the original tuple.\footnote{So why do we need two tuples, if they can
+be derived from each other?  Wait until we discuss NAT.}
+Please note that this new struct ip\_conntrack is {\bf not} yet placed
+into the conntrack hash table.
+
+The packet is now passed on to other callback functions which have registered
+with a lower priority at NF\_IP\_PRE\_ROUTING.  It then continues traversal of
+the network stack as usual, including all respective netfilter hooks.
+
+If the packet survives (i.e. is not dropped by the routing code, network stack,
+firewall ruleset, ...), it re-appears at NF\_IP\_POST\_ROUTING.  In this case,
+we can now safely assume that this packet will be sent off on the outgoing
+interface, and thus put the connection tracking entry which we created at
+NF\_IP\_PRE\_ROUTING into the conntrack hash table.  This process is called
+{\it confirming the conntrack}.
+
+The connection tracking code itself is not monolithic, but consists out of a
+couple of seperate modules\footnote{They don't actually have to be seperate
+kernel modules; e.g. TCP, UDP and ICMP tracking modules are all part of
+the linux kernel module ip\_conntrack.o}.  Besides the conntrack core, there
+are two important kind of modules: Protocol helpers and application helpers.
+
+Protocol helpers implement the layer-4-protocol specific parts.  They currently
+exist for TCP, UDP and ICMP (an experimental helper for GRE exists).
+
+\subsubsection{TCP connection tracking}
+
+As TCP is a connection oriented protocol, it is not very difficult to imagine
+how conntection tracking for this protocol could work.  There are well-defined
+state transitions possible, and conntrack can decide which state transitions
+are valid within the TCP specification.  In reality it's not all that easy,
+since we cannot assume that all packets that pass the packet filter actually
+arrive at the receiving end, ...
+
+It is noteworthy that the standard connection tracking code does {\bf not}
+do TCP sequence number and window tracking.  A well-maintained patch to add
+this feature exists almost as long as connection tracking itself.  It will
+be integrated with the 2.5.x kernel.  The problem with window tracking is
+it's bad interaction with connection pickup.  The TCP conntrack code is able to
+pick up already existing connections, e.g. in case your firewall was rebooted.
+However, connection pickup is conflicting with TCP window tracking:  The TCP
+window scaling option is only transferred at connection setup time, and we
+don't know about it in case of pickup...
+
+\subsubsection{ICMP tracking}
+
+ICMP is not really a connection oriented protocol.  So how is it possible to
+do connection tracking for ICMP?
+
+The ICMP protocol can be split in two groups of messages
+
+\begin{itemize}
+\item
+ICMP error messages, which sort-of belong to a different connection
+ICMP error messages are associated {\it RELATED} to a different connection.
+(ICMP\_DEST\_UNREACH, ICMP\_SOURCE\_QUENCH, ICMP\_TIME\_EXCEEDED,
+ICMP\_PARAMETERPROB, ICMP\_REDIRECT). 
+\item
+ICMP queries, which have a request->reply character.  So what the conntrack
+code does, is let the request have a state of {\it NEW}, and the reply 
+{\it ESTABLISHED}.  The reply closes the connection immediately.
+(ICMP\_ECHO, ICMP\_TIMESTAMP, ICMP\_INFO\_REQUEST, ICMP\_ADDRESS)
+\end{itemize}
+
+\subsubsection{UDP connection tracking}
+
+UDP is designed as a connectionless datagram protocol. But most common
+protocols using UDP as layer 4 protocol have bi-directional UDP communication.
+Imagine a DNS query, where the client sends an UDP frame to port 53 of the
+nameserver, and the nameserver sends back a DNS reply packet from it's  UDP
+port 53 to the client.
+
+Netfilter trats this as a connection. The first packet (the DNS request) is
+assigned a state of {\it NEW}, because the packet is expected to create a new
+'connection'. The dns servers' reply packet is marked as {\it ESTABLISHED}.
+
+\subsubsection{conntrack application helpers}
+
+More complex application protocols involving multiple connections need special
+support by a so-called ``conntrack application helper module''.  Modules in
+the stock kernel come for FTP and IRC(DCC).  Netfilter CVS currently contains
+patches for PPTP, H.323, Eggdrop botnet, tftp ald talk.  We're still lacking
+a lot of protocols (e.g. SIP, SMB/CIFS) - but they are unlikely to appear
+until somebody really needs them and either develops them on his own or
+funds development.
+
+\subsubsection{Integration of connection tracking with iptables}
+
+As stated earlier, conntrack doesn't impose any policy on packets.  It just
+determines the relation of a packet to already existing connections.  To base
+packet filtering decision on this sate information, the iptables {\it state}
+match can be used.  Every packet is within one of the following categories:
+
+\begin{itemize}
+\item
+{\bf NEW}: packet would create a new connection, if it survives
+\item
+{\bf ESTABLISHED}: packet is part of an already established connection 
+(either direction)
+\item
+{\bf RELATED}: packet is in some way related to an already established connection, e.g. ICMP errors or FTP data sessions
+\item
+{\bf INVALID}: conntrack is unable to derive conntrack information from this packet.  Please note that all multicast or broadcast packets fall in this category.
+\end{itemize}
+
+\subsection{NAT Subsystem}
+
+The NAT (Network Address Translation)  subsystem is probably the worst
+documented subsystem within the whole framework.  This has two reasons:  NAT is
+nasty and complicated.  The Linux 2.4.x NAT implementation is easy to use, so
+nobody needs to know the nasty details.
+
+Nonetheless, as I was traditionally concentrating most on the conntrack and NAT
+systems, I will give a short overview.
+
+NAT uses almost all of the previously described subsystems:
+\begin{itemize}
+\item
+IP tables to specify which packets to NAT in which particular way. NAT
+registers a ``nat'' table with PREROUTING, POSTROUTING and OUTPUT chains. 
+\item
+Connection tracking to associate NAT state with the connection.
+\item
+Netfilter to do the actuall packet manipulation transparent to the rest of the
+kernel.  NAT registers with NF\_IP\_PRE\_ROUTING, NF\_IP\_POST\_ROUTING,
+NF\_IP\_LOCAL\_IN and NF\_IP\_LOCAL\_OUT.
+\end{itemize}
+
+The NAT implementation supports all kinds of different nat; Source NAT,
+Destination NAT, NAT to address/port ranges, 1:1 NAT, ...
+
+This fundamental design principle is still frequently misunderstood:\\
+The information about which NAT mappings apply to a certain connection
+is only gathered once - with the first packet of every connection.
+
+So let's start to look at the life of a poor to-be-nat'ed packet.
+For ease of understanding, I have chosen to describe the most frequently
+used NAT scenario:  Source NAT of a forwarded packet.  Let's assume the
+packet has an original source address of 1.1.1.1, an original destination
+address of 2.2.2.2, and is going to be SNAT'ed to 9.9.9.9.  Let's further
+ignore the fact that there are port numbers.
+
+Once upon a time, our poor packet arrives at NF\_IP\_PRE\_ROUTING, where
+conntrack has registered with highest priority.  This means that a conntrack
+entry with the following two tuples is created:
+\begin{verbatim}
+IP_CT_DIR_ORIGINAL: 1.1.1.1 -> 2.2.2.2
+IP_CT_DIR_REPLY: 2.2.2.2 -> 1.1.1.1
+\end{verbatim}
+After conntrack, the packet traverses the PREROUTING chain of the ``nat''
+IP table.  Since only destination NAT happens at PREROUTING, no action
+occurs.  After it's lengthy way through the rest of the network stack,
+the packet arrives at the NF\_IP\_POST\_ROUTING hook, where it traverses
+the POSTROUTING chain of the ``nat'' table.  Here it hits a SNAT rule,
+causing the following actions:
+\begin{itemize}
+\item
+Fill in a {\it struct ip\_nat\_manip}, indicating the new source address
+and the type of NAT (source NAT at POSTROUTING).  This struct is part of the
+conntrack entry.
+\item
+Automatically derive the inverse NAT transormation for the reply packets:
+Destination NAT at PREROUTING.  Fill in another {\it struct ip\_nat\_manip}.
+\item
+Alter the REPLY tuple of the conntrack entry to
+\begin{verbatim}
+IP_CT_DIR_REPLY: 2.2.2.2 -> 9.9.9.9
+\end{verbatim}
+\item
+Apply the SNAT transformation to the packet
+\end{itemize}
+
+Every other packt within this connection, independent of its direction,
+will only execute the last step.  Since all NAT information is connected
+with the conntrack entry, there is no need to do anything but to apply
+the same transormations to all packets witin the same connection.
+
+\subsection{IPv6 Firewalling with ip6tables}
+
+Yes, Linux 2.4.x comes with a usable, though incomplete system to secure
+your IPv6 network.
+
+The parts ported to IPv6 are
+\begin{itemize}
+\item
+IP tables (called IP6 tables)
+\item
+The ``filter'' table
+\item
+The ``mangle'' table
+\item
+The userspace library (libip6tc)
+\item
+The command line tool (ip6tables)
+\end{itemize}
+
+Due to the lack of conntrack and NAT\footnote{for god's sake we don't have NAT
+with IPv6}, only traditional, stateless packet filtering is possible.  Apart
+from the obvious matches/targets, ip6tables can match on
+\begin{itemize}
+\item
+{\it EUI64 checker}; verifies if the MAC address of the sender is the same as in the EUI64 64 least significant bits of the source IPv6 address
+\item
+{\it frag6 match}, matches on IPv6 fragmentation header
+\item
+{\it route6 match}, matches on IPv6 routing header
+\item
+{\it ahesp6 match}, matches on SPIDs within AH or ESP over IPv6 packets
+\end{itemize}
+
+However, the ip6tables code doesn't seem to be used very widely (yet?). 
+So please expect some potential remaining issues, since it is not tested
+as heavily as iptables.
+
+\subsection{Recent Development}
+
+Please refer to the spoken word at the presentation.  Development at the 
+time this paper was written can be quite different from development at the
+time the presentation is held.
+
+\section{Thanks}
+
+I'd like to thank
+\begin{itemize}
+\item
+{\it Linus Torvalds} for starting this interesting UNIX-like kernel
+\item
+{\it Alan Cox, David Miller, Alexey Kuznetesov, Andi Kleen} for building 
+(one of?) the world's best TCP/IP stacks.
+\item
+{\it Paul ``Rusty'' Russell} for starting the netfilter/iptables project
+\item
+{\it The Netfilter Core Team} for continuing the netfilter/iptables effort
+\item
+{\it Astaro AG} for partially funding my current netfilter/iptables work
+\item
+{\it Conectiva Inc.} for partially funding parts of my past netfilter/iptables
+work and for inviting me to live in Brazil
+\item
+{\it samba.org and Kommunikationsnetz Franken e.V.} for hosting the netfilter
+homepage, CVS, mailing lists, ...
+\end{itemize}
+
+\end{document}
diff --git a/2002/netfilter-knf2002/abstract b/2002/netfilter-knf2002/abstract
new file mode 100644
index 0000000..bf43544
--- /dev/null
+++ b/2002/netfilter-knf2002/abstract
@@ -0,0 +1,50 @@
+Firewalling mit netfilter/iptables unter Linux 2.4.x
+
+Der Linux 2.4.x Kernel bietet eine fortgeschrittene Infrastruktur, genannt
+netfilter, auf deren Basis ein Paketfilter, NAT und sonstige
+Paket-Manipulationen implementiert sind.
+
+Das gesamte Firewalling-Subsystem wurde gegenueber Kernel 2.2.x neu entwickelt.
+Das netfilter/iptables System laesst alles bisher unter Linux existierende
+(ipfwadm, ipchains) wie aus grauer Vorzeit erscheinen.
+
+netfilter/iptables bietet neben dem traditionellen Paketfilter auch optional
+Connection Tracking, mittels dessen sich im Handumdrehen eine Stateful
+Firewall realisieren laesst.  Auch das NAT (Network Address Translation)
+System ist jetzt flexibel genug, um saemtliche Formen von NAT anbieten
+zu koennen: source NAT, destination NAT, static NAT, NAPT, ...
+
+Die hohe Modularitaet resultiert in einer sehr leichten Erweiterbarkeit,
+so dass in einfacher Weise neue Erweiterungen zum Firewalling-System 
+entwickelt werden koennen.
+
+Der Vortrag beschreibt die unterschiedlichen Teile des netfilter/iptables
+Systems und gibt dadurch einen Ueberblick ueber dessen Moeglichkeiten und 
+Anwendungsszenarien.  Er beschaeftigt sich mit den folgenden Themen:
+
+- netfilter/iptables architektur
+	- netfilter hooks im Netzwerk-Stack
+	- IP tables als Regelbeschreibung
+- Paketfilter
+- Connection Tracking
+- Network Address Translation
+	- source NAT
+	- destination NAT
+	- Masquerading
+	- transparent proxy support
+- Packet mangling
+- Userspace packet queuing
+- Userspace packet logging
+
+
+Voraussetzungen:
+- Wissen ueber TCP/IP, Routing
+- Grundlagen ueber Firewalling (insbesondere Paketfilter)
+- Gewisse Grundkenntnisse ueber die Linux/Unix Architektur
+
+
+Ueber den Vortragenden:
+Harald Welte ist seit 1995 aktives KNF-Mitglied und der derzeitige 
+stellvertretende Technische Kontakt des KNF.  Er ist der Maintainer des
+netfilter/iptables Firewalling-Subsystems im Linux 2.4.x und
+2.5.x Kernel und war massgeblich an dessen Entwicklung beteiligt.
diff --git a/2002/netfilter-knf2002/netfilter-knf2002.mgp b/2002/netfilter-knf2002/netfilter-knf2002.mgp
new file mode 100644
index 0000000..4523dd3
--- /dev/null
+++ b/2002/netfilter-knf2002/netfilter-knf2002.mgp
@@ -0,0 +1,466 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+The netfilter/iptables framework in 
+Linux 2.4.x
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@gnumonks.org>
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Contents
+
+
+	Introduction
+	Netfilter hooks in protocol stacks
+	Packet selection based on IP Tables
+	The Connection Tracking Subsystem
+	The NAT Subsystem based on netfilter + iptables 
+	Packet filtering using the 'filter' table
+	Packet mangling using the 'mangle' table
+	Advanced netfilter concepts
+	Current development and Future
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+netfilter/iptables in Linux 2.4
+Introduction
+
+Why did we need netfilter/iptables?
+Because ipchains...
+
+		has no infrastructure for passing packets to userspace
+		makes transparent proxying extremely difficult
+		has interface address dependent Packet filter rules
+		has Masquerading implemented as part of packet filtering
+		code is too complex and intermixed with core ipv4 stack
+		is neither modular nor extensible
+		only barely supports one special case of NAT (masquerading)
+		has only stateless packet filtering
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Introduction 
+
+Who's behind netfilter/iptables
+		Paul 'Rusty' Russel
+			co-author of iptables in Linux 2.2
+			was paid by Watchguard for about one Year of development
+		James Morris
+			userspace queuing (kernel, library and tools)
+			REJECT target
+		Marc Boucher
+			NAT and packet filtering controlled by one command
+			Mangle table
+		Harald Welte 
+			Conntrack+NAT helper infrastructure (newnat)
+			Userspace packet logging (ULOG)
+			PPTP and IRC conntrack/NAT helpers
+		Jozsef Kadlecsik
+			TCP window tracking
+			H.323 conntrack + NAT helper
+			Continued newnat development
+		Non-core team contributors
+			http://www.netfilter.org/scoreboard/
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Netfilter Hooks
+
+What is netfilter?
+
+		System of callback functions within network stack
+		Callback function to be called for every packet traversing certain point (hook) within network stack
+		Protocol independent framework
+		Hooks in layer 3 stacks (IPv4, IPv6, DECnet, ARP)
+		Multiple kernel modules can register with each of the hooks
+		Asynchronous packet handling in userspace (ip_queue)
+
+Traditional packet filtering, NAT, ... is implemented on top of this framework
+
+Can be used for other stuff interfacing with the core network stack, like DECnet routing daemon.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Netfilter Hooks
+
+Netfilter architecture in IPv4
+%font "courier"
+
+   --->[1]--->[ROUTE]--->[3]--->[4]--->
+                 |            ^
+                 |            |
+                 |         [ROUTE]
+                 v            |
+                [2]          [5]
+                 |            ^
+                 |            |
+                 v            |
+
+%font "standard"
+1=NF_IP_PRE_ROUTING
+2=NF_IP_LOCAL_IN
+3=NF_IP_FORWARD
+4=NF_IP_POST_ROUTING
+5=NF_IP_LOCAL_OUT
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Netfilter Hooks
+
+Netfilter Hooks
+
+	Any kernel module may register a callback function at any of the hooks
+
+	The module has to return one of the following constants
+
+		NF_ACCEPT	 continue traversal as normal
+		NF_DROP		 drop the packet, do not continue
+		NF_STOLEN	 I've taken over the packet do not continue
+		NF_QUEUE	 enqueue packet to userspace
+		NF_REPEAT	 call this hook again
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP tables
+
+Packet selection using IP tables
+
+		The kernel provides generic IP tables support
+
+		Each kernel module may create it's own IP table
+
+		The three major parts of 2.4 firewalling subsystem are implemented using IP tables
+			Packet filtering table 'filter'
+			NAT table 'nat'
+			Packet mangling table 'mangle'
+
+		Can potentially be used for other stuff, i.e. IPsec SPDB
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Managing chains and tables
+
+	An IP table consists out of multiple chains
+	A chain consists out of a list of rules
+	Every single rule in a chain consists out of
+		match[es] (rule executed if all matches true)
+		target (what to do if the rule is matched)
+
+%size 4
+matches and targets can either be builtin or implemented as kernel modules
+
+%size 6
+	The userspace tool iptables is used to control IP tables
+		handles all different kinds of IP tables 
+		supports a plugin/shlib interface for target/match specific options
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Basic iptables commands
+
+	To build a complete iptables command, we must specify
+		which table to work with
+		which chain in this table to use
+		an operation (insert, add, delete, modify)
+		one or more matches (optional)
+		a target
+
+The syntax is
+%font "typewriter"
+%size 3
+iptables -t table -Operation chain -j target match(es)
+%font "standard"
+%size 5
+
+Example:
+%font "typewriter"
+%size 3
+iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp
+%font "standard"
+%size 5
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Matches
+		Basic matches
+			-p			protocol (tcp/udp/icmp/...)
+			-s			source address (ip/mask)
+			-d			destination address (ip/mask)
+			-i			incoming interface
+			-o			outgoing interface
+
+		Match extensions (examples)
+			tcp/udp		TCP/udp source/destination port
+			icmp			ICMP code/type
+			ah/esp		AH/ESP SPID match
+			mac		 	source MAC address
+			mark 		nfmark
+			length		match on length of packet
+			limit			rate limiting (n packets per timeframe)
+			owner	 	owner uid of the socket sending the packet
+			tos			TOS field of IP header
+			ttl			TTL field of IP header
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+IP Tables
+
+Targets 
+	very dependent on the particular table.
+
+	Table specific targets will be discussed later
+
+	Generic Targets, always available
+		ACCEPT		accept packet within chain
+		DROP		silently drop packet
+		QUEUE		enqueue packet to userspace
+		LOG		log packet via syslog
+		ULOG		log packet via ulogd
+		RETURN		return to previous (calling) chain
+		foobar		jump to user defined chain
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+netfilter/iptables in Linux 2.4
+Packet Filtering
+
+Overview
+
+	Implemented as 'filter' table
+	Registers with three netfilter hooks
+
+		NF_IP_LOCAL_IN (packets destined for the local host)
+		NF_IP_FORWARD (packets forwarded by local host)
+		NF_IP_LOCAL_OUT (packets from the local host)
+
+Each of the three hooks has attached one chain (INPUT, FORWARD, OUTPUT)
+
+Every packet passes exactly one of the three chains. Note that this is very different compared to the old 2.2.x ipchains behaviour.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Packet Filtering
+
+Targets available within 'filter' table
+
+	Builtin Targets to be used in filter table
+		ACCEPT	accept the packet
+		DROP	silently drop the packet 
+		QUEUE	enqueue packet to userspace
+		RETURN	return to previous (calling) chain
+		foobar	user defined chain
+
+	Targets implemented as loadable modules 
+		REJECT	drop the packet but inform sender
+		MIRROR	change source/destination IP and resend
+		LOG  	log via syslog
+		ULOG	log via userspace
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Connection Tracking Subsystem
+
+	Connection tracking...
+
+		implemented seperately from NAT 
+		enables stateful filtering 
+		implementation
+			hooks into NF_IP_PRE_ROUTING to track packets
+			hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules
+			protocol modules (currently TCP/UDP/ICMP)
+			application helpers currently (FTP,IRC,H.323,talk,SNMP)
+		divides packets in the following four categories
+			NEW - would establish new connection
+			ESTABLISHED - part of already established connection
+			RELATED - is related to established connection
+			INVALID - (multicast, errors...)
+		does _NOT_ filter packets itself
+		can be utilized by iptables using the 'state' match 
+		is used by NAT Subsystem
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Network Address Translation
+
+Overview
+
+		Previous Linux Kernels only implemented one special case of NAT: Masquerading
+		Linux 2.4.x can do any kind of NAT.
+		NAT subsystem implemented on top of netfilter, iptables and conntrack
+		NAT subsystem registers with all five netfilter hooks
+		'nat' Table registers chains PREROUTING, POSTROUTING and OUTPUT
+		Following targets available within 'nat' Table
+			SNAT changes the packet's source whille passing NF_IP_POST_ROUTING
+			DNAT changes the packet's destination while passing NF_IP_PRE_ROUTING
+			MASQUERADE is a special case of SNAT
+			REDIRECT is a special case of DNAT
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Network Address Translation
+
+	Source NAT
+		SNAT Example:
+%font "typewriter"
+%size 3
+iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -s 10.0.0.0/8
+%font "standard"
+%size 4
+
+		MASQUERADE Example:
+%font "typewriter"
+%size 3
+iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0
+%font "standard"
+%size 5
+
+	Destination NAT
+		DNAT example
+%font "typewriter"
+%size 3
+iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -p tcp --dport 80 -i eth1
+%font "standard"
+%size 4
+
+		REDIRECT example
+%font "typewriter"
+%size 3
+iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80
+%font "standard"
+%size 5
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Packet Mangling
+
+	Purpose of mangle table
+		packet manipulation except address manipulation
+
+	Integration with netfilter
+		'mangle' table hooks in all five netfilter hooks
+		priority: after conntrack
+
+	Targets specific to the 'mangle' table:
+		DSCP - manipulate DSCP field
+		IPV4OPTSSTRIP - strip IPv4 options
+		MARK - change the nfmark field of the skb
+		TCPMSS - set TCP MSS option
+		TOS - manipulate the TOS bits 
+		TTL - set / increase / decrease TTL field
+
+Simple example:
+%font "typewriter"
+%size 3
+iptables -t mangle -A PREROUTING -j MARK --set-mark 10 -p tcp --dport 80
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Advanced Netfilter concepts
+
+%size 4
+	Userspace logging
+		flexible replacement for old syslog-based logging
+		packets to userspace via multicast netlink sockets
+		easy-to-use library (libipulog)
+		plugin-extensible userspace logging daemon (ulogd)
+		Can even be used to directly log into MySQL
+
+	Queuing
+		reliable asynchronous packet handling 
+		packets to userspace via unicast netlink socket
+		easy-to-use library (libipq)
+		provides Perl bindings
+		experimental queue multiplex daemon (ipqmpd)
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Current Development and Future
+
+Netfilter (although it proved very stable) is still work in progress. 
+
+	Areas of current development
+		infrastructure for conntrack manipulation from userspace
+		failover of stateful firewalls
+		making iptables layer3 independent (pkttables)
+		new userspace library (libiptables) to hide plugins from apps
+		more matches and targets for advanced functions (pool, hashslot)
+		more conntrack and NAT modules (RPC, SNMP, SMB, ...)
+		better IPv6 support (conntrack, more matches / targets)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Thanks
+
+	Thanks to
+		the BBS people, Z-Netz, FIDO, ...
+			for heavily increasing my computer usage in 1992
+
+		KNF
+			for bringing me in touch with the internet as early as 1995
+			for providing a playground for technical people
+			for telling me about the existance of Linux!
+
+		Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen
+			for implementing (one of?) the world's best TCP/IP stacks
+
+		Paul 'Rusty' Russell
+			for starting the netfilter/iptables project
+			for trusting me to maintain it today
+
+		Linux User Group Nuernberg (ALIGN, LUG-N)
+			for helping me with my initial Linux problems
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+netfilter/iptables in Linux 2.4
+Availability of slides / Links
+
+The slides and the an according paper of this presentation are available at 
+	http://www.gnumonks.org/
+
+The netfilter homepage
+	http://www.netfilter.org/
+
diff --git a/2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp b/2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp
new file mode 100644
index 0000000..c98ba30
--- /dev/null
+++ b/2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp
@@ -0,0 +1,201 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%
+%deffont "typewriter" tfont "MONOTYPE.TTF"
+
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+TCP state + windowtracking
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@gnumonks.org>
+
+
+%page
+TCP state + window tracking
+What? Why?
+
+
+	TCP is a stateful protocol, each endpoint is a state machine
+
+	What is TCP state / windowtracking?
+		Some intermediate System (Router/Firewall) is trying to derive the current state of the two TCP endpoints
+
+	Why does somebody want TCP state / windowtracking
+		Evaluation of TCP stack implementations
+		Hide/Protect broken implementations from a public network
+
+
+%page
+TCP state + windowtracking
+TCP basics
+
+	states of a TCP endpoint:
+		LISTEN: port waiting for connection request from remote end
+		SYN_SENT: we've sent a SYN packet and not received anything yet
+		SYN_RECEIVED: We've received a SYN in reply to our SYN
+		ESTABLISHED: fully established TCP connection
+		FIN_WAIT1: waiting for FIN from remote end or ACK of sent FIN
+		FIN_WAIT2 waiting for FIN from remote end
+		TIME_WAIT: waiting for enough time to pass to be sure the remote end received the ACK of its FIN
+		CLOSED: no connection state at all
+		CLOSE_WAIT: waiting for a connection termination request from local user
+		CLOSING: waiting for a connection termination request acknowledgement from the remote end
+		LAST_ACK: Waiting for ACK of the FIN previously sent to remote end
+
+%page
+TCP state + windowtracking
+TCP basics
+
+	sequence numbers
+		every octet has a corrsponding sequence number
+		sequence number is increased by one for every payload octet sent
+		receiver acknowledges last received contiguous sequence number (cumulative ack)
+		EXTENSION: selective acknowledgement (SACK) option, RFC2018
+			receiver can specify seperate sequencenumber blocks it has received
+
+	sliding window protocol
+		receiver advertises the size of the receive window
+		sender can only send up to 'window' number of octets which are not ACK'ed yet
+		EXTENSION: window scaling, RFC1323
+			window size of 16bit is too small for high bandwith links, thus window scaling was introduced
+
+%page
+TCP state + windowtracking
+TCP state tracking
+
+	Where do we do TCP state tracking?
+		state tracker needs to see _all_ packets in both directions
+		problems with asymmetric routing!
+
+	So where's the Problem?
+		IP is an unreliable, best-effort protocol
+		If man in the middle does observe a packet, he can make no assumption on whether it actually arrives at the receiver.
+
+%page
+TCP state + window tracking
+Problems
+
+
+	Example scenario 1
+		A sends SYN to B
+			man in the middle saves state as SYN_SENT
+		B sends SYN/ACK to A
+			man in the middle detects state transition to SYN_RECEIVED
+		SYN/ACK doesn't arrive at A
+		somebody spoofs ACK A->B to firewall
+			man in the middle detects state transition to ESTABLISHED
+		==> Any traffic between A and B will be accepted (wrong!)
+
+%page
+TCP state + window tracking
+Problems
+
+
+	Example scenario 2
+		fully established TCP connection
+		A sends FIN to B
+			man in the middle saves state to FIN_WAIT1
+		B sends FIN/ACK to A
+			man in the middle saves state CLOSING/TIME_WAIT
+		FIN/ACK doesn't arrive at A
+		B retransmits FIN/ACK to A
+			man in the middle doesn't accept any further packets
+		.oO(booom)Oo.
+
+%page
+TCP state + window tracking
+Problems
+
+
+	Example scenario 3 (FIN/RST spoofing without windowtracking)
+		fully established TCP connection
+		evil guy spoofs FIN A->B (with guessed sequence number
+			man in the middle saves satet as FIN_WAIT1
+		B ignores FIN/ACK because of wrong sequence number
+		A sends further segments to B
+			man in the middle doesn't accept further segments after FIN was sent in this direction
+		.oO(booom)Oo.
+
+	Solution: Real Window tracking
+		See paper by Guido van Rooj
+
+
+%page
+TCP state + window tracking
+Further Problems
+
+
+	pickup of already established connections
+		window scaling sucks in this case
+		window tracking has to be disabled in that case
+
+	selective acknowledgements
+		man-in-the-middle needs to track all selectively acknowledged segments
+		this can draw lots of resources at the man in the middle and is prone to DoS
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+TCP state + window tracking
+conntrack subsystem of netfilter
+
+Netfilter architecture in IPv4
+%font "typewriter"
+%size 3
+
+   --->[1]--->[ROUTE]--->[3]--->[4]--->
+                 |            ^
+                 |            |
+                 |         [ROUTE]
+                 v            |
+                [2]          [5]
+                 |            ^
+                 |            |
+                 v            |
+
+%font "standard"
+1=NF_IP_PRE_ROUTING
+2=NF_IP_LOCAL_IN
+3=NF_IP_FORWARD
+4=NF_IP_POST_ROUTING
+5=NF_IP_LOCAL_OUT
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+TCP state + window tracking
+conntrack subsystem of netfilter
+
+	Connection tracking...
+
+		implemented seperately from NAT 
+		enables stateful filtering 
+		implementation
+			hooks into NF_IP_PRE_ROUTING to track packets
+			hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules
+			protocol modules (currently TCP/UDP/ICMP)
+			application helpers currently (FTP,IRC,H.323,talk,SNMP)
+		divides packets in the following four categories
+			NEW - would establish new connection
+			ESTABLISHED - part of already established connection
+			RELATED - is related to established connection
+			INVALID - (multicast, errors...)
+		does _NOT_ filter packets itself
+		can be utilized by iptables using the 'state' match 
+		is used by NAT Subsystem
+
+%page
+TCP state + window tracking
+Further Reading
+
+	RFC793,RFC2018,RFC1323: Transmission Control Protocol
+	http://www.netfilter.org/ - netfilter hacking howto contains some info
diff --git a/2002/tex-introduction-cc2002/tex-einfuehrung b/2002/tex-introduction-cc2002/tex-einfuehrung
new file mode 100644
index 0000000..ff5a4ff
--- /dev/null
+++ b/2002/tex-introduction-cc2002/tex-einfuehrung
@@ -0,0 +1,147 @@
+
+0. Einfuehrung / Geschichte
+1. Grundsaetzliches (.tex file, latex, .dvi, dvips, postscript, ...)
+2. wie sieht ein LaTex dokument aus?
+	\documentstyle[german]{article}
+	\pagestyle{empty}
+	\begin{document}
+	..
+	\end{document}
+
+3. Texteingabe
+	- leerzeichen / leerzeilen irrelevant
+	- absatz durch leere zeile oder \par
+	- zeilenumbruch mit \\
+
+Trennvorgaben:
+	- lokal (nur): Donau\-dampf\-schiff
+	- lokal (auch): Donau"-dampf"-schiff
+	- global: \hyphenation{Donau-dampf-schiff}
+	- keine trennung lokal: \mbox{Untrennbar}
+	- keine trennung global: \hyphenation{Untrennbar}
+	- ~ == leerzeichen, bei dem kein zeilenumbruch erfolgen darf
+
+Sonderzeichen:
+	- deutsch: "a "o "u "A "O "U "s
+	- sonstige: \'o \`o \^o \=o \.o \u{o} \v{o} \H{o} \t{oo} \c{c} \d{o}
+	  z.b. C'est \c{c}a!
+	- \$ \& \% \# \{ \} [ ] \_ @ \S \pounds $<$ $>$ $\backslash ?` !`
+
+Striche und Anfuehrungszeichen:
+	- Striche: - -- ---
+	- Anfuehrungszeichen: \glq \grq \glqq \grqq \flq \frq \flqq \frqq
+	  (german left quote, french right quote, ...)
+	  Kurzform: "` "' "> "<
+
+Leerraeume
+	- \hspace{length}
+	- \vspace{length}
+	- \hfill \vfill
+Auslassungszeichen
+	- \ldots{}
+	- \dotfill{}
+	- \vdots
+
+
+Texthervorhebungen
+	- betonen {\em betontes}
+	- unterstreichen \underline{ }
+	- woertlich \verb{text}
+
+Schriftarten:
+	- Roman (\rm)
+	- Fett (\bf)
+	- Kursiv (\it)	(Italic-Korrektur \/)
+	- Slanted (\sl)
+	- Sans Serif (\sf)
+	- Small Caps (\sc)
+	- Typweriter (\tt)
+
+Schriftgroessen:
+	- \tiny
+	- \scriptsize
+	- \footnotesize
+	- \small
+	- \normalsize
+	- \large
+	- \Large
+	- \LARGE
+	- \huge
+	- \Huge
+
+NFSS:
+	- \family{cmr|cmss|cmtt}
+	- \series{ul|el|l|sl|m|sb|b|eb|ub}
+	- \series{uc|ec|c|sc|m|sx|x|ex|ux}
+	- \shape{n|it|sl|sc}
+	- \size{size}{linespacing}
+	- \selectfont
+
+
+Dokumenststruktur
+
+Gliederung:
+
+	- \part{Teilueberschrift} 		\part*
+	- \chapter{Kapitelueberschrift}		\chapter*
+	
+	- \section{Abschnittsueberschrift}
+	- \subsection{}
+	- \subsubsection{}
+	- \paragraph{} [text folgt in gleicher zeile wie ueberschrift]
+	- \subparagraph{}
+
+
+	-  \setcounter{page|part|chapter|section|...}{wert}
+
+Titelseite:
+	- \title{Titel}
+	- \thanks{Danksagung}
+	- \author{Autor}
+	- \date{Datum}
+	- \maketitle
+
+Zusammenfassung:
+	- \begin{abstract} \end{abstract}
+
+Inhaltsverzeichnis:
+	- \tableofcontents
+	- Tiefe des Einbindens: \setcounter{tocdepth}{tiefe}
+	  tiefe:	-1 keine ueberschrift
+	  		 0 chapter
+			 1 chapter und section
+			 2 chapter bis subsection
+			 3 chapter bis subsubsection
+			 4 chapter bis paragraph
+			 5 alle
+
+Dokumentaufbau:
+	- \documentstyle[german, option, ...]{style}
+	  Gaengige styles: article, report, book
+	  Stiloptionen: 10pt,11pt,12pt,twoside,twocolumn,titlepage
+	- \pagestyle{plain|headings|empty|myheadings}
+
+	- \noindent
+	- Zentriert: \begin{center} \end{center}
+	- Links-Rechtsbuendig: \begin{flushleft|flushright}
+	- Zitat: \begin{quotation} \end{quotation}
+	- Gedichtzeilen: \begin{verse} \end{verse}
+	- Woertlich: \begin{verbatim} \end{verbatim}
+	- Randnotiz: \marginpar{Randnotiz}
+	- Fussnote: \footnote{foobaR}
+
+Listen und Aufzaehlungen:
+	- Liste: \begin{itemize} \item \end{itemize}
+	- Aufzaehlung: \begin{enumerate} \item \end{enumerate}
+	- Beschreibung: \begin{description} \item[was] \end{description}
+
+Querverweise:
+	- Ziel des verweises: \label{name}
+	- Verweis: \ref{name}, Seite \pageref{name}
+
+Literaturverzeichnis:
+	- "Wie in \cite[Seiten 12,13]{1} beschrieben..."
+	\begin{thebibliography}{99}
+	\bibitem{1} Markus Mueller, {\sl Mahlzeit - das Kochbuch, Addison-Wesley, 1995}
+	...
+	\end{thebibliography}
diff --git a/2002/tex-introduction-cc2002/tex-einfuehrung.tex b/2002/tex-introduction-cc2002/tex-einfuehrung.tex
new file mode 100644
index 0000000..8e90d0d
--- /dev/null
+++ b/2002/tex-introduction-cc2002/tex-einfuehrung.tex
@@ -0,0 +1,430 @@
+\documentstyle[german,a4]{article}
+\pagestyle{plain}
+
+\setlength{\oddsidemargin}{0in}
+\setlength{\evensidemargin}{0in}
+\setlength{\topmargin}{0.0in}
+\setlength{\headheight}{0in}
+\setlength{\headsep}{0in}
+\setlength{\textwidth}{6.5in}
+\setlength{\textheight}{9.5in}
+\setlength{\parindent}{0in}
+\setlength{\parskip}{0.05in}
+
+\begin{document}
+
+\title{The UNIX way of text processing: \LaTeX}
+\author{Harald Welte $<$laforge@gnumonks.org$>$}
+\maketitle
+
+\begin{abstract}
+Dieses Dokument soll als kleines Begleitschreiben zu meinem Einf"uhrungskurs in
+{\LaTeX} dienen. Vervielf"altigung erlaubt und erw"unscht.
+\end{abstract}
+
+\tableofcontents
+
+\section{Einleitung}
+Viele Anwender arbeiten heute mit sogenannten {\em WYSIWYG}-Textverarbeitungen.
+Dieses relativ neue Konzept erm"oglicht es, ein Textdokument am Bildschirm so
+zu bearbeiten, wie es nachher auch aus dem Drucker herauskommt (zumindest
+Behaupten dies die Hersteller, die Realit"at sieht meist anders aus).
+
+Eine ganz andere Philosophie verfolgen Textsatzsysteme wie \TeX  oder dessen
+Erweiterung {\LaTeX}. Hier wird der Text zun"achst mit einem beliebigen
+Texteditor gescrhieben, wobei bestimmte Befehle und Steuerzeichen eingebettet
+werden.  Anschlie"send wird dann der Textprocessor aufgerufen, der das
+eigentliche Resultat generiert.
+
+Dieser Vorgang erinnert stark an das Programmieren: Der Autor schreibt einen
+Quelltext, welcher mittels eines Compilers in Maschinensprache "ubersetzt wird.
+Diese Analogie ist kein Zufall, wurde TeX doch von {\em Donald E. Knuth}, einem
+der renommiertesten Informatikern "ubehaupt, geschrieben.  Knuth hat neben zwei
+Professuren unter anderem auch 27 Ehrendoktortitel und zahlreiche Ehrungen
+Namhafter Institutionen. 
+
+Knuth schreibt seit Jahrzehnten ma"sgebliche Referenzwerke der Informatik, so
+z.B. die mehrteilige Reihe {\em The Art of Programming}.  Um seine B"ucher
+vern"unftig schreiben zu k"onnen, hat Knuth keine befriedigende Software
+gefunden, und hat so kurzerhand selbst eine entwickelt.  
+
+Die ersten TeX-Versionen wurden 1978 ver"offentlicht, und der letzte bekannte
+(in Erscheinung tretende) Bug wurde 1985 gefixed. Der Autor hat f"ur jeden
+Bugfix eine finanzielle Belohnung ausgesetzt, welche sich mit jedem Fehler 
+verdoppelt (beginnend bei US\$ 1.28, heute nahe der H"ochstgrenze von
+US\$327.68).
+
+\section{Warum sollte ich {\LaTeX} verwenden?}
+\begin{itemize}
+\item
+Professionelles Textsatzsystem v"ollig kostenlos
+\item
+Absolut identische Ausgabe unabh"angig von verwendeter Computerhardware, Betriebssystem, Softwareversion, Drucker
+\item
+Kompatibilit"at "uber Jahrzehnte.  Welches propriet"are Textsyetem existiert seit 1978 und kann heute noch problemlos mit den alten Dokuenten arbeiten?
+\item
+Perfekte Unterst"utzung f"ur alles, was in wissenschaftlichen Dokumenten gebraucht wird: Formelnsatz, Literaturverzeichnisse, Glossar, ...
+\end{itemize}
+
+\section{Mein erstes {\LaTeX}-Dokument}
+\subsection{Bearbeiten des .tex Files im Editor}
+
+Man nehme seinen lieblings-Texteditor und schreibe folgendes:
+
+\begin{verbatim}
+\documentstyle[german,a4]{article}
+\pagestyle{empty}
+\begin{document}
+...
+\end{document}
+\end{verbatim}
+
+Die einzelnen Elemente werden sp"ater noch ausf"uhrlich besprochen. Vorerst
+sollte einfach das obige Template verwendet werden.  Dort wo ``....'' steht,
+kann man jetzt seinen eigenen Text hinschreiben.
+
+\subsection{Das eigentliche Tex(t)processing}
+
+Nach eingabe des Quelltextes wird der Processor aufgerufen, welcher dann das Ergebnis produziert.  Unter Unix/Linux sieht der Befehl folgendermassen aus:
+
+\begin{verbatim}
+latex meinedatei.tex
+\end{verbatim}
+
+Anschlie"send liegt eine Datei {\em meinedatei.dvi} im gleichen Verzeichnis.
+Das DVI ist ein device-independent File.  Das hei"st, da"s es das Dokument in
+einem vom Ausgabeger"at unabh"angigen Format beschreibt.
+
+Dieses DVI-File kann man sich unter Linux am besten mit dem Programm {\em xdvi} ansehen:
+
+\begin{verbatim}
+xdvi meinedatei.dvi
+\end{verbatim}
+
+Sollte man nnoch etwas am Dokumnt nachbessern wollen, so editiert man wieder das .tex-File, ruft {\LaTeX} auf und sieht sich das neue .dvi an.
+
+\subsection{Das Ausgeben auf dem Drucker}
+
+Das .dvi kann nun in das endg"ultige Ausgabeformat "uberf"uhrt werden. Zumeist ist das Postscript. F"ur die Konvertierung nach Postscript wird {\em dvips} verwendet:
+
+\begin{verbatim}
+dvips meinedatei.dvi > meinedatei.ps
+\end{verbatim}
+
+oder gleich zum Drucker schicken:
+
+\begin{verbatim}
+dvips meinedatei.dvi | lpr
+\end{verbatim}
+
+\section{Allgemeines zur Syntax}
+
+\subsection{Leerzeichen}
+
+Leerzeichen und ein einfacher Zeilenumbruch werden von {\LaTeX} nicht beachtet.
+
+Ein neuer Absatz wird durch eine Leerzeile (doppelter Zeilenumbruch) begonnen.
+Zeilenumbr"uche k"onnen durch $\backslash\backslash$ am Zeilenende erzeugt
+werden.  Es k"onnen manuell Leerr"aume eingef"ugt werden:
+
+\begin{verbatim}
+\hspace{length}		% horizontaler Leerraum
+\vspace{length}		% vertikaler Leerraum
+\end{verbatim}
+
+\subsection{Trennung}
+
+Die Trennung wird von {\LaTeX} automatisch vorgenommen.  Hierbei werden die in
+der jeweiligen Landessprache ({\em german.sty}) geltneden Trennungsregeln
+verwendet.  Es k"onnen jedoch vom Autor Trennungsvorgaben gemacht werden:
+
+\begin{itemize}
+\item
+Zus"atzliche Trennungsm"oglichkeit: Donau$\backslash$-dampf$\backslash$-schiff
+\item
+Ausschliessliche Trennvorgabe: Donau\"-dampf\"-schiff
+\item
+Globale Trennvorgabe f"ur ein Wort: $\backslash$hyphenation\{Donau-dampf-schiff\}
+\item
+Keine Trennungsm"oglichkeit (im text): $\backslash$mbox\{Untrennbar\}
+\item
+Keine Trennungsm"oglichkeit (global): $\backslash$hyphenation\{Untrennbar\}
+\item
+Leerzeichen, bei dem kein Zeilenumbruch erfolgen darf: $~$
+\end{itemize}
+
+
+\subsection{Sonderzeichen}
+Sonderzeichen k"onnen nicht einfach im Flie"stext geschrieben werden, da sie
+h"aufig von Zeichensatz zu Zeichensatz unterschiedlich sind.  Einige andere
+Symbole werden von {\LaTeX} selbst als Steuer- und Kommandozeichen verwendet.
+
+\subsubsection{Deutsche Umlaute}
+\begin{verbatim}
+"a "o "u "A "O "U "s
+\end{verbatim}
+"a "o "u "A "O "U "s
+
+\subsubsection{Ausl"andische Sonderzeichen}
+\begin{verbatim}
+\'o \`o \^o \=o \.o \u{o} \v{o} \H{o} \t{oo} \c{c} \d{o}
+\end{verbatim}
+\'o \`o \^o \=o \.o \u{o} \v{o} \H{o} \t{oo} \c{c} \d{o}
+
+\subsubsection{Sonderzeichen/Symbole}
+\begin{verbatim}
+\$ \& \% \# \{ \} [ ] \_ @ \S \pounds $<$ $>$ $\backslash$ @' !'
+\end{verbatim}
+\$ \& \% \# \{ \} [ ] \_ @ \S \pounds $<$ $>$ $\backslash$ @' !'
+
+\section{Dokumentstruktur}
+
+\subsection{Gliederung}
+
+Gr"o"sere Dokumentvorlagen wie book.sty haben Teile und Kapitel. Dise k"onnen wie folgt verwendet werden:
+
+\begin{verbatim}
+\part{Teil"uberschrift}
+\chapter{Kapitel"uberschrift}
+\end{verbatim}
+
+Kleinere Dokumentvorlagen wie article.sty bieten die Unterteilung in
+Abschnitte, Unterabschnitte, Unter-Unterabschnitte, Abs"tze und Unterabs"atze.
+Selbstverst"andlich sind diese Gliederungselemente auch in gr"o"seren
+Dokumentvorlagen verwendbar.
+
+\begin{verbatim}
+\section{Abschnitts"uberschrift}
+\subsection{Unterabschnitts"uberschrift}
+\subsubsection{Unter-Unterabschnitts"uberschrift}
+\paragraph{Absatz"uberschrift}
+\subparagraph{Unterabsatz"uberschrift}
+\end{verbatim}
+
+Die einzelnen Gliederungselemente werden automatisch durchnummeriert.  Wie tief die Nummerierung angezeigt wird, ist einstellbar.  Standardm"a"sig wird nur bis Subsection nummeriert, d.h. subsubsection, paragraph und subparagraph erhalten keine angezeigte Nummerierung.
+
+\begin{verbatim}
+\setcounter{secnumdepth}{wert}
+\end{verbatim}
+
+\label{gliederungswerte}
+Wobei {\em wert} die folgenden Werte annehmen kann: 
+\begin{description}
+\item[-1] keine Nummern
+\item[0] nur Chapter
+\item[1] Chapter und Section
+\item[2] Chapter bis Subsection
+\item[3] Chapter bis Subsubsection
+\item[4] Chapter bis Paragraph
+\item[5] alle
+\end{description}
+
+\subsection{Titelseite}
+
+Die meisten Dokumentvorlagen bieten die M"oglichkeit, automatisch eine Titelseite zu generieren. Dazu werden die folgenden Definitionen verwendet:
+
+\begin{verbatim}
+\title{Titel}
+\thanks{Danksagung}
+\author{Autor}
+\date{Datum}
+\maketitle
+\end{verbatim}
+
+\subsection{Zusammenfassung}
+
+Eine Zusammenfassung kann dem eigentlichen Dokument vorangestellt werden:
+
+\begin{verbatim}
+\begin{abstract}
+...
+\end{abstract}
+\end{verbatim}
+
+\subsection{Inhaltsverzeichnis}
+
+Aus den Gliederungselementen kann auf Wunsch automatisch ein Inhaltsverzeichnis erzeugt werden. Hierzu verwendet man den Befehl
+\begin{verbatim}
+\tableofcontents
+\end{verbatim}
+
+Man kann nun noch bestimmen, bis zu welcher Gliederungsebene Eintr"age im Inhaltsverzeichnis gemacht werden sollen:
+\begin{verbatim}
+\setcounter{tocdepth}{tiefe}
+\end{verbatim}
+
+Wobei {\em tiefe} die gleichen Werte annehmen kann, wie in Teil \ref{gliederungswerte} auf Seite \pageref{gliederungswerte} beschrieben.
+
+
+\section{Formatierung}
+
+\subsection{Schriftarten}
+
+Man kann selbstverst"andlich auch zwischen diversen Schriftarten w"ahlen.  Der Einfachheit halber werden hier jedoch nur die Standardschriften beschrieben:
+
+\begin{itemize}
+\item
+{\rm Roman}: $\backslash$rm
+\item
+{\bf Fett}: $\backslash$bf
+\item
+{\it Kursiv}: $\backslash$it (Italic-Korrektur $\backslash$/)
+\item
+{\sl Slanted}: $\backslash$sl
+\item
+{\sf Sans Serif}: $\backslash$sf
+\item
+{\sc Small Caps}: $\backslash$sc
+\item
+{\tt Typewriter}: $\backslash$tt
+\end{itemize}
+
+\subsection{Schriftgr"o"sen}
+
+\begin{itemize}
+\item {\tiny $\backslash$tiny}
+\item {\scriptsize $\backslash$scriptsize}
+\item {\footnotesize $\backslash$footnotesize}
+\item {\small $\backslash$small}
+\item {\normalsize $\backslash$normalsize}
+\item {\large $\backslash$large}
+\item {\Large $\backslash$Large}
+\item {\LARGE $\backslash$LARGE}
+\item {\huge $\backslash$huge}
+\item {\Huge $\backslash$Huge}
+\end{itemize}
+
+\subsection{Textausrichtung}
+
+Standardm"a"sig formatiert {\LaTeX} immer im Blocksatz. Dies kann ge"andert
+werden:
+
+\begin{verbatim}
+\begin{center}
+Zentriert
+\end{center}
+\end{verbatim}
+
+Es k"onnen neben {\em center} auch {\em flushleft} oder {\em flushright}
+verwendet werden, um linksb"undige bzw. rechtsb"undige Ausgabe zu erhalten.
+
+\subsection{Zitate}
+
+Zitate k"onnen wie folgt eingebunden werden:
+\begin{verbatim}
+\begin{quotation}
+Mahlzeit
+\end{quotation}
+\end{verbatim}
+
+
+
+\section{Listen und Aufz"ahlungen}
+
+\subsection{Listen}
+
+Eine Liste kann wie folgt erzeugt werden:
+
+\begin{verbatim}
+\begin{itemize}
+\item erster eintrag
+\item zweiter eintrag
+\end{itemize}
+\end{verbatim}
+
+\subsection{Aufz"ahlungen}
+
+Eine Aufz"ahlung kann wie folgt erzeugt werden:
+\begin{verbatim}
+\begin{enumerate}
+\item erster Eintrag
+\item zweiter Eintrag
+\end{enumerate}
+\end{verbatim}
+
+\subsection{Beschreibungen/Definitionen}
+
+Eine Beschreibung kann wie folgt erzeugt werden:
+\begin{verbatim}
+\begin{description}
+\item[Donald E. Knuth] Autor des bekannten TeX Syetems
+\item[Donald Becker] Autor von zahllosen Linux-Netzwerktreibern
+\end{description}
+\end{verbatim}
+
+\section{Fu"snoten, Querverweise, Literaturverzeichnis}
+
+\subsection{Fu"snoten}
+Eine Fu"snote\footnote{Fussnoten sehen so aus *g*} wird einfach in den Text
+mit hineingeschrieben, an der Stelle an der sie erscheinen soll:
+\begin{verbatim}
+Benutzt man hingegen das Sub-Etha-Sens-O-Matic\footnote{Ein Ger"at zur 
+detektion in der N"ahe befindlicher Raumschiffe}, so ....
+\end{verbatim}
+
+\subsection{Querverweise}
+
+Es k"onnen Querverweise eingef"ugt werden, welche dann automatisch auf die
+jeweils aktuelle Abschnittsnummer / Seite verweisen, auch wenn sich das Ziel
+des Querverweises verschiebt.
+
+An dem Ziel des Querverweises (also wohin man verweisen m"ochte), wird
+folgender Befehl eingef"ugt:
+\begin{verbatim}
+\label{namedeslabels}
+\end{verbatim}
+
+Ein Querverweis dorthin sieht dann wie folgt aus:
+\begin{verbatim}
+Wie in Abschintt \ref{namedeslabels} auf Seite \pageref{namedeslabels}
+beschrieben
+\end{verbatim}
+
+\subsection{Literaturverzeichnis}
+
+Vor allem in wissenschaftlichen Dokumenten wird ein Literaturverzeichnis
+gebraucht.  Es gibt zwei unterschiedliche M"oglichkeiten, ein
+Literaturverzeichnis unter {\LaTeX} zu verwenden.
+
+Die einfache, hier beschriebene Variante eignet sich f"ur kleine, einzelne
+Dokumente.  Wer h"aufig zu den gleichen Themen dokumente verfasst, sollte sich
+mit {\em bibtex} auseinandersetzen, hier kann man sich ein zentrales 
+Literaturverzeichnis anlegen, worauf von allen Dokumenten aus verwiesen werden
+kann.
+
+Ein Verweis auf ein Literaturverzeichnis sieht so aus:
+\begin{verbatim}
+Wie in \cite[Seiten 12 ff.]{1} bescrhieben, ...
+\end{verbatim}
+
+Das Literaturverzeichnis am Ende sieht dann so aus:
+\begin{verbatim}
+\begin{thebibliography}{99}
+\bibitem{1} Markus M"uller, {\sl Mahlzeit - das Kochbuch, Addison-Wesley, 1995}
+\end{thebibliography}
+\end{verbatim}
+
+
+\section{Dokumentvorlagen}
+
+Wir haben in den bisherigen Beispielen immer die Dokumentvorlage {\em article.sty} vewendet.  Die zu verwendende Dokumentvorlage wird im Kopf des Dokuments mit dem {\em $\backslash$documentstyle}-Befehl angegeben.
+
+G"angige Dokumentvorlagen:
+\begin{description}
+\item[article] F"r das Verfassen strukturierter Dokumente begrenzter L"ange
+\item[book] Zum Verfassen eines Ganzen Buches
+\item[dinbrief] Zum Verfassen eines sich exakt an der DIN-Norm orientierenden Briefes
+\end{description}
+
+Zus"atzlich werden beim {\em documentstyle}-Befehl in den eckigen Klammern noch
+Optionen angegeben.
+
+G"angige Optionen:
+\begin{description}
+\item[10pt, 11pt, 12pt] Standardschriftgr"o"se
+\item[german] Unterst"utzung f"ur deutsche Umlaute und Trennregeln
+\item[twocolumn] Zweispaltige Formatierung
+\item[twoside] Zweiseitiger Druck (Seitennummern, etc.)
+\end{description}
+
+\end{document}