Pros and Cons of Upper Layer Network Access

1. Pros and Cons of Upper Layer Network Access Bernard Aboba Microsoft Bernarda@microsoft.com http://www.drizzle.com/~aboba/IEEE/ BURP BOF

2. Agenda • How do we measure success? • What do we do today? • Who standardizes what? • What have we learned from the past? • Pros and Cons of Upper Layer Auth • Summary BURP BOF

3. How Do We Measure Success? • A network access architecture is successful if: • Users get access quickly. Need to minimize round-trips! • High speed operation is supported • We will have 1,000 Gbps wired networks by 2008! • That’s 5 clock cycles @ 10 Ghz to process a 64 octet packet! • It’s simple to develop, understand, operate and manage • We don’t get paid by the word for specifications. • On the Internet, we need to scale to handle everyone on (multiple?) planets – and their dog, watch, car, light bulb, etc. • Equipment can be manufactured inexpensively • Cost matters if you’re trying to connect everything! • More state, complexity means more hardware, higher cost, slower speed – so new features need to add real value. • Summary: You need to pass the laugh test! BURP BOF

4. Microprocessor performance Storage Gilder’s Law vs. Moore’s Law: The Next 20 Years Ethernet 1000000 100000 10000 1000 Speed in Gbps Performance in Gflop/s Storage in GB 100 10 1 2016 2000 2002 2004 2006 2008 2010 2012 2014 BURP BOF

5. What Do We Do Today? • Today, network access authentication is typically done at the link layer • Authentication takes place at the beginning of the session, with periodic re-auth if desired • Implies that the NAS is one-hop from the client, since link layer isn’t routable • Network access is granted on a per-port basis • NAS can do ingress filtering if desired, but usually doesn’t • Virtual ports (VPNs) can provide access control by user or machine • The client and Network Access Server speak the link layer protocol over a point-to-point link • 802.11: shared media converted to point-to-point for authentication via the concept of an Association (see 802.11 Tge) • The NAS and AAA server talk AAA protocol, which runs over IP • NAS tells AAA server what kind of access is desired (VPN, xDSL, 802.11, etc.); AAA server responds with appropriate attributes • The AAA protocol can tunnel the auth conversation (EAP) • AAA server can be many hops from client • Does this still make sense? Or has the world changed? BURP BOF

6. Who Standardizes What? • IETF: PPP, AAA, MobileIP, etc. • IEEE • Open standards body (http://www.ieee.org/) • Much of the discussion is held on the mail reflectors • Attendance at plenary, interim meetings not required • Documents in process available free for download • Standards CD-ROM available free to attendees at meetings • Responsible for standardization of IEEE 802 physical and link layers • Not just Ethernet or hardware or wired networks! • Current activities of interest • Ethernet in the First Mile Study Group • Ethernet over passive optical and xDSL • 802.3ae: 10 Gigabit Ethernet • 802.1X: network port authentication • 802.11: PHY & MAC for wireless LANs • TgE: security & QoS, TgF: inter-access point protocol • 802.16: Personal Area Networks (PANs) BURP BOF

7. What We’ve Learned • Network access authentication has already been implemented at every layer. • PHY • Example: 802.11b • Pros: no MAC or TCP/IP changes required (all support in firmware) • Cons: requires firmware changes in NICs and NASes to support new auth methods, requires NAS to understand new auth types, slows delivery of bug fixes (e.g. WEP v1.0), hard to integrate into AAA • MAC • Examples: PPP , 802.1X • Pros: no firmware changes required for new auth methods, easier to fix bugs, easy to integrate into AAA, no network access needed prior to authentication, extensible (RFC 2284) • Cons: requires MAC layer changes unless implemented in driver • IP • Examples: hotel access (based on ICMP re-direct to access web server) • Pros: no client MAC or TCP/IP changes required (for ICMP re-direct method) • Cons: Doesn’t work for all apps, no mutual authentication, partial network access required prior to auth, need to find access control server if not at first hop, typically not extensible, may not derive encryption keys, no accounting (no logoff) • UDP/TCP • Examples: Proprietary token card protocols • Pros: No client MAC or TCP/IP changes required – can be implemented purely at the application layer • Cons: requires client software, partial network access required prior to auth, need to find access control server if not at first hop, typically not extensible, no accounting (no logoff) BURP BOF

8. Static vs. Extensible Authentication • Lesson: New authentication methods are constantly being developed • Passwords, public key smartcards, token cards, OTP, biometrics, etc. • If new NAS code is required for each new authentication method, new methods will never be widely deployed. • Solution: • Build extensibility into the authentication framework: support for method negotiation, multiple round trips, etc. • Only require support for new auth methods on client and AAA server • NAS acts as a “pass through” to enable a conversation between the client and AAA server. • New access methods should support EAP, RFC 2284 BURP BOF

9. Why Do Auth at the Link Layer? • It’s fast, simple, and inexpensive • Most popular link layers support it: PPP, IEEE 802 • Cost matters if you’re planning on deploying 1 million ports! • Client doesn’t need network access to authenticate • No need to resolve names, obtain an IP address prior to auth • NAS devices need minimal layer 3 functionality • 802.11 access points, 1 Gbps switch ports go for $300, support 802.1D, 802.1X, SNMP & RADIUS, may have no layer 3 filtering support • Authentication, AAA support typically a firmware upgrade • In a multi-protocol world, doing auth at link layer enables authorizing all protocols at the same time • Doing it at the network layer would mean adding authentication within IPv4, IPv6, AppleTalk, IPX, SNA, NetBEUI • Would also mean authorizing within multiple layers • Result: more delay BURP BOF

10. Implications of Link Layer Auth • Authentication not routable, must occur at edge • NAS acts as Link-Layer/AAA gateway • Edge auth more scalable than core auth • No intrinsic support for fragmentation • To handle certs you need fragmentation support • RFC 2284 should have built this in • Workarounds available (RFC 2716) • No windowing support (ACK/NAK only) • Not a big issue unless you have a long exchange • Need to implement auth for each new link layers • Question: how many new link layers do we need? Which ones? BURP BOF

11. Trends • More of everything (people, addresses, routes, hosts, names…) • Faster, faster, faster! • Mobile Internet Access the Next Big Thing • IP everywhere! • Non-IP protocols going away (AppleTalk, IPX, NetBEUI, SNA) • Though multi-protocol still alive (IPv4 & IPv6) • Ethernet everywhere! • Non-Ethernet LAN protocols going away (FDDI, Token Ring, ARCNET) • Though PPP is alive and well (L2TP & PPPOE) • Support for point to point topologies as well as shared media • Speed increases by an order of magnitude every 3 years • Distance limitations removed via fiber optic PHYs • Ethernet now a LAN, MAN, WAN and even SAN medium • Some say Ethernet will also replace ATM, Frame Relay & SONET • Support for wired as well as wireless (802.11) BURP BOF

12. When Might Layer 3+ Auth Make Sense? • If speed is not a concern: filtering consumes precious cycles • If you can’t re-use PPP or 802 link layers • This rules out xDSL, dialup, wired LAN/MAN/WAN/SAN, wireless LAN • What’s left and why? • If you need to do complex authentication quickly • Combined auth methods, long cert chains, etc. • Some thoughts… • Need for new PHY doesn’t imply new frame format • Frame size not a factor at higher speeds • 802 hard invariants and soft invariants… • Hard: non-duplication, sequential delivery • Soft: low error rate, high bandwidth, low delay • Other: need to support multicast/broadcast service • Can be satisfied in a wireless LAN • Hard: ARQ • Software: ARQ/FEC, 100+ Kbps bandwidth, 300 ms delay BURP BOF

13. Pitfalls of Upper Layer Auth • Difficult to do accounting: if you don’t support logoff • Increased cost, decreased performance • Need to implement layer 3 filtering adds cost • Sweet spot for NASen implemented purely at layer 2 (low cost 802.11 APs, 1+ Gbps ports, etc.) • Result: is this a high-priced niche solution? • Finding the access control server, if not at first hop • Do you need to resolve the name? Use Service Discovery? • Service dependencies • Do you need DHCP? DNS? SLP? Anycast? • How porous does the filter need to be? What attacks do you enable in the process? • Inflexible and incompatible authentication • No support for multiple round trips, requiring MICs thereby increasing AAA complexity, etc. • Solution: support EAP • Enforcement in the core • Beware of state explosion, route changes, etc. • Security issues • Increased vulnerability to DoS attacks results from partial access BURP BOF

14. Five Questions… • Why do port authentication? Why not machine or user authentication? • Port authentication requires minimal state: the port is either open or closed. • Machine auth requires keeping state on which machines are authorized (substantial if the port connects to a shared medium), as well as filtering non-authorized traffic (more CPU cycles). • User auth (distinguishing between users on the same machine) is even harder: need to track flow state, filter non-authorized flows. BURP BOF

15. Five Questions (cont’d) • Why do we need a AAA protocol? Why not just tunnel the link layer? • You can tunnel link layer auth: EAP • You can tunnel the entire link layer: L2TP • But AAA isn’t just about authentication – it’s also about authorization and accounting • NASes need to authorize services beyond network access – telnet to a port (substitute for X.25), compulsory tunneling, etc. • Don’t necessarily trust client to do its own accounting BURP BOF

16. Five Questions (cont’d) • Why authenticate and authorize at the edge? Wouldn’t it be more flexible to do this in the core? • Core auth implies that unauthorized users can reach authorized users – security risk • Can’t do port authentication in the core – one port corresponds to many machines. So core auth requires more state. • Routing and MPLS tagging can interact in core auth • Summary: Core authentication is more complex, costly, insecure BURP BOF

17. Five Questions (cont’d) • Why can’t we do AAA directly between client and server? • You can authenticate directly, and receive a ticket authorizing network access: Kerberos • Requires clients to have (limited) network access prior to authenticating • Need to do name resolution, ICMP, address assignment, etc. prior to auth • Use “uncontrolled port” with appropriate filters • However, you may not want to put authentication, internal DNS servers on the Internet, open to all clients • May be concerned about DoS implications • Instead, client and server can talk through a gateway • EAP: uses NAS as a gateway • IAKERB: uses IAKERB proxy as a gateway • Gateways tunnel packets, no need for name resolution BURP BOF

18. Five Questions (cont’d) • Why is link layer auth easy to integrate with AAA? Why has integrating IP layer (or higher) auth been so hard? • Link layer auth has typically kept within the existing AAA auth model: PAP, CHAP, EAP • Result: no code changes needed to extend AAA to VPNs, xDSL, 802, etc., only additional attributes or values • IP-layer auth methods have included per-packet integrity and authentication via Message Integrity Check (MIC) • Link layers often assume physical security, but IP layer can’t do this • Need to prevent rogue DHCP server from sending bad configuration info (could determine boot load of diskless clients!) • Need to prevent rogue MN from registering with the HA • Result: AAA server needs to be intimately integrated with IP-layer auth method; you need an extension, not just new attributes or values • Example: AAA for DHCP requires AAA to parse DHCP packets, validate and prepare MICs, possibly distribute keys • Can’t just support CHAP, or you’d be vulnerable to attack by rogue servers! BURP BOF

19. Summary • Network port authentication more scalable than machine or user auth • Edge more scalable than core authentication • New network access methods should support existing AAA auth model: (CHAP, EAP) • DHCP for AAA proposals difficult to integrate • Link layer authentication likely to remain mainstream technique • Dialup, xDSL, 802, VPN already supported • Inexpensive, fast NAS devices available • AAA “just works” • Need for Layer 3+ auth rests on need for multiple new link layers • If there’s a need, it is in wireless WAN • No need for layer 3+ auth in dialup, LAN, xDSL, wireless LANs BURP BOF