import of old now defunct presentation slides svn repo

5 files changed, 459 insertions, 0 deletions

diff --git a/2004/nat-ccc2004/biography b/2004/nat-ccc2004/biography
new file mode 100644
index 0000000..22438a2
--- /dev/null
+++ b/2004/nat-ccc2004/biography
@@ -0,0 +1,24 @@
+  Harald Welte is the chairman of the netfilter/iptables core team.
+
+  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 UUCP over SSL HOWTO.  Other kernel-related projects he has been
+contributing are user mode linux, the international (crypto) kernel patch, device drivers and the neighbour cache.
+
+  He has been working as an independent IT Consultant working on projects 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 Conectiva Inc.
+
+  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.  
+
+  Aside from the Astaro sponsoring, he continues to work as a freelancing
+kernel developer and network security consultant.
+
+  He licenses his software under the terms of the GNU GPL.  He is determined to bring all users, distributors, value added resellers and vendors of netfilter/iptables based products in full compliance with the GPL, even if it includes raising legal charges.
+
+  Harald is living in Berlin, Germany.
+
+
diff --git a/2004/nat-ccc2004/cfp-reply b/2004/nat-ccc2004/cfp-reply
new file mode 100644
index 0000000..0d3bde3
--- /dev/null
+++ b/2004/nat-ccc2004/cfp-reply
@@ -0,0 +1,53 @@
+21c3-content@cccv.de
+
+    * Name: Full name of speaker
+
+Harald Welte
+
+    * Bio: Short biography of speaker
+
+See Attachment 1
+
+    * Contact: E-Mail, phone, instant messaging etc.
+
+email: laforge@gnumonks.org
+Phone: +49-30-24033902
+Fax: +49-30-24033904
+
+    * Title: Name of event or lecture
+
+The Reality of Network Address Translators
+
+    * Subtitle: Additional title description (a couple of words, optional)
+
+
+    * Abstract: An abstract of the event's content (max. 250 letters)
+
+NAT's are ubiquitous in todays Internet. Unfortunately the IETF missed to
+recognize this reality.  Due to this lack of standardizaiton, NAT's pose an
+enormous threat to the paradigm shift from client-server to peer-to-peer.  The
+presentation covers proposed solutions.
+
+
+    * Description: A detailed description of the event's content (250 to 500 words)
+
+See Attachment 2
+
+    * Attachments: more information
+         o Links to background information
+
+http://www.potaroo.net/ietf/idref/draft-aoun-nsis-nslp-natfw-migration/
+http://www.ietf.org/internet-drafts/draft-audet-nat-behave-00.txt
+http://www.rnp.br/ietf/internet-drafts/draft-ford-natp2p-00.txt
+http://www.ietf.org/proceedings/03nov/I-D/draft-ietf-mmusic-ice-00.txt
+http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-03.txt
+http://ietfreport.isoc.org/ids/draft-jennings-midcom-stun-results-01.txt
+http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-natfw-security-problems-00.txt
+http://alumnus.caltech.edu/~dank/peer-nat.html
+http://www.faqs.org/rfcs/rfc3489.html
+
+         o Links to information on the lecture itself
+         o Slides, Paper in PDF or other formats
+
+Not yet available.
+
diff --git a/2004/nat-ccc2004/extended-abstract b/2004/nat-ccc2004/extended-abstract
new file mode 100644
index 0000000..de9af12
--- /dev/null
+++ b/2004/nat-ccc2004/extended-abstract
@@ -0,0 +1,34 @@
+The Reality of Network Address Translators
+
+NAT's are ubiquitous in todays Internet, not only built into so-called DSL or
+WLAN Routers within customer premises, but also in the corporate environment. 
+
+The dream of an end-to-end transparent network has died one NAT at at time.
+
+Unfortunately the IETF missed to recognize this reality for a long time.  This
+means that there are no up-to-date informations (like best current practice
+RFC's) specifying how an implementor should implement Network Address
+Translation.   This lack of standardization leads to different NAT behaviour
+from implementor to implementor.
+
+Tradiditonal IP based protocols are built around the client-server paradigm,
+and NAT's are designed for this.  However, recently protocols and applications
+based on the peer-to-peer paradigm are becomming more and more common.  And
+this is where NAT's become a major problem, especially since they don't expose
+any standardized deterministic behaviour.
+
+Many approaches have been designed, usually with H.323 or SIP as driving force
+behind them.  FCP, Midcom, NSIS, STUN - just to name a few examples.
+
+None of them works in all, or even the majority of all cases. In fact the
+author of this presentation believes it is impossible to solve the problem
+without making assumptions on some common behaviour of all NAT implementations.
+
+The recently published draft-audet-nat-behave tries to be a first candidate of
+such a behavioral specification.  It is scheduled to evolve into a BCP RFC on
+NAT behaviour in 2005.
+
+The presentation will present the fundamental problem, look at different
+classes of NAT's, their behaviour, and give an overview about the proposed
+solutions.
+
diff --git a/2004/nat-ccc2004/nat-ccc2004.mgp b/2004/nat-ccc2004/nat-ccc2004.mgp
new file mode 100644
index 0000000..78a6cdc
--- /dev/null
+++ b/2004/nat-ccc2004/nat-ccc2004.mgp
@@ -0,0 +1,343 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+The reality of 
+Network Address Translators
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@netfilter.org>
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Reality of NAT
+Contents
+
+
+	RFC3489: STUN
+	RFC3714: IAB problem statement / congestion control
+	RFC3448: TFRC, TFRC-PS
+	DCCP
+	NSIS: GIMPS / NAT NSLP
+	BEHAVE
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+NAT Basics
+
+	Network Address Translation is an old technique
+	Widely used throughout the net as a way to cope with address shortage
+	More and more popular with to DSL and cable modem routers
+	Unfortunately not standardized at all
+	NAT itself is not a security technology !!
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+NAT Basics
+
+	What does NAT do?
+		Rewrite addresses of packets as they pass a particular forwarding machine
+
+	What can be translated?
+		Layer 3 (IP) addresses 
+		Layer 4 (TCP/UDP/SCTP/...) specific addresses
+		Layer 5+ (e.g. FTP PORT statements)
+
+	Where can it be translated?
+		Traditionally, at a router
+		But also possible on a bridge
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+NAT Configurations
+
+	Source NAT
+		source address of the first packet of a particular connection is changed
+
+	Masquerading
+		special case of Source NAT, most common implementation
+
+	Destination NAT
+		destination address of of the first packet of a particular connection is changed
+		sometimes referred to as 'port mapping' or 'port redirection'
+
+	Bi-NAT
+		1:1 translation of whole address ranges or networks
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+Why is NAT a nightmare
+
+	NAT might have been a solution 8 years ago
+	However,
+		it is very much designed for the traditional client/server paradigm
+		the Internet sees more advanced applications such as
+			peer-to-peer networks
+			Voice over IP
+			Multimedia streams
+		protocols are getting increasingly complex
+			multiple layer 4 connections comprising one logical connection
+			embedding layer 3/4 addresses in payload leads to ALG requirement
+			direct 'client-to-client' transmission of media streams  not possible due to deployment of NAT.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+NAT Basics
+
+	But well, even eight years ago....
+	NATing a FTP connection is a real PITA. Why?
+		First you change the source ip/port of the control connection
+		Then your ftp client sends a PORT command (in ASCII!!!)
+			PORT 123,123,123,123,1,0
+		Then your ftp nat ALG needs to change that to
+			PORT 1,1,1,1,10,10
+		Thus, the resulting string is shorter! 
+			therefore you need to mangle every sequence number of each successive packet 
+			now think of multiple port commands being issued within a single TCP window and retransmissions
+			if that is not enough, think of SACK
+		Summary
+			It is ugly as hell
+			Difficult to impossible to get right in all cases
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+Why is NAT a nightmare
+
+	Todays NAT's horribly violate the network layering model
+		a NAT (although it operats on a rotuer or bridge) requires knowledge of the application protocols
+		support for every new protocol needs to be added to all NAT's
+	Also, you loose the ability to encrypt the payload
+		SIP can PGP-encrypt SDP. 
+		However, port numbers are inside SDP
+		Therefore, if you use crypto, it just can't work
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+Types of NAT (STUN  RFC3489)
+
+
+	Full Cone
+		all requests from the same internal IP and port are mapped to the same external IP address and port
+		any external host can send a packet to the internal host by sending a packet to the mapped address
+
+	Restricted Cone
+		all requests from the same internal IP and port are mapped to the same external IP address and port.
+		an external host can send a packet to the internal host only if the internal host had previously ent a packet to that particular external host
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+Types of NAT (STUN  RFC3489)
+
+
+	Port Restricted Cone
+		like restricted cone, but includes port numbers
+		an external host can send a packet with source IP X and port P to the internal host only of the internal host had perviously sent a packet to IP address X and port P
+
+	Symmetric
+		all requests from same internal IP address and port to a specifica destination IP and port are mapped to the same external IP and port.
+		if the same host sends a packet with the same source address and port, but to a different estination, a different mapping is used.  Only the external host that receives a packet can send a packet back to the external host
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+Types of NAT: draft-audet-nat-behave
+
+	Address and port binding
+		External NAT binding is endpoint independent
+		External NAT binding is endpoint address dependent
+		External NAT binding is endpoint address and port dependent
+
+	Port Assignment
+		Port Preservation
+		Port Overloading
+
+	Bind Refresh Scope
+		Per binding
+		Per session
+		Only outgoing or also incoming?
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+Types of NAT: draft-audet-nat-behave
+
+	Filtering of unsolicited packets
+		External filtering is endpoint independent
+		External filtering is endpoint address dependent
+		External filtering is endpoint address and port dependent
+
+	Hairpinning Behaviour
+		What happens if two endpoints are behind same nat
+
+	Deterministic Properties
+		Chaning over time:
+			Port preservation
+			Port allocation algorithm
+			Address and port binding 
+			Filtering
+
+	Multicast Behaviour
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+The IETF and NAT
+
+	The IETF has long ignored the fact that NAT's are commonplace
+		Therefore, there's a lack of standardization in NAT behaviour
+		Furthermore, it is impossible to make a protocol work with all existing NAT's
+		Protocol designers normally don't consider NAT when developing new protocols
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+The IETF and NAT
+
+	SIP was the first IETF protocol that had _serious_ NAT issues
+		Therefore, the SIP working group came up with FCP (Firewall Control Protocol)
+		Later, a new working group 'MIDCOM' was founded
+		MIDCOM took several years but didn't really come up with a solution
+	Now there are dozens of groups publishing papers, drafts and RFC's.
+	Most of them are targeted at UDP-only operation
+	Most of them target consumer side NAT devices
+	
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+How to solve the NAT problem?
+
+	At a protocol level
+		designing protocols in a way to operate on most/all NAT's
+		SIP has some extensions for this
+		IPsec also introduced NAT-T to tackle the problem
+		Very difficult because of the number of differnet implementations and lack of standardization
+
+	At a NAT level
+		Making NAT's interoperate with all different kinds of protocols
+		Support operations like hole-punching for UDP and TCP
+		Problematic because of large existing deployment
+	
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+How to solve the NAT problem?
+
+	With a specific NAT configuration protocol
+		FCP
+		MIDCOM
+		GIMPS NSIS NAT NSLP
+		uPnP
+	
+	There is no good solution without standardization
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+RFC3489: STUN
+
+RFC3489: STUN (Simple Traversal of UDP Through NAT)
+	Helps endpoints to find out whether they are behind some form of NAT by communication with a host known to have an official IP
+	Tries to create NAT binding(s) on NAT devices 
+	allows applications to 'open ports' on the NAT
+	implemented with lots of apps, including gnomemeeting
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+RFC3714
+
+	IAB problem statement about media traffic without congestion control
+		danger of congestion collapse with VoIP / streaming media
+		IETF actions to counter this problem
+			upgrade RTP to make packet loss monitoring a MUST
+			TFRC (TCP Friently Rate Control)
+			TFRC-PS (TCP Friendly Rate Control - Packet Size)
+			DCCP (Datagram Congestion Control Protocol)
+			Adaptive Audio Codecs
+			specified drop rate for mimimum sending rate (tables)
+	
+	Result:
+		We'll see new layer four protocols that need NAT, too
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+NSIS WG
+
+	NSIS (Next Step In Signalling) WG:
+		Signalling Transport protocol for Signalling QoS, NAT, Firewalls
+		GIMPS (Generic Internet Messaging Protocol for Signalling)
+			Builds on top of TCP/UDP/SCTP/DCCP
+			can be combined with TLS and IPsec
+			Has Messages with 'Router Alert' that are to be processed by Routers/Firewalls/NATs
+		NAT NSIS Signalling Layer Protocol
+			wants to establish a connection between two ends, any number of Firewalls / NAT's in between
+			draft-aoun-nsis-nslp-natfw-migration-02
+			draft-tschofenig-nsis-natfw-security-problems-00
+			draft-aoun-nsis-nslp-natfw-intrarealm-00.txt
+			draft-martin-nsis-nslp-natfw-sip-00.txt
+			draft-fessi-nsis-natfw-threats-01.txt
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+Reality of NAT
+BEHAVE
+
+	Behave working group
+		Parts of IETF acknowledge NAT is reality
+		Acknowledges lack of standardization
+		wants to provide vendor guidelines for NAT implementation
+		focus on UDP and TCP unicast
+		will adress multicast NAT, too
+		goal: NAT-BEHAVE BCP RFC
+		second document describing protocol design for BEHAVE-compliant NATs
+		current draft:
+			require outbound-only UDP timer refresh
+			strongly discourages port persistency
+			requires no NAT for IPv6
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+Reality of NAT
+Thanks
+
+	Thanks to
+		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
+		Free Software Foundation
+			for the GNU Project 
+			for the GNU General Public License
+%size 3
+	The slides of this presentation are available at http://www.gnumonks.org/
+
+	Further Reading
+%size 3
+	The netfilter homepage http://www.netfilter.org/
diff --git a/2004/nat-ccc2004/short-abstract b/2004/nat-ccc2004/short-abstract
new file mode 100644
index 0000000..b31c803
--- /dev/null
+++ b/2004/nat-ccc2004/short-abstract
@@ -0,0 +1,5 @@
+NAT's are ubiquitous in todays Internet. Unfortunately the IETF missed to
+recognize this reality.  Due to this lack of standardizaiton, NAT's pose an
+enormous threat to the paradigm shift from client-server to peer-to-peer.  The
+presentation covers proposed solutions.
+