schedule nat/firewalls and applications phd thesis, enst

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







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







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






– 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


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



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







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


. . .<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


—— 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


—— 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







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

schedule nat/firewalls and applications phd thesis, enst

Documents