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


Agenda: 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


How Do We Measure Success?: 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!


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


What Do We Do Today?: 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?


Who Standardizes What?: 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)


What We’ve Learned: 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)


Static vs. Extensible Authentication: 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


Why Do Auth at the Link Layer?: 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


Implications of Link Layer Auth: 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?


Trends: 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)


When Might Layer 3+ Auth Make Sense?: 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


Pitfalls of Upper Layer Auth: 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


Five Questions…: 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.


Five Questions (cont’d): 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


Five Questions (cont’d): 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


Five Questions (cont’d): 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


Five Questions (cont’d): 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!


Summary: 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