21C3 Schedule Release 1.1.7
21st Chaos Communication Congress
Lectures and workshops
Speakers | |
---|---|
Harald Welte |
Schedule | |
---|---|
Day | 3 |
Location | Saal 4 |
Start Time | 16:00 h |
Duration | 01:00 |
INFO | |
ID | 72 |
Type | Lecture |
Track | Hacking |
Language | english |
FEEDBACK | |
---|---|
Did you attend this event? Give Feedback! |
The Reality of Network Address Translators
Dealing with NAT
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.
NATs 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.