1. Future Network Requirements @ UW Focus on Policy Networking Terry Gray David Sinn University of Washington 06 February 2008

2. Thanks! For coming! To Melissa!

3. In our last episode... DDNS in UWWI?  Planned for campus-wide NETID domain SSL VPN?  Scoping study underway Self-service net portal  No change; beta still open NAC?  Extended registration implemented for wireless Inventory reports from MAC reg database?  No action

4. Policy Networking Discussion Goals Discuss some of the tradeoffs of multiple service class approach Attempt to reach broad consensus on a “starter set” of policy networking / service classes

5. Premises A single connectivity class is no longer adequate for UW's needs Most users well-served by a “global” class No idea how many Dept'l classes needed A few private/isolated nets needed In general, the campus backbone remains L3; Extending L2 broadcast domains across multiple buildings remains an “anti-goal” Wireless will dominate end-user connectivity

6. Futures Market Questions In what year will >80% of {Fac, Staff, Students} no longer care about having a desktop computer? (i.e. laptop+docking is sufficient) In what year will >80% of {Fac, Staff, Students} no longer care about having a desktop phone? (assuming reasonable cell coverage and no onerous IRS issues to limit deployment).

7. Network Service Class Categories Global Subnet Specific Department Specific (multi-bg, multi-subnet)‏ Private/Isolated (multi-building)‏

8. Network Service Class Attributes IP reachability semantics (by Address and/or Port)‏ Non-IPv4 connectivity (Enet, IPv6, other )‏ Performance (Speed, Latency, Loss, Sequencing)‏ Duplex (Half, Full, Auto)‏ MTU (Jumbo Frames?)‏ Multicast Potential Options:  Shaping  NAC  QoS  Redundancy Cost, Price, and Value :)‏

9. Service Class Selection Methods Infrastructure Configuration  Switch port configuration  Router (subnet) configuration User/Device Properties  Identity of user  Identity of device (PKI or MAC addr)‏  IP Address of device (static or registered)* * Assumes service classes differentiated in routers via different address ranges; Need lots of address space to do this! (v6 ??)‏

10. Network Admission Control Motives: traceability; host posture verification Some NAC options:  None  Low assurance NAC (register/check host once)‏  High assurance NAC (verify host state on connection)‏  802.1x for wireless? Credential lifetime? SSO? Via PKI, or Win Domain, or ? Wireless, Wired, Both? 802.1x issues (software, flavors, dependencies, Enet hubs, PKI, Domain interactions...)‏

11. Global Classes Open  Traditional clear-channel (globally-routed "open" Internet connection with no firewalls)‏  R&D (clear channel, high bandwidth, low interference with basic services)‏ Protected  IPS-protected (Default connectivity w/ border IPS)‏  IPS + No incoming connections (like P172)‏  IPS + No outgoing connections, for servers ('cept DNS)‏  “Validated” --combination(s) of NAC + border policy

12. Global vs. Dept'l Question Motive for protected/validated class: reducing need for dept-specific classes (which don't scale) If there were global Protected/Validated classes defined, how many would take advantage? How many would say “Not good enough... still need a private dept'l network cloud” ? What other requirements might lead to the need for a dedicated dept’l network service class?

13. Department-Specific (multi-building)‏ L3 service: L2 broadcast domains remain single-building Multi-building, multi-subnet, single firewall Example: Traffic shaped class (e.g. packeteer) for residence halls Potential for widely-dispersed depts who currently need multiple subnet firewalls

14. Subnet-Specific Examples Subnet-firewall? P172 as DHCP default? DHCP server filtering?

15. Private/Isolated Classes Connectivity for devices/applications requiring a high degree of isolation or security (Power Strips, Elevator, Fire Alarms, SCADA, etc.) and no direct connection to Internet, e.g.  Dedicated to Life-critical applications  Dedicated to Voice-over-IP  Dedicated to Building control, etc  Dedicated to network management and control May be required for compliance or contracts Goal of only L3/IP between buildings may not work for datacenters (e.g. fiberchannel)‏

16. One Example: Duke GLOBAL  Wireless (public addresses, internet access)‏  Campus (public addresses, internet access, default)‏  VoIP (public + private addrs, firewalled)‏  Console (private addrs, firewalled)‏ DEPARTMENTAL  Resnet (public addresses, internet access)‏  DukeTIP (departmental, public + firewall, internet)‏  DUFCU (departmental, public + firewall, internet)‏ PRIVATE  Management (network ops, private, firewall, no internet)‏  Private (private, firewall, no internet)‏

17. Quarantine Limited connectivity for suspected "threat" hosts Is it a service class or property of each class? Mandatory, based on IPS/IDS sensors Optional, for configuring/patching new hosts Could use private addr space (10. or 172.)‏ Could do null-routing Require host to re-address, or not? One quarantine pool, or many?

18. Wireless Do all the global classes apply to wireless too? Or is wireless its own distinct service class? Claim:  It is not a distinct class in terms of reachability  Some, but not all, class defs might apply to wireless Wireless management is messy, but it is where most of the hosts will be

19. Key Requirements Def'n Questions What is the minimum set of service classes? Do “validated” global classes make any sense? How many Depts would still want a dedicated svc? How will wireless trends change the prev answer? NAC? How much, what kind, where? What other policy issues are important?

20. Questions / Comments