Tunneling for Secure Communication: The Aerospace Clinic 2002 Team

1. The Aerospace Clinic 2002 Team Members Nick Hertl (Project Manager) Will Berriel Richard Fujiyama Chip Bradford Faculty Advisor Professor Michael Erlinger Aerospace Liaisons Joseph Betser, PhD Rayford Sims

2. Overview: • Background Information • Alternatives to Tunnel • Technical Approach • Completed work • Future work • Questions

3. Background • TCP/IP • Firewalls • Security • BEEP • IDXP • Tunnel

4. TCP/IP • Main protocols used over the Internet • Provides reliable, full-duplex, peer-to-peer communication • Most current application protocols use this directly: HTTP (web), SMTP (email), etc. • Multiple connections to the same machine are handled using ports

5. Firewalls • Set of rules to restrict TCP/IP traffic • Can filter by any combination of source and destination IP address and port • Rule sets are usually static—not easy to handle "only allow Joe's messages through" if Joe doesn't always connect from the same computer

6. Security • Firewalls attempt to ensure this • To allow Joe access, he must first prove he is who he claims to be (login/authenticate) • SSH Tunnel is a common solution—handles authentication • SSH not without drawbacks, however (discussed later) • Tunnel is a better solution, but first...

7. BEEP • General framework for rapidly creating application-level protocols • Requires an underlying transport protocol (TCP) • Provides a message framing mechanism and many common service "profiles" • Profiles provide transparent addition of properties to a connection (i.e. security)

8. IDXP • Intrusion Detection eXchange Protocol • BEEP profile used to transfer intrusion detection alert information from various sensors within a large network to a central repository where an administrator or correlation program can take actions against an attack if needed • Firewall must not block messages

9. Tunnel • General purpose proxy routing BEEP profile • Our focus is Tunnel for IDXP message

10. Tunnel • Uses XML messages to establish a tunnel: <tunnel fqdn="host2.example.com" port="10288"> <tunnel /> </tunnel> • Example...

11. Tunnel host1.example.com host2.example.com proxy.example.com Transport Connect Usually TCP

12. Tunnel host1.example.com host2.example.com proxy.example.com Transport Connect BEEP Greeting Advertise services (Tunnel, maybe others)

13. Tunnel host1.example.com host2.example.com proxy.example.com Transport Connect BEEP Greeting Start Tunnel <tunnel fqdn="host2.example.com" port="10288"> <tunnel /> </tunnel>

14. Tunnel host1.example.com host2.example.com proxy.example.com Transport Connect BEEP Greeting Start Tunnel Transport Connect Usually TCP

15. Tunnel host1.example.com host2.example.com proxy.example.com Transport Connect BEEP Greeting Start Tunnel Transport Connect BEEP Greeting Advertise services (Tunnel, maybe others)

16. Tunnel host1.example.com host2.example.com proxy.example.com Transport Connect BEEP Greeting Start Tunnel Transport Connect BEEP Greeting Start Tunnel <tunnel />

17. Tunnel host1.example.com host2.example.com proxy.example.com Transport Connect BEEP Greeting Start Tunnel Transport Connect BEEP Greeting Start Tunnel OK <ok />

18. Tunnel host1.example.com host2.example.com proxy.example.com Transport Connect BEEP Greeting Start Tunnel Transport Connect BEEP Greeting Start Tunnel OK OK <ok /> proxy now transparently forwards messages

19. Tunnel host1.example.com host2.example.com proxy.example.com Transport Connect BEEP Greeting Start Tunnel Transport Connect BEEP Greeting Start Tunnel OK OK BEEP Greeting Advertise services (proxy now invisible)

20. Alternatives to Tunnel • SSL/TLS • SASL • SSH • VPN • IPsec

21. SSH (Secure Shell) Tunnelling • Client/Server applications • Provides encryption, client authentication • Mass adoption leaves port 22 open • Commonly used to tunnel through firewalls • Application dependency on SSH • Explicit endpoint connections • Lacks host authentication • Tunnel offers auth/encry details, address anonymity, doesn't require explicit endpoint

22. SSL v3 / TLS v1(RFC 2246) • HTTPS, NNTP, IMAP, POP • Lives between TCP and application • API is similar to BSD socket API • Encryption • Server authentication and optional host • Simple client configuration – no AC • Certificate spoofing, man-in-the-middle attacks

23. SASL (RFC 2222)(Simple Authentication and Security Layer) • SSL with an A? • Framework for adding auth/encry/integrity • Allows network admin to configure proper security levels for the environment • BEEP makes use of SASL

24. VPN(Virtual Private Network) • Secure, private, transparent network • Encryption, strong authentication • Intrusive on the client • Tunnel is easier to deploy and administer, allows more policy flexibility

25. IPsec(IP Security) • Protects everything running on top of IP, including TCP and UDP • Requires kernel modification • No recompiling necessary to get benefit • IPsec does not work with NAT • Tunnel is easier to deploy, works with NAT, and configurable

26. Completed Work • Proposal Submitted • Tunnel Evaluated • Beep Implementations Chosen • No – Hop Tunnel Implementation

27. Tunnel Issues: • No IPv6 support in the DTD or a standard way to extend the DTD. • Possibility for loops with misconfigured servers. • No way to specify a Time-To-Live when using a dynamic route, ie: connecting to a service rather than a host.

28. Beep Implementations: • JAVA: • PermaBEEP 0.8 • Beepcore–java 0.9.07 • C • Roadrunner 0.9 • Beepcore–C 0.2

29. No-Hop Tunnel • Profile and application can successfully open a tunnel to a host with no firewall in between.

30. Future Work • One–Hop Tunnel • Firewall Proxy–Hopping • Multi–Hop Proxying • Interoperability between C and JAVA implementations

31. Schedule

32. Questions?