Embed Size (px)
Citation preview
28
Realtime Multimedia in Presence of Firewalls and
Network Address Translation (NAT)
Knut OmangIfi/Energima14 Sep, 2020
29
Overview● Solving the traversal problem from a ’network owner’ perspective
● Quick overview of some protocols in use for real-time multimedia
– SIP/SDP
– Other protocols that struggles with firewall/NAT
● Details of SIP/SDP
– Firewall and NAT traversal examples with SIP/SDP
● IPv6 to the rescue?
● Firewall and NAT support in the Linux kernel
– Iptables and ebtables
– Routing
– Traffic control using tc● qdiscs and filters● netem
30
Solving the traversal problem from a ’network owner’ perspective
● Discovery methods so far:– what can we achieve if we have no influence over the network layout or
services offered
● What if we control the network - other approaches we can use?– Extending the firewall/NAT functionality?
– Let firewall route some traffic via special ‘gateways’ (= delegate)
● Make the firewall collaborative, trusting (some…) clients
● Transparently handle more protocols (also at higher levels such as session layer)
31
Collaborative: Controlled Firewalls● Adding a separate firewall control protocol● Client requests opening of ports in firewall● Examples: SOCKS, UPnP (“Universal Plug and Play”)
● About trusting clients on local network
● UPnP: Clients must trust any device replying to broadcast
32
Application Level Gateways (ALG)• Server/service in connection with firewall
– Allowed in FW rules
– Controls firewall through control protocol
– Or built into firewall
• Old proto example: ftp
• Some VPN gateways
• Session Border Controller:
– SIP ALG
– Terminates traffic in both directions
– Masks real source/destination at the session layer
33
Application Level Gateways (ALG)● Server/service in connection with firewall
– either built-in (plugin) or separate service
● Sometimes called ‘application level proxy’
● Protocol examples: – ftp (file transfer protocol)
– SIP (Session Initiation Protocol) [Often called Session Border Controller (SBC)]
– H.323
– RTSP (Real Time Streaming Protocol)
34
ALGs vs simple firewalls?
Firewalls often dedicated hardware - long lived compared to other infrastructure!
● IP,UDP,TCP: Stable protocols, modest changes– easy to maintain in firewalls
● Contrast with many upper level protocols: Lots of features, lots of development => lots of bugs/fixes
● Linux maybe altering the picture as more FW/NAT devices are powered by Linux, and are software upgradable?
● ALGs must be trusted: If encrypted data, they might need to decrypt
35
Some protocols exposed to firewall/NAT issues
• FTP (File Transfer Protocol)
• SIP (Session Initiation Protocol)
• H323 (ITU – telecoms standard)
• Skype (proprietary peer-to-peer)
• XMPP (Extensible Messaging and Presence Protocol)
• IPsec (AH/ESP/Tunnel mode)
36
Session Initiation Protocol (SIP)• HTTP inspired protocol for session management:
– Registration/location information– Establish (and take down) session– Multiple channels (voice,video,ppt,chat,…)– Add/remove participants– Renegotiate media– ’Forking’– Bridge to POTS (Plain Old Telephony Systems)
• Session layer running on top of different protocols (UDP,TCP,…)• VoIP (Voice over IP) usually means SIP based• Lots of equipment available/being developed that uses SIP in some
form• Also ’embraced’ by telecoms by means of IMS
37
Skype and firewall/NAT
• Based on software developed for Kazaa (early file sharing: Napster)– Per-to-peer intended for file sharing
– Got much ’for free’ from P2P..
– Proprietary and encrypted -> tech likely lives on in MNP24..
– Solves NAT traversal with similar strategies as STUN/TURN and tunnelling if necessary
– Relaying via (and relying on) private users
– Breakdown in 2007 thought to be due to diminishing number of non-fw/NAT’ed users
38
WebRTC● Open source APIs initiated by Google to make it easier to implement
peer-to-peer unified communication from web browsers.
● Supports different underlying protocols for signalling and media, for instance SIP over Websockets for signalling and STUN, TURN and ICE for discovery
39
Unified communication in the COVID-19 era
Examples of commercial, cross platform “conference” type collaboration software:
● Zoom
● Microsoft Teams (evolution from Skype and other products)
● Google Meet (former Hangouts)
40
Unified communication in the COVID-19 era
Open source conferencing:
● BigBlueButton– Used by Linux Plumbers Conference (LPC) ‘2020:
https://lwn.net/Articles/830436/
● Jitsi– Evaluated runner-up for LPC’2020
(https://lwn.net/Articles/815751/)
41
Chat applications...
Proprietary:
● Facebook Messenger
● Telegram
● Slack
● Discord
● ...
Open source:
● IRC
● Signal
● Mattermost
● …..
42
Protocols in use:● Google Meet, Discord, Facebook Messenger: WebRTC
● Zoom:– Indicate they only use peer-to-peer for 2-person calls (WebRTC?)
– Larger conferences appear to be solely client-server based (proprietary)
● Microsoft Teams: MNP24 - evolution from ‘Skype consumer code’– e.g. proprietary, but uses similar techniques as STUN, TURN, ICE
– But ‘bridge’ that supports SIP and H.323 - likely to allow seamless use of conference equipment etc
43
IPsec
• AH (Authentication Header protocol)
– Additional header that authenticates the information in the IP header
• Ensures that the IP header information is not changed by intermediates..• Does not encrypt payload but checksums it to avoid tampering..
• ESP (Encapsulating Security Payload protocol)
– Encapsulates and encrypts a checksum of the IP payload– does not checksum/verify the IP header
• Tunnel mode: – Either or combinations of ESP/AH where the payload is a complete IP packet
with its own IP header
44
IPsec and Firewall/NAT
• AH:
– Defeats the very purpose of NAT!
• Any NAT’ed packets will be dropped..
• ESP:
– Address modifications may pass
– Port modifications lead to dropped packets!
• The port numbers are in the transport headers (UDP/TCP..) which are inside the encrypted payload!
45
IPsec and Firewall/NAT (2)
• NAT-T (RFC 3947,3948)
– Adds an additional UDP header to ESP packets– Defines port 4500 as the ipsec-nat-t port– Limited: Requires one side to have destination nat (’static’ nat)
– Defines a protocol for exchanging NAT information
• Problem:– DNAT allows a single listener– What if multiple VPNs are to communicate across the same
NAT devices?– Approach requires firewall access – not always possible
46
MSNP (MSN) and firewall/NAT
• RealTunnel used to serve MSN community with free download
– Had significant user base
• Microsoft increasingly aware of problem
• Acquired Skype in 2011 for 8.5$ bn…
• Discontinued old MSN client in 2013
• Replaced with Skype..
47
XMPP and Firewall/NAT
• Jabber
• Basis for a.o. original Googletalk, Cisco Jabber...
• Implements STUN/TURN/ICE for XMPP(++)
48
Firewalls and IPv6
• Most of the problems remains
– Open/blocked ports
– Detecting best path for media
– UDP/TCP
– QoS problems
49
NAT and IPv6?
Pros:• Avoiding renumbering:
– when changing Internet provider..
• Facilitating multi-homing– Use of multiple providers from same
domain
• Topology hiding– Preventing host counting by attackers– Router scalability
• IPv6 already old – what about host mobility?
Cons:• End-to-end routability
– All the complexity of NAT in today’s lecture..
• Much reconfiguration to do already– DHCP, DNS dynamic update
• Provider independent IP blocks– Good for switch vendors… – See RFC 5902
50
NAT and IPv6?
• 2011: Linux implementation of NAT for IPv6
• In mainline kernel from v.3.7(merged Oct.2012)
51
Some firewall/NAT RFCs...
● RFC 5389: Session Traversal Utilities for NAT (STUN) (2008)
● RFC 5766: Traversal Using Relays Around NAT (TURN) (2010)
● RFC 8445: Interactive Connectivity Establishment (ICE) (2018)
● RFC 4787: NAT Behavioral Requirements for Unicast UDP (2007)
● RFC 5382: NAT Behavioral Requirements for TCP (2012)
● RFC 5902: IAB Thoughts on IPv6 NAT (2010)
● RFC 7857: Updates to NAT Behavioral Requirements (2016)
52
Other RFCs in this area:● RFC 6146: Stateful NAT64: NAT from IPv6 clients to IPv4 servers (2011)
● RFC 3261: SIP: Session Initiation Protocol (2002)
● RFC 5411: A Hitchhiker’s Guide to the Session Initiation Protocol (SIP) (2009)
53
Our simple call example: (now with SIP)
User: per User: ida
192.168.0.81
[email protected]: 192.168.0.81:[email protected]: 192.168.20.10:4560
192.168.20.10
REGISTER sip:realsip.com
200 OK
REGISTER sip:realsip.com
200 OK
• Registration
54
Our simple call example: (now with SIP)
User: per User: ida
192.168.0.81
[email protected]: 192.168.0.81:5060
[email protected]: 192.168.20.10:5060
192.168.20.10
INVITE sip:[email protected]…m=audio 42921 RTP/AVP
200 OK…m=audio 14351 RTP/AVP
INVITE sip:[email protected]
200 OK
• Call:
192.168.0.81:42921
192.168.0.81:14351
55
A complete SIP dialoguePer IdaSIP registrar
INVITE sip:[email protected]
INVITE sip:[email protected] Trying
180 Ringing 180 Ringing Ida answers
200 OK 200 OK
ACK sip:[email protected]:5060ACK sip:[email protected]:5060
.
.
.In call…
BYE sip:[email protected]:5060BYE sip:[email protected]:5060
200 OK 200 OK
56
A SIP request with SDPINVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.168.0.81:5061;branch=z9hG4bK-32063-1-1From: "per" <sip:[email protected]>;tag=1To: <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]:5061>Max-Forwards: 70Subject: Simple CallContent-Type: application/sdpContent-Length: 186
v=0o=- 53655765 2353687637 IN IP4 192.168.0.81s=-c=IN IP4 192.168.0.81t=0 0m=audio 6001 RTP/AVP 8a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-11,16
57
A SIP request with SDP (received)INVITE sip:[email protected]:5062 SIP/2.0Via: SIP/2.0/UDP 192.168.0.84:5060;branch=z9hG4bK-ffdef4f8xc0a80054Via: SIP/2.0/UDP 192.168.0.81:5061;branch=z9hG4bK-32063-1-3From: "per" <sip:[email protected]>;tag=1To: <sip:[email protected]>Call-ID: [email protected]: 2 INVITEContact: <sip:[email protected]:5061>Max-Forwards: 69Subject: Simple CallContent-Type: application/sdpRecord-Route: <sip:192.168.0.84:5060;lr>Content-Length: 186
v=0o=- 53655765 2353687637 IN IP4 192.168.0.81s=-c=IN IP4 192.168.0.81t=0 0m=audio 6001 RTP/AVP 8a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-11,16
58
A SIP response with SDPSIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.0.81:5061;branch=z9hG4bK-32063-1-3Record-Route: <sip:192.168.0.84:5060;lr>From: "per" <sip:[email protected]>;tag=1To: <sip:[email protected]>;tag=1Call-ID: [email protected]: 2 INVITEContact: <sip:[email protected]:5062;transport=UDP>Content-Type: application/sdpContent-Length: 131
v=0o=- 53655765 2353687637 IN IP4 192.168.0.81s=-c=IN IP4 192.168.0.81t=0 0m=audio 6000 RTP/AVP 0a=rtpmap:0 PCMU/8000
59
A SIP response with SDP (received)SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.0.84:5060;branch=z9hG4bK-ffdef4f8xc0a80054Via: SIP/2.0/UDP 192.168.0.81:5061;branch=z9hG4bK-32063-1-3Record-Route: <sip:192.168.0.84:5060;lr>From: "per" <sip:[email protected]>;tag=1To: <sip:[email protected]>;tag=1Call-ID: [email protected]: 2 INVITEContact: <sip:[email protected]:5062;transport=UDP>Content-Type: application/sdpContent-Length: 131
v=0o=- 53655765 2353687637 IN IP4 192.168.0.81s=-c=IN IP4 192.168.0.81t=0 0m=audio 6000 RTP/AVP 0a=rtpmap:0 PCMU/8000
60
Linux packet handling toolbox● Packet filtering (iptables,ebtables → nft (bpfilter?) )
● Connection tracking (conntrack)
● Packet classification and traffic shaping/control (tc)
● Routing/forwarding (ip route)
● Test tools (netem, tcpdump, wireshark, log targets,…)
61
Why is this interesting?● Linux powers most of the world’s firewalls today
● Cloud: – SDN (Software Defined Networking)
– Virtual machines
– Nested virtual machines
– Containers
62
netfilter packet flow..
63
iptables● able to filter where packets are passed at the IP protocol level
● 5 tables: filter, nat, mangle, raw, security
● filter for typical filtering of packets– FORWARD, INPUT and OUTPUT
● nat for network address translation– PREROUTING (incoming)
– POSTROUTING (forwarded outgoing)
– OUTPUT (packets coming from the host itself)
● mangle: modify the packets before subject to other rules
64
ebtables● similar to iptables but at the link layer
● filter, forward, nat on ethernet addresses
● send “upwards” in stack
● can be used to implement special handling in virtual bridges
● often IP layer does not see packet at all
● useful in virtualization:– host want's to interfere with bridged traffic from guests
65
Packet filtering - ongoing evolution● nftables (nft)
– iptables replacement, started 2009.
– more coherent syntax, transactions
– easier to extend
– easier to write efficient rule sets
– default for firewalld from Fedora 32
● eBPF (extended Berkeley Packet Filter)– a small byte code executor within the kernel
– simple programming language
– security? “Verifier”, simple language,…
– bpfilter: Netfilter implementation in eBPF
66
Linux routing/forwarding
[root@ukvm01 ~]# ip route show
default via 192.168.167.1 dev eth0 proto static metric 100
192.168.167.0/24 dev eth0 proto kernel scope link src 192.168.167.101 metric 100
[root@ukvm01 ~]# ip route show table local broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 192.168.167.0 dev eth0 proto kernel scope link src 192.168.167.101 local 192.168.167.101 dev eth0 proto kernel scope host src 192.168.167.101 broadcast 192.168.167.255 dev eth0 proto kernel scope link src 192.168.167.101
67
ip route● Table space defined by
/etc/iproute2/rt_tables:
● May add own table names or just use number:
# # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 mytable
[root@ukvm01 ~]# ip route add 192.168.1.0/24 dev eth0 table 23 [root@ukvm01 ~]# ip route show table 23 192.168.1.0/24 dev eth0 scope link
68
Connection tracking: conntrack● Built into the kernel
– optional user level tool to display: conntrack
● All connections tracked by the kernel
● Usable by firewall and NAT functionality
● Allows optimization to only inspect packets that does not belong to a connection
69
Traffic shaping and control: tc● Ability to discriminate traffic
● Traffic classes– Examples: High bandwidth, low latency
– Allow setup to get resources distributed among usages
– Prioritize traffic as needed
– “Easy” to combine with packet filtering (iptables)
70
Network namespacesAllows virtualization of network for a process (or set of processes..)
● No network at all (only loopback)
● Specifically configured, separate network device instance(s)
● Own routing tables, etc etc..
● Container systems use it...
[root@ukvm01 ~]# ip netns list[root@ukvm01 ~]# ip netns add myns[root@ukvm01 ~]# ip netns listmyns[root@ukvm01 ~]# ip netns exec myns bash[root@ukvm01 ~]# ip link show1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
71
Summary● RT multimedia protocols
– demands good RT QoS - peer to peer!
– Particularly susceptible to firewalls and NAT
– Can generate very complex initiation scenarios
● Firewalls and NAT– Firewalls and NAT can to some extent
be characterized● potential for issues and problems● limited observability in the general case!
– Lots of protocols exhibit similar problems
– No rescue in IPv6….
● Linux and firewall/NAT– Linux powers many of the worlds firewalls
– Readily available to experiment with and deploy
– Lots of development going on
– Lots of tools and knowledge available
