200 likes | 302 Views
Future Network Requirements @ UW. Focus on Policy Networking Terry Gray David Sinn University of Washington 06 February 2008. Thanks!. For coming! To Melissa!. In our last episode. DDNS in UWWI? Planned for campus-wide NETID domain SSL VPN? Scoping study underway
E N D
Future Network Requirements @ UW Focus on Policy Networking Terry Gray David Sinn University of Washington 06 February 2008
Thanks! • For coming! • To Melissa!
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
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
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
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).
Network Service Class Categories • Global • Subnet Specific • Department Specific (multi-bg, multi-subnet) • Private/Isolated (multi-building)
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 :)
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 ??)
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...)
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
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?
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
Subnet-Specific Examples • Subnet-firewall? • P172 as DHCP default? • DHCP server filtering?
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)
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)
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?
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
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?