diff options
Diffstat (limited to '2004/nat-ccc2004')
| -rw-r--r-- | 2004/nat-ccc2004/biography | 24 | ||||
| -rw-r--r-- | 2004/nat-ccc2004/cfp-reply | 53 | ||||
| -rw-r--r-- | 2004/nat-ccc2004/extended-abstract | 34 | ||||
| -rw-r--r-- | 2004/nat-ccc2004/nat-ccc2004.mgp | 343 | ||||
| -rw-r--r-- | 2004/nat-ccc2004/short-abstract | 5 |
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. + |