NAT/Firewalls and Applications
Olivier Paul
LOR department
Schedule
• Bibliography– Cedric Aoun, A NAT and Firewall signaling framework for the Internet,
PhD thesis, ENST, 2005.
Schedule
• What is NAT ?– NAT Classification(s)
• What problems are we trying to solve ?• Answers
– Changing NATs a lot & keeping applications as is.• ALGs
– Exploiting NAT properties & changing applications a little.• STUN• TURN
– Changing NAT a little & applications a lot.• MIDCOM, NSIS• UPNP
– Other approaches.• Manual configuration.• Tunneling
What is NAT
• Operations
NAT
NAT Rules
IP Packet IP Packet
• Rules specify what should be changed in the IP packet header.– IP addresses (Source/Destination).
– Transport level identifiers (Ports/ICMP Identifier).
• And how.– Replace with fixed value.
– Replace with dynamically allocated value.
• Network/Transport level devices.
• Often bundled with routers/Firewalls.
Source/Destination NAT
• Considers what is changed in first IP packet of a communication• Source address NAT
– Used to hide internal addresses.• Internal addresses reveal information about network structure.• Randomize port numbers to defeat insertion attacks.
– Used to solve IPv4 addressing restrictions• Dynamic public address attribution (NAT – RFC 3022).• Multiplex multiple communications from several IP addresses using different port
values (NAPT – RFC 3022).
• Destination address NAT– Used to redirect traffic to particular device.
• As seen in firewall section.
– Used to limit rights of contacted applications while keeping privileged port numbers.
• Redirects ports < 1024 to ports > 1024.
Static/Dynamic NAT
• Considers whether the result of applying NAT rules can give a different result over time.– Static
NAT
NAT Rules:A int;Pint �Aext;PextAext;Pext �A int;Pint
A int;Pint Adst;Pdst Aext;Pext Adst;Pdst
NAT
NAT Rules:A int;Pint : dyn.
A int;Pint Adst;Pdst Aext;Pext Adst;Pdst
– The state is usually called binding.– One binding is kept for every session.– The definition of “session” is implementation dependant.
– Dynamic
Adst;Pdst Aext;PextAdst;Pdst A int;Pint
A int;Pint Adst;Pdst Aext;Pext’ Adst;Pdst
State:A int;Pint� Aext;PextA int;Pint� Aext;Pext’
Source/Destination NAT
Dynamic NATStatic NAT
XUsed to limit rights of contacted applications while keeping privileged port numbers.
XUsed to redirect traffic to particular device.
XUsed to solve IPv4 addressing restrictions
XXUsed to hide internal addresses
NAT standardization
• RFC 3022, Traditional IP Network Address Translator.– Defines Traditional NAT/NAT Port Translation bindings.
• Trad. NAT: (Aint� Aext)– Supports any protocol.
• NAT - PT: (Aint:Pint� Aext:Pext)– Supports UDP/TCP and ICMP query/reply.– Prohibits inbound sessions.
– Bindings• Allocated when first packet is received.• Kept as long as a session is going on.
– Headers manipulations• UDP/TCP/ICMP checksums: recomputed after change.• ICMP Error packet payload. Modify payload to match original tuple.• IP routing options. Can be kept unchanged.
Other Classifications
• RFC3489, Based on the most common definitions for “sessions”– Cone NATs:
• Binds: Aint:Pint� Aext:Pext.
• Any packet to Aext:Pext is translated to Aint:Pint
– Full cone NAT.• Does not filter anything.
– Address restricted cone NAT.• Filters out packets that do not come from Adst’ where Adst’ is the address of a packet
sent out.
– Port-Restricted cone NAT.• Filters out packets that do not come from Adst’:Pdst’ where Adst’:Pdst’ is the address of
a packet sent out.
Other Classifications
• RFC3489, Based on the most common definitions for “sessions”– Cone NATs.
• If two packets are sent from Aint:Pint to Adst:Pdst and Adst’:Pdst’, Adst’:Pdst’ can send traffic to Aint:Pint !
– Symmetric NAT.• Binds: Aint:Pint, Adst:Pdst� Aext:Pext.
• Any packet coming from Adst:Pdst and sent to Aext:Pext is translated to Aint:Pint.
• Filters out packets that do not come from Adst:Pdst to Aint:Pint.
• Many NAT implementations do not match this classification.
• This classification is being refined by separating filtering behavior from address translation behavior.
NAT behaviors
• Existing types of NATs (2004):– NAT Classification Results using STUN, draft-jennings-midcom-stun-results-00– Study over 34 different NAT devices
• 30% were Full Cone NATs.• 3% were Address Restricted Cone NATs.• 55% were Port Restricted NATs.• 3% were Symmetric NATs.• 9% were not compliant with NAT classification.
• Characterization and Measurement of TCP Traversal through NATs and Firewalls. Saikat Guha, Paul Francis. IMC 2005:– Study over 16 NAT devices (+93 in the wild)
• 57% (70%) Full Cone NATs.• 19% (23%) Port Restricted NATs.• 19% (6%) were Symmetric NATs.• 5% (0.5%) were not compliant with NAT classification.
More NAT specification
• RFC 4787: Network Address Translation (NAT) Behavioral Requirements.– Separates filtering behavior from binding behavior.– Address and Port Mapping:
• Endpoint-Independent Mapping ~ Cone binding.– (Aext; Pext) depends on (Aint; Pint).
• Address-Dependent Mapping ~ Symmetric binding.– (Aext; Pext) depends on (Aint; Pint; Adst).
• Address and Port-Dependent Mapping ~ Symmetric binding.– (Aext; Pext) depends on (Aint; Pint; Adst; Pdst).
– Filtering Behavior• Assuming Aint;Pint establishes communication with Adst;Pdst
• Endpoint-Independent Filtering– Filters out packet not destined to Aint;Pint
• Address-Dependent Filtering– Filters out packet not destined to Aint;Pint and coming from Adst
• Address and Port-Dependent Filtering– Filters out packet not destined to Aint;Pint and coming from Adst;Pdst
More NAT specification
• RFC 4787: Network Address Translation (NAT) Behavioral Requirem.– Specifies desirable NAT behaviors ("MUST" points)
• "Endpoint-Independent Mapping“.• No "Port overloading“.
– Does not attribute the same port to two simultaneous communications.
• "NAT Outbound refresh behavior“. – Refresh binding when outbound traffic received.
• Minimal “UDP mapping timer”– Must not expire in less than two minutes,
• "Hairpinning". – Routing between two hosts behind the same NAT.
• “Deterministic behavior”• “ICMP message”
– ICMP messages must not end bindings.
• “Received Fragment Out of Order”. – Able to deal with fragmentation problem.
– “SHOULD” point• “Endpoint-Independent Filtering”
Security Issues
Schedule
• What is NAT ?– NAT Classification(s)
• What problems are we trying to solve ?• Answers
– Changing NATs a lot & keeping applications as is.• ALGs
– Exploiting NAT properties & changing applications a little.• STUN• TURN
– Changing NAT a little & applications a lot.• MIDCOM, NSIS• UPNP
– Other approaches.• Manual configuration.• Tunneling
Problems using NAT
• Summarized in RFC 3027: “Protocol Complications with the IP Network Address Translator”:– Realm specific address/identifier in payload.– IPsec related.– NAT mapping behavior.– NAT filtering behavior.– IP Fragmentation.– Application Protocols requiring specific IP mapping.
• Others:– Asymmetric/Disjoint routing.– Changes in routing topology.
Problem #1
• Realm specific address information in payload
IP: 157.159.100.54 157.159.100.55 UDPUDP: 6091 5060SIP: INVITE sip:[email protected]: Via: SIP/2.0/UDP 192.168.4.5:5067SIP: From: <sip:[email protected]>SDP: (c): IN IP4 192.168.4.5SDP: (m): audio 5054 RTP/AVP
IP: 157.159.100.55 192.168.4.5 UDPUDP: 5054 6091 RTP:
IP: 192.168.4.5 157.159.100.55 UDPUDP: 5067 5060 SIP: INVITE sip:[email protected]: Via: SIP/2.0/UDP 192.168.4.5:5067SIP: From: <sip:[email protected]>SDP: (c): IN IP4 192.168.4.5SDP: (m): audio 5054 RTP/AVP
192.168.4.5 5067 <--> 157.159.100.54 6091
XPacket Unroutable
Problem #2
• Transport level information can be encrypted.– Here ESP in tunnel mode
IP: 157.159.100.54 157.159.100.55 UDPESP: SPI = 5125524IP: 192.168.4.5 157.159.100.55UDP: 5067 5060 SIP: INVITE sip:[email protected]: Via: SIP/2.0/UDP 192.168.4.5:5067SIP: From: <sip:[email protected]>SDP: (c): IN IP4 192.168.4.5SDP: (m): audio 5054 RTP/AVP
IP: 192.168.4.5 157.159.100.55 ESPESP: SPI = 5125524IP: 192.168.4.5 157.159.100.55UDP: 5067 5060 SIP: INVITE sip:[email protected]: Via: SIP/2.0/UDP 192.168.4.5:5067SIP: From: <sip:[email protected]>SDP: (c): IN IP4 192.168.4.5SDP: (m): audio 5054 RTP/AVP
X X
NAT impossible
Potential ConflictIf simultaneous communications
Can not change SPI192.168.4.5 <--> 157.159.100.54
Problem #3
• IP/Transport level information can be integrity protected.– Here AH in tunnel mode. In AH IP source address is immutable.
IP: 157.159.100.54 157.159.100.55 AHAH: SPI = 5125524IP: 192.168.4.5 157.159.100.55UDP: 5067 5060 SIP: INVITE sip:[email protected]: Via: SIP/2.0/UDP 192.168.4.5:5067SIP: From: <sip:[email protected]>SDP: (c): IN IP4 192.168.4.5SDP: (m): audio 5054 RTP/AVP
IP: 192.168.4.5 157.159.100.55 AHAH: SPI = 5125524IP: 192.168.4.5 157.159.100.55UDP: 5067 5060 SIP: INVITE sip:[email protected]: Via: SIP/2.0/UDP 192.168.4.5:5067SIP: From: <sip:[email protected]>SDP: (c): IN IP4 192.168.4.5SDP: (m): audio 5054 RTP/AVP
192.168.4.5 <--> 157.159.100.54
X
Integrity checkfails
X
NAT impossible
Problem #4
• Applications with server role and realm specific addresses– How to learn application address ?– Packets sent can either reach the wrong destination or fail to be routed.
Contact me at A2;P2
?
1
2
3
4
Problem #5
• Mapping dependence/independence behavior– Packet not matching an existing session (Address&Port dependent mapping).
IP: 157.159.100.54 157.159.100.55 UDPUDP: 6091 5060SIP: INVITE sip:[email protected]: Via: SIP/2.0/UDP 192.168.4.5:5067SIP: From: <sip:[email protected]>SDP: (c): IN IP4 192.168.4.5SDP: (m): audio 5054 RTP/AVP
IP: 157.159.100.55 157.159.100.54 UDPUDP: 5079 6091 SIP: Status: 100 Trying
IP: 157.159.100.54 157.159.100.55 ICMPICMP: 5079 6091 Destination unreachable
IP: 192.168.4.5 157.159.100.55 UDPUDP: 5067 5060 SIP: INVITE sip:[email protected]: Via: SIP/2.0/UDP 192.168.4.5:5067SIP: From: <sip:[email protected]>SDP: (c): IN IP4 192.168.4.5SDP: (m): audio 5054 RTP/AVP
192.168.4.5 5067 <--> 157.159.100.54 6091
X
Problem #6
• Filtering dependence/independence behavior– Inbound originated traffic is prohibited
Contact me at A3;P3
1
2
3
4
Dst=A3;P3Src=A1;P1
Dst=A3;P3Src=A1;P1
X
Inbound Packet dropped
Problem #7
• IP Fragmentation– Only first IP fragment contains transport information.
• NAT relies on Source IP address & packet ID to change IP address in following fragments.
– NAT should rewrite IDs.
Recipient cannot reassemble
Problem #8
• Protocols requiring specific IP mapping– Problem with static NAT.– Some applications use well known ports/relation between port numbers.
• Only one can be mapped to an external address at a time.• Relation in port numbers is application specific and most NAT don’t parse
application traffic.
?
Problem #9
• Asymmetric/Disjoint routing – NATs not belonging to same organizations.– Traffic comes back through a different path.
Client 1192.168.4.5 5067
192.168.4.5 5067 <--> 157.159.100.54 6090
X
– Traffic treatment is differentiated though it goes to the same destination.
Client 1192.168.4.5 5067
192.168.4.5 5067 <--> 157.159.100.54 6090 SIP157.159.100.54 6094 <--> 192.168.4.5 5068 RTP
X
Problem #9
• Routing changes – NATs not belonging to same organizations.– Traffic path changes over time.
Client 1192.168.4.5 5067
192.168.4.5 5067 <--> 157.159.100.54 6090
X
– Traffic treatment is differentiated though it goes to the same destination.
Client 1192.168.4.5 5067
192.168.4.5 5067 <--> 157.159.100.54 6090 SIP
X
192.168.4.5 5068 <--> 157.159.100.53 1538 RTP 2 different source addresses
Schedule
• What is NAT ?– NAT Classification(s)
• What problems are we trying to solve ?• Answers
– Changing NATs a lot & keeping applications as is.• ALGs
– Exploiting NAT properties & changing applications a little.• STUN• TURN
– Changing NAT a little & applications a lot.• MIDCOM, NSIS• UPNP
– Other approaches.• Manual configuration.• Tunneling
ALGs
• Changing Applications as is. Changing NATs a lot.– Idea is that NAT should be transparent to applications. Changing applications
is not realistic as some have already been deployed.
• What is an Application Level Gateway:– It is a piece of software that
• Understands the application level protocol it is designed to work with.• Interacts with a NAT (or firewall) to setup bindings/filtering states.• Interacts with the application level protocol to rewrite/translate data.
– ALGs operations are not standardized. • Their behavior is implementation specific.• Their implementation is specific to the type of NAT they are associated to.
– ALGs can be implemented as proxies.– ALGs can be implemented as a part of stateful packet filters.– Client side.
NAT
FTPALG
Others
Generic ALG Layer
ALGs examples
• FTP ALG (called kernel proxy) in IPFilter.– Packet based in kernel.
• map fxp0 192.168.0.0/24 � 157.159.100.54/32 proxy port ftp ftp/tcp
– ALG only used • For segments with data.
• For connections specified in configuration (dst port 21).
Conf
157.159.100.54 157.159.11.37TCP 49365 21 [SYN]
157.159.11.37 192.168.0.3 TCP 21 49365 [SYN, ACK]
192.168.0.3 157.159.11.37TCP 49365 21 [SYN]
MAP 192.168.0.3 49365 <- -> 157.159.100.54 49365 [157.159.11.37 0]
STATE
157.159.11.37 157.159.100.54 TCP 21 49365 [SYN, ACK]
ALGs examples
• FTP ALG (called kernel proxy) in IPFilter.– Packet based in kernel.
• map fxp0 192.168.0.0/24 � 157.159.100.54/32 proxy port ftp ftp/tcp
– Handled commands• PORT (forward) + PASV/EPSV (backward)
Conf
157.159.100.54 157.159.11.37FTP 49365 21 Request: PORT157,159,100,54,192,214NAT
FTPALG
Others
Generic ALG Layer
157.159.11.37 192.168.0.3FTP 21 49365 Response: 200 PORT command successful.
192.168.0.3 157.159.11.37FTP 49365 21 Request: PORT 192,168,0,3,192,214
MAP 192.168.0.3 49365 <- -> 157.159.100.54 49365 [157.159.11.37 0]
STATE
STATE
157.159.11.37 192.168.0.3TCP 20 49366 [SYN]
157.159.11.37 157.159.100.54 TCP 20 49366 [SYN]
MAP 192.168.0.3 49366 <- -> 157.159.100.54 49366 [157.159.11.37 0]
157.159.11.37 157.159.100.54FTP 21 49365 Response: 200 PORT command successful.
ALGs examples
• SIP ALG Siproxd before v0.5.2– Acts as a transparent proxy for SIP traffic.– Interacts with iptable/ipchain to NAT RTP traffic.
NAT
SIPALG
Others
Socket Layer
157.159.100.54 157.159.100.55 UDP5060 5060INVITE sip:[email protected]: 157.159.100.54:5060Via: 192.168.4.5:5067From: <sip:[email protected]>(c): IN IP4 157.159.100.54(m): audio 7072 RTP/AVP
157.159.100.55 157.159.100.54 UDP5075 5060Status: 100 TryingVia: 157.159.100.54:5060Via: 192.168.4.5:5067
192.168.4.5 157.159.100.55 UDP5067 5060 INVITE sip:[email protected]: 192.168.4.5:5067From: <sip:[email protected]>(c): IN IP4 192.168.4.5(m): audio 5045 RTP/AVP
157.159.100.55 192.168.4.5 UDP5060 5067Status: 100 TryingVia: 192.168.4.5:5067
192.168.4.5 5045 <- -> 157.159.100.54 7072
STATECONF
ALGs examples
• SIP ALG Siproxd before v0.5.2
NAT
SIPALG
Others
Socket Layer157.159.100.54 157.159.100.55 UDP5060 5075ACK sip:[email protected]: 157.159.100.54:5060Via: 192.168.4.5:5067From: <sip:[email protected]>
157.159.100.55 157.159.100.54 UDP5020 7072RTP
192.168.4.5 5045 <- -> 157.159.100.54 7072
192.168.4.5 157.159.100.55 UDP5067 5060ACK sip:[email protected]: 192.168.4.5:5067From: <sip:[email protected]>
157.159.100.55 192.168.4.5 UDP5020 5045RTP
192.168.4.5 157.159.100.55 UDP5045 5020RTP
157.159.100.54 157.159.100.55 UDP7072 5020 RTP
157.159.100.55 157.159.100.54 UDP5075 5060Status: 200 OKVia: 157.159.100.54:5060Via: 192.168.4.5:5067From:<sip:[email protected]>(c): IN IP4 157.159.100.55(m): audio 5020 RTP/AVP
157.159.100.55 192.168.4.5 UDP5060 5067Status: 200 OKVia: 192.168.4.5:5067From:<sip:[email protected]>(c): IN IP4 157.159.100.55(m): audio 5020 RTP/AVP
STATECONF
ALGs
• Advantages– Passing through NAT/firewall does not depend on decisions external to the
NAT/firewall.– No/Little impact on applications.
• Drawbacks– Not all NATs can be changed.– Developing ALG is costly.– A limited set of applications are supported through ALGs.– ALG usually only support a subset of protocol specification (could also be an
advantage).– ALGs are not always developed with security in mind. Often assumes
honest/cooperating user.
Schedule
• What is NAT ?– NAT Classification(s)
• What problems are we trying to solve ?• Answers
– Changing NATs a lot & keeping applications as is.• ALGs
– Exploiting NAT properties & changing applications a little.• STUN• TURN
– Changing NAT a little & applications a lot.• MIDCOM, NSIS• UPNP
– Other approaches.• Manual configuration.
STUN&TURN
• Changing Applications a little. Keeping NATs as is.– Idea is to minimize changes. Changes on applications are more realistic than
changes on NATs as many are already deployed.
– Main aspects : • Identifies the type of NAT used by both parties.
• Takes advantage of behavior of certain types of NATs to perform direct communications between devices behind NATs when possible.
• In other cases use relay server.
STUN
• RFC 3489: Simple Traversal of UDP over NATs– Protocol allowing a STUN client to determine
• The type of NAT used.
• The binding used by the most external NAT.
– Architecture
Public address
Public address 1Public address 2
– Protocol• Mostly UDP based for binding requests/responses.
• Uses TCP for security features.
• Server simulates potential destination.
Binding request/response
STUN
• RFC 3489: Simple Traversal of UDP over NATs– Protocol operations.
• Determine if behind a NAT.
• Determine outmost binding.
• Determine symmetry with second request (binding change)
• Determine address restriction.– Full cone NAT if response received.
– Need further tests for other types.
Non Full Cone Example (different binding)
STUN
• RFC 3489: Simple Traversal of UDP over NATs– Protocol operations.
• Determine port restriction.– Port restricted if response not
received.
– Address restricted if response received.
– Maintain binding• Binding needs to be kept so that peer can take advantage of it.
– Too long wait without traffic: binding expiration.
Address Restricted Cone Example
– Problems solved by STUN• Full Cone: Source and/or destination behind a NAT.
– Obvious: Once binding is created by STUN server it can be used by anyone.
– Private realm address in data, Routing private realm addresses.
• Address & Port restricted Cone. Source and/or destination behind a NAT.– Not so obvious: Hole punching technique. (Port restricted Cone case presented)
STUN
• RFC 3489: Simple Traversal of UDP over NATs
Client1A1;P1
– Private realm address in data, Routing private realm addresses.
Client1 knowsClient2 public address: A5;P5
Client2 knowsClient1 public address: A3;P3
Dst=A5;P5Src=A3;P3
Dst=A3;P3Src=A5;P5
Creates stateAllowing A5;P5Packets back
Creates stateAllowing A3;P3Packets back
Client2A2;P2
Dst=A5;P5Src=A1;P1
X
No state allowingPackets from A3;P3
Dst=A1;P1Src=A5;P5
Dst=A3;P3Src=A2;P2
State allowingA5;P5 PacketsBack is used
– STUN and TCP• Must establish connection server and to peer with the same (Aint; Pint).
– Otherwise the binding will be different.
• Inbound filtering is more thorough.– Matching (Adst; Pdst) of outbound packets is no longer sufficient.
STUN
• RFC 3489: Simple Traversal of UDP over NATs
Client1A1;P1
Client1 knowsClient2 public address: A5;P5
Client2 knowsClient1 public address: A3;P3
Dst=A5;P5Src=A3;P3
Dst=A3;P3Src=A5;P5
Creates stateAllowing A5;P5Packets backIf they match Outbound connection
Creates stateAllowing A3;P3Packets backIf they match Outbound connection
Client2A2;P2
Dst=A5;P5Src=A1;P1
X
No state allowingPackets from A3;P3
Dst=A3;P3Src=A2;P2
Different Sequence number/No ACKSYN segmentDropped.
X
STUN extensions
• draft-ietf-behave-rfc3489bis draft. Session Traversal Utilities for NATs– Document no longer defines NAT categories.– Document no longer defines what STUN can be used for. This is delegated to
“usage“ documents:• NAT classification: draft-ietf-behave-nat-behavior-discovery-??• ICE specifies how SIP should use STUN&TURN: draft-ietf-mmusic-ice-??.• TURN: draft-ietf-behave-turn-??.txt. See next slides.
– Support for TCP.– Enhanced security.
• STUN for TCP (various proposals)– Difficulties:
• Guess sequence numbers without direct communication with peer.
• Guess Pext if NAT is symmetric or non compliant (Aext is often fixed).– Some NAT use linear Pext allocation.
– With random allocation, birthday paradox can be exploited to find match by initiating hundreds of connections on both sides.
– Using ICMP error messages or server spoofing.
TURN
• draft-ietf-behave-turn draft. Traversal Using Relay NAT.– Used when other alternatives don’t work.– Uses an intermediate proxy server.– Protocol between Client and Server is STUNv2 with TURN specific
attributes.
1- Requests address binding(allocate request message)
2 – provides address binding(allocate response message)
5 – sends to peer(send message)
3 – Requests address binding
4 – provides address binding
6 – relays to peer(UDP packet)
7 – sends to client(UDP packet)
8 – sends to client(data message)
TURN
• What is the difference with a traditional proxy ?– Session based application address allocation.
• Allocate/Refresh/Channelbind request/response messages allow client to decide when address is allocated and released.
• With UDP a traditional proxy can attribute a different address for every packet.
• With TCP a traditional proxy address allocation depends on timer constraints.
– Particular allocation properties support• Requested props attribute allows requesting some relations between allocations
from same client (parity/port preservation/…).
• With traditional proxy, allocation is random at best.
– One to many support• Multiplexing several communications between one client and several peers.
TURN
• What is the difference with a traditional proxy ?– (Application level) Protocol agnostic
• Supports any protocol (UDP/TCP) on the client – TURN server leg.
• Only supports UDP on the turn server – peer leg.– Does not suppose to know TCP state of recipient.
• Support ICMP error messages on both legs– On client-server legs the protocol supports attribute allowing ICMP information from the
peer to be relayed.
– On server-peer leg, the protocol relays ICMP messages from the client.
– More compact coding• Low overhead: Only data + peer address in send/data messages.
• Even lower overhead: Channel support: short identifier avoiding need to provide peer address in every “send/data“ message.
TURN
• draft-ietf-behave-turn-??.txt draft. Traversal Using Relay NAT. – Advantages
• One size fits all. Works with any configuration.• Well understood architecture.
– Drawbacks.• Cost (servers + bandwidth).• Triangular routing: increased latency.• QoS Support.• Confidentiality/integrity of communications (especially if servers are not controlled
by service provider like in p2p networks).
– Similar alternatives• SOCKS (RFC 1928).
Schedule
• What is NAT ?– NAT Classification(s)
• What problems are we trying to solve ?• Answers
– Changing NATs a lot & keeping applications as is.• ALGs
– Exploiting NAT properties & changing applications a little.• STUN• TURN
– Changing NAT a little & applications a lot.• MIDCOM, NSIS• UPNP
– Other approaches.• Manual configuration.• Tunneling
Signaling based Approaches
• Changing Applications a little, changing NAT a little.– Idea is to minimize changes. Changes on applications are more realistic than
changes on NATs as many are already deployed.– Many NATs can be programmed/configured remotely.
• Signaling protocols classification– Path coupled signaling:
• Signaling follows same path as data.
– Path decoupled signaling: • Signaling can follow different path as data.
– Path targeted signaling: • Assumes signaling entities as well as topology are known in advance.
– Path directed signaling: • Does not assume knowledge of signaling entities nor of topology.
Signaling based Approaches
– End to end: • Signaling goes from data sender to data receiver.
– Local: • Sender and receiver are not expected to cooperate.
• Three main proposals:– MIDCOM:
• End to End, path decoupled, path targeted.– NSIS:
• End to End, path coupled, path directed.– UPNP:
• Local, path decoupled, path directed.
MIDCOM
• MIDdleboxes COMmunication. Main definitions: RFC 3303/3304/5189.– Standard track. SNMPv3 based protocol. RFC 5190.– Experimental. NEC SIMCO protocol. RFC4540.
• Main Scenario:
ProxyA4;P4
• Communications supported:– Synchronous transactions
• Configuration requests: Implemented using SNMP SET REQUEST PDUs.• Configuration monitoring: Implemented using SNMP GET REQUEST/ GET
RESPONSE PDUs.
– Asynchronous transactions• Events: Implemented using TRAP PDUs.
Client1A1;P1
Client2A2;P2
MIDCOMMIDCOM
MIDCOM
• MIDCOM MIB
midcomConformancemidcomNotificationsmidcomObjects
midcomConfig midcomMonitoringmidcomTransaction
midcomRuleTable
midcomRuleEntry
midcomRuleInternalIpAddrmidcomRuleInternalIpPrefixLengthmidcomRuleInternalPortmidcomRuleExternalIpAddrmidcomRuleExternalIpPrefixLengthmidcomRuleExternalPortmidcomRuleInsideIpAddrmidcomRuleInsidePortmidcomRuleOutsideIpAddrmidcomRuleOutsidePortmidcomRuleLifetimemidcomRuleRowStatus
midcomRuleOwnermidcomRuleIndexmidcomRuleAdminStatusmidcomRuleOperStatusmidcomRuleStorageTypemidcomRuleStorageTimemidcomRuleErrormidcomRuleInterfacemidcomRuleFlowDirectionmidcomRuleMaxIdleTimemidcomRuleTransportProtocolmidcomRulePortRangemidcomRuleInternalIpVersionmidcomRuleExternalIpVersionInternal Inside Outside External
MIDCOM
• Advantages– Builds on widely used protocol.– MIB definition overlaps existing many proprietary/standardized MIBs (e.g.
NAT MIB, FIREWALL MIB).– Requires few changes to existing middleboxes.– Requires few changes to end device in proxy scenario.
• Drawbacks– Could not find a proper implementation (except NEC SIMCO implementation).– Requires topology knowledge.– SNMPv3 complexity.– Does not work when proxy and middleboxes are not in the space addressing
realm.
NSIS
• From Next Steps in Signaling working group at IETF– GIST: General Internet Signaling Transport, draft-ietf-nsis-ntlp-17.
• Expected to carry generic signaling information on the same path as data.
– NAT/Firewall NSIS Signaling Layer Protocol (NSLP), draft-ietf-nsis-nslp-natfw-20.txt.
• Expected to carry FW/NAT related information/configuration requests/responses.
• Overall Architecture
NATFW
Applications
GIST
TCP/IP
NATFW
Configuration Tool
GIST
TCP/IP
NAT/FW
NSLP
NTLP
NATFW
Applications
GIST
TCP/IP
NATFW
Configuration Tool
GIST
TCP/IP
NAT/FW
NSIS
• GIST - General Internet Signaling Protocol.– Expected to support various types of services configuration (NAT/FW, QoS,…)– Signaling can be initiated by the GIST entity closer to the data source.– Two GIST entities maintain an association when
• They implement the same NSLP and are adjacent from that NSLP point of view.• NSLP data goes through both entities.• Soft state timeout value has not expired, State has not been explicitly suppressed.
– NSLP data flows between two NSLP entities only once a GIST association is created.
– GIST entities are topology blind.• Don’t know addresses of neighboring GIST entities a priori.• Discovery is made using signaling (Query) message using original source, destination
addresses and diffserv codepoint so that is follows same path as data.• GIST Entities capture messages with GIST identifier (UDP port & magic number).
– NSIS unaware NAT traversal• NAT presence can be detected through address change observation.• No guarantee that associations can be created.
NSIS
• NATFW NSLP - NSIS Signaling Layer Protocol– Transported in GIST DATA messages.– Three main types of messages:
• CREATE (C): Initiated by the data source to setup address mapping and learn chosen address.
• EXTERNAL (E): Initiated by the data destination to setup address mapping and learn chosen address.
• RESPONSE (R): Response with requested configuration results.
– Information Elements• MRI (from NTLP), Message Routing Information (C, E, R). Used to
– Describe signaling source and destination.– Describe rule to install.
• NATFW DTI data terminal information (E). Used to describe – receiver protocol and port– sender protocol, port and IP address (most of the time unknown).
• NATFW EFI extend flow information (C). Used to describe action and port options.• NATFW EA external address (R). Used to describe reserved public IP address/port.• NATFW SI Session Identifier, SL Session lifetime …
NSIS
• NSIS exchange
DataInitiator
NSISForwarder
DataResponder
NSISForwarder
CreateMRI: UDP, DiIP, DiPort, PuIP2, PuPort2EFI: Allow
CreateMRI: UDP, PuIP1, PuPort1, PuIP2, PuPort2EFI: Allow
CreateMRI: UDP, PuIP1, PuPort1, PuIP2, PuPort2EFI: Allow
NATpubIP1,prIP1
ResponseMRI: UDP, PuIP1, PuPort1, PuIP2, PuPort2EA: PuIP1, PuPort1
NATpubIP2,prIP2
ExternalMRI: UDP, DrIP, DrPort, PuIP3, PuPort3DTI: UDP, *, *
ResponseMRI: UDP, DrIP, DrPort, PuIP3, PuPort3EA: PuIP2, PuPort2
ResponseMRI: UDP, PuIP1, PuPort1, PuIP2, PuPort2EA: PuIP1, PuPort1
ResponseMRI: UDP, DiIP, DiPort, PuIP2, PuPort2EA: PuIP1, PuPort1
DiIP,DiPort DrIP,DrPort
NSIS
• NSIS advantages– Generic solution for several problems.– Supports routing changes/asymmetry.
• NSIS drawbacks– Heavyweight.– Requires applications instrumentation.– Only really works if all NATs are at least GIST instrumented.– How much trust can you put in clients ? Embedded Device
UPnP
• UPNP – Universal Plug and Play– Specifies a set of protocols for networked device/services configuration.
– Devices model:
– Four phases:
• Addressing:Getting a unique address either using DHCP or Auto-IP.
• Discovery:IP multicast/UDP/HTTP/SSDP+UPnP– Either Control point/device initiated (notify/request-response, byebye)
– Each device/service provides:
» Description. What the service/device is supposed to do.
» Identifier. Unique value for network.
» Description URL: link that can be used to access description.
Root device
ServiceService
UPnP control point
Application
UPnP Stack
UPnP Control APIService
UPnP Stack
Configuration Tool
UPnP
– Four phases:• Description: IP/TCP/HTTP/UPnP
– Defines devices, embedded devices.– For each device defines available services.– Services are described using:
» Available actions and types of parameters, direction of parameters.» State variables describing state of service/device.
– UPnP forum defines services/devices specifications in standardized documents.– Service definitions are often not transported between device and control point
when standard.• Control: IP/TCP/HTTP/SOAP/UPnP
– Supports service invocation and state variable query.– Service Invocation:
» Action in SOAPACTION header.» Action + variables in UPnP format.
– Variable Query:» Query in SOAPACTION header.» Variable in UPnP format.
• Events.
UPnP & NAT example
• Thread between MS WinXP and Linksys WRT54G– Discovery
—— WIN XP ——M-SEARCH * HTTP/1.1Host:239.255.255.250:1900ST:upnp:rootdeviceMan:”ssdp:discover”MX:3—— WRT54G ——HTTP/1.1 200 OKST:urn:schemas-upnp-org:service:WANIPConnection:1USN:uuid:000625d8-095f-0006-25d8-095f0232aa18::urn:schemas-upnp-org:service:WANIPConnection:1Location: http:// 192.168.1.1:5431/dyndev/uuid:000625d8-095f-0006-25d8-095f0032aa18Server: Custom/1.0 UPnP/1.0 Proc/VerEXT: Cache-Control:max-age=1800DATE: Mon, 29 Nov 2004 16:58:01 GMT
—— WIN XP ——GET /dyndev/uuid:000625d8-095f-0006-25d8-095f0032aa18 HTTP/1.1HOST: 192.168.1.1:5431ACCEPT-LANGUAGE: en
– Description
Source: Zac Bowling « Implementing UPnP »
InternetGatewayDevice
UPnP & NAT example
• Thread between MS WinXP and Linksys WRT54G
—— WRT54G ——HTTP/1.0 200 OK<?xml version=”1.0??><root xmlns=”urn:schemas-upnp-org:device-1-0?><specVersion> <major>1</major> <minor>0</minor> </specVersion><device><deviceType>urn:schemas-upnp-org:device:InternetGatewayDevice:1</deviceType><UDN>uuid:000625d8-095f-0006-25d8-095f0032aa18 </UDN><deviceList> <device><deviceType>urn:schemas-upnp-org:device:WANDevice:1</deviceType><UDN>uuid: 000625d8-095f-0006-25d8-095f0132aa18 </UDN><deviceList> <device><deviceType>urn:schemas-upnp-org:device:WANConnectionDevice:1</deviceType><UDN>uuid: 000625d8-095f-0006-25d8-095f0232aa18 </UDN><serviceList><service><serviceType>urn:schemas-upnp-org:service:WANIPConnection:1</serviceType><serviceId>urn:upnp-org:serviceId:WANIPConn1</serviceId><controlURL>/uuid: 000625d8-095f-0006-25d8-095f0232aa18/WANIPConnection:1 </controlURL><SCPDURL>/dynsvc/WANIPConnection:1.xml</SCPDURL></service></serviceList></device></deviceList></device></deviceList></device></root>
WANDevice
WANConnectionDevice
WANIPConnection
UPnP & NAT example
• Thread between MS WinXP and Linksys WRT54G
. . .<action><name>AddPortMapping </name><argumentList><argument> <name> NewRemoteHost </name> <direction>in</direction> <relatedStateVariable>RemoteHost</relatedStateVariable> </argument><argument> <name> NewExternalPort </name> <direction>in</direction><relatedStateVariable>ExternalPort</relatedStateVariable> </argument><argument> <name> NewProtocol </name> <direction>in</direction><relatedStateVariable>PortMappingProtocol</relatedStateVariable> </argument><argument> <name> NewInternalPort </name> <direction>in</direction><relatedStateVariable>InternalPort</relatedStateVariable> </argument><argument> <name> NewInternalClient </name> <direction>in</direction><relatedStateVariable>InternalClient</relatedStateVariable> </argument><argument> <name> NewEnabled </name> <direction>in</direction><relatedStateVariable>PortMappingEnabled</relatedStateVariable> </argument><argument> <name> NewPortMappingDescription </name> <direction>in</direction><relatedStateVariable>PortMappingDescription</relatedStateVariable> </argument><argument> <name> NewLeaseDuration </name> <direction>in</direction><relatedStateVariable>PortMappingLeaseDuration</relatedStateVariable> </argument></argumentList></action>. . .
– WANIPConnection:1 Service description from standard.
UPnP & NAT example
• Thread between MS WinXP and Linksys WRT54G
—— WIN XP ——POST /uuid: 000625d8-095f-0006-25d8-095f0232aa18/WANIPConnection:1 HTTP/1.1HOST: 192.168.1.1:5431SOAPACTION: “urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping”
<s:Envelope xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/ ”s:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/ “><s:Body><u: AddPortMapping xmlns:u=”urn:schemas-upnp-org:service:WANIPConnection:1?><NewRemoteHost ></NewRemoteHost><NewExternalPort >27360</NewExternalPort><NewProtocol >UDP</NewProtocol><NewInternalPort >8615</NewInternalPort><NewInternalClient >192.168.1.101</NewInternalClient><NewEnabled >1</NewEnabled><NewPortMappingDescription >msmsgs (192.168.1.101:8615) 27360 UDP </NewPortMappingDescription><NewLeaseDuration >0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>
– Control – adding port mapping.
UPnP & NAT example
• Thread between MS WinXP and Linksys WRT54G
—— WRT54G ——HTTP/1.1 200 OKDATE: Mon, 29 Nov 2004 16:58:03 GMTConnection: Keep-AliveServer: LINUX/2.4 UPnP/1.0 BRCM400/1.0Content-Length: 289Content-Type: text/xml; charset=”utf-8?EXT:
<?xml version=”1.0??><s:Envelope xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/ ”s:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”><s:Body><m:AddPortMappingResponse xmlns:m=”urn:schemas-upnp-org:service:WANIPConnection:1?></m:AddPortMappingResponse></s:Body></s:Envelope>
UPnP
• Advantages– Widely available.– “Relatively” lightweight.– Solves the need to know middleboxes by using multicast.
• Drawbacks– Requires instrumented applications.– No authentication. No security.– Inter-network protocol. UPnP packets initial TTL=4.– How much trust can you put in clients ?
• Alternatives– DPWS – Devices Profiles for Web Services.
• Web services adaptation of UPnP. Supports WS Security.• Implemented in MS Vista.
– NAT Port Mapping Protocol (NAT-PMP)• Binary protocol over UDP to default gateway.• Implemented in Apple OS X/Apple products.
Schedule
• What is NAT ?– NAT Classification(s)
• What problems are we trying to solve ?• Answers
– Changing NATs a lot & keeping applications as is.• ALGs
– Exploiting NAT properties & changing applications a little.• STUN• TURN
– Changing NAT a little & applications a lot.• MIDCOM, NSIS• UPNP
– Other approaches.• Manual configuration.• Tunneling
By Hand
• By hand– Most NATs support port mapping
commands.• A port map is a static NAT allocation:
(Internal_port;Internal_addr)
<-> (External_port;External_addr)
• Associated with a filtering rule allowing inbound traffic toward(External_port;External_addr)
– The user then configures its internal tools
• To use the Internal_port .
• To advertise the External_port .No External_addr because this device only supports a single external address
NATPrIP4
PubIP2
Tunneling
• Manual tunnels setup.– Tunnel head and/or tail must have public IP address.– Source and destination must be in different address realm.– IPSEC*/L2TP/…
SourceprIP1
DestinationPrIP4
• Alternatives: .– RFC 3948: UDP Encapsulation of IPsec ESP Packets.
Tunneling
• RSIP (RFC 3102/3103).– RSIP server usually collocated with NAT (must have a public and a private
address).
RSIP ClientprIP1
ServerPubIP2RSIP Server
NATprIP2/PubIP1
• Outbound traffic scenario.
Register_request
Register_response, ClientID
Assign_request, ClientID
Assign_response, PubIP1, PubPort1
Tunnel Creation
[PrIP1->prIP2;][pubIP1->PubIP2][pubIP1->PubIP2]
[PrIP2->prIP1;][pubIP2->PubIP1]
[pubIP2->PubIP1]
Tunneling
RSIP ClientprIP1
ServerPubIP2RSIP Server
NATprIP2/PubIP1
• Inbound traffic scenario.
Register_request
Register_response, ClientID
Listen_request, ClientID, PubPort1
Listen_response, PubIP1, PubPort1
Tunnel Creation
[PrIP2->prIP1;][pubIP2->PubIP1]
[pubIP2->PubIP1]
[PrIP1->prIP2;][pubIP1->PubIP2][pubIP1->PubIP2]
DNS based
• Two Way NAT (RFC 2663).– NAT implements DNS ALG.– Internet device register private address with DNS.– DNS ALG maps unique name to dynamically allocated public address.
• Extension: Twice NAT (RFC 2663) for realms with overlaps.
PrIP1 PubIP5PubIP1
Query UPDATE, PrIP1, [email protected]
Query A, [email protected]
Answer CNAME, [email protected], pubIP2prIP1<->PubIP2
[pubIP5,pubPort5;pubIP2,pubPort2][pubIP5,pubPort5;prIP1,pubPort2]
[prIP1,pubPort2;pubIP5,pubPort5]
[pubIP2,pubPort2;pubIP5,pubPort5]
Answer UPDATE, PrIP1, [email protected]
Summary
• Techniques comparison– Realm specific identification information in application data
• Provide ability to learn public ID information: STUN; NSIS; MIDCOM; UPNP.• Provide ability to setup public ID information: TURN; NSIS; MIDCOM; UPNP; • Hide NAT presence: Tunnels.• Use application level knowledge to modify application data: ALGs.• Use public IP address: RSIP.
– NAT based information cannot be accessed• Hide NAT presence: Tunnels, RSIP. • Treat encrypted traffic differently: ALGs.
– NAT based information cannot be changed• Hide NAT presence: Tunnels, RSIP.• Treat encrypted traffic differently: ALGs.
– Internal realm specific ID information is unknown in public realm.• Advertise binding through E2E protocol: DNS, NSIS, MIDCOM.• Use relay with public ID information: Proxies, TURN.
Summary
• Techniques comparison– Internal devices open ports unknown to NAT
• Assume they are open – no NATPT: DNS.• Assume favorable NAT mapping behavior: STUN.• Traffic always outbound: Proxies; TURN.• Provide ability to setup NAT mapping: TURN; NSIS; MIDCOM; UPNP; RSIP.• Hide NAT presence: Tunnels.• Use application level knowledge to build mapping: ALGs.
– NAT filtering inbound traffic.• Don’t filter inbound traffic: DNS.• Assume favorable NAT filtering behavior: STUN.• Traffic always outbound: Proxies; TURN.• Provide ability to open pinholes: NSIS; MIDCOM; UPNP.• Hide NAT presence: Tunnels.• Use application level knowledge to open pinholes: ALG.
Summary
• Techniques comparison– Fragmentation hides transport level information
• Implement NAT that reassemble packets.• Implement NAT that translates IDs.
– Protocols require specific port/port relationships.• There is always a possibility for conflicts.• Provide ability to setup public ID information : TURN; MIDCOM; NSIS; UPNP;
RSIP.• Assume all ports are available No NATPT: DNS; • Hide NAT presence; Tunnels.• Use application level knowledge to build mapping: ALGs.
– Asymmetric routing between data source and data destination.• Use path coupled protocol: NSIS.
– Route changes between data source and data destination.• Use data initiated protocol with soft states: NSIS.
Summary
• Techniques comparison
XXXXXXDNS
XXXXXXXXXXXBy hand
XXXXXXXXXXTunneling
X
X
X
X
X
X
X
#5
X
X
X
X
X
X
X
#6 #7
X
X
X
X
X
#8
X
#3
X
X
X
X
#4
XXXXXUPNP
XXXXNSIS
XXXXMIDCOM
XXXXXXProxies
XXXXTURN
XXXXXSTUN
XXX
Maturity#9
XXX
Popularity
XXALGs
#2#1Solution/
Problem
NA
T d
epen
den
t
Top Related