1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
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/
|