Transcript Some of the forces driving WLAN (re)design

Where are we going?
1
@arubanetworks
@arubanetworks
Some of the forces driving WLAN (re)design
Consumer devices
in the enterprise
Migration to the
cloud
2
Migration to IPv6
Why do we need VLANs?
• VLANs split up L2 subnets to control excessive broadcast & multicast traffic
• We sometimes use VLANs to segregate traffic for security
• VLANs can help us manage geographically distributed networks (addresses imply location)
• We sometimes use VLANs to segregate services and QoS
• We’ve always done it this way
• VLAN pooling has been a widely-used (and useful) feature…
3
Why do we need VLANs?
• VLANs split up L2 subnets to control excessive broadcast & multicast traffic
• We sometimes use VLANs to segregate traffic for security
• VLANs can help us manage geographically distributed networks (addresses imply location)
• We sometimes use VLANs to segregate services and QoS
• We’ve always done it this way
• VLAN pooling has been a widely-used (and useful) feature…
But…
• VLAN pooling causes inefficient address usage
• And IPv6 (SLAAC) VLANs don’t mix well with WLANs
• And managing multiple VLANs across a large network is challenging
4
Moving WLANs to IPv6 – SLAAC
• IPv6 address discovery with SLAAC
(State-Less Address Auto
Configuration, RFC 4862)
•
•
•
•
•
Routers send unsolicited Router
Advertisements (RA) periodically (~
minutes)
RS
Router Solicitation
RA
Router Advertisement
SLAAC
Stateless Address Auto-Configuration
DAD Duplicate Address Detection
ND, NS, NA Neighbor Discovery, Solicitation, Advertisement
2001:0db8:1010:61ab:0219:71ff:fe64:3f00
VLAN 1
RA includes the ‘network’ stub for the
address, device adds a unique interface
identifier to construct an address in a
stateless protocol
RA
Network Identifier
64 bits
RS
Interface Identifier
64 bits
RS
But more often, a device requests an
address by sending a Router Solicitation
(RS) to the well-known ‘all routers’
address
RA
RS
Controller assigns device to a pooled
VLAN and forwards the RS to only the
appropriate router
Address
MAC
On receipt of an RS, the router sends an
RA to the all-nodes multicast address
5
1. RS to ff02::2 ICMPv6 type 133 (RS)
2. RA to ff02::1 ICMPv6 type 134 (RA)
router lifetime 1800s
preferred lifetime = 7d,
valid lifetime = 30d
Moving WLANs to IPv6 – RAs meet wireless
• IPv6 address discovery with
SLAAC (State-Less Address Auto
Configuration, RFC 4862)
•
Controller assigns device to a pooled
VLAN and forwards the RS to only the
appropriate router
•
On receipt of an RS, the router sends
an RA to the all-nodes multicast
address
•
Controller forwards the multicast RS to
all APs with a member of that
multicast group
•
RAs multicasts are limited within their VLAN by
switches…But 802.11 has no concept of VLANs or
multicast, only broadcast to all associated devices.
VLAN 1
So an RA for a device on one VLAN is received by
devices on other VLANs. This affects BSSs serving
devices from more than one VLAN, which comes about
after mobility events or through VLAN pooling.
RA
RA
RAs are broadcast over the air, all
associated devices receive them
6
1. RS to ff02::2 ICMPv6 type 133 (RS)
2. RA to ff02::1 ICMPv6 type 134 (RA)
router lifetime 1800s
preferred lifetime = 7d,
valid lifetime = 30d
Address list
Address list
MAC
MAC
Consumer devices in the enterprise
•
Several scenarios result in clients
from multiple VLANs associating to
the same AP
•
This sows the seeds of the VLAN’s
demise
•
Mixed VLAN clients on one AP:
i.
Through VLAN pooling, by design
ii.
From mobility events, where
devices move from one AP to
another
iii. Where VLANs are used to
segregate, or manage traffic and
clients are using different services
7
Moving WLANs to IPv6 – multiple VLANs
• IPv6 address discovery with SLAAC
(State-Less Address Auto
Configuration, RFC 4862)
•
Controller assigns device to a pooled
VLAN and forwards the RS to only the
appropriate router
•
On receipt of an RS, the router sends an
RA to the all-nodes multicast address
•
Controller forwards the multicast RS to
all APs with a member of that multicast
group
•
RAs are broadcast over the air, all
associated devices receive them and
build multiple addresses
With IPv6, devices construct multiple addresses, one per distinct RA received,
by adding its MAC address to the RA global_routing_prefix + subnet_id.
A device may choose to use any address from its list as its source address.
VLAN 1
VLAN 2
RA
RA
RA
RA
2. RA to ff02::1 ICMPv6 type 134 (RA)
router lifetime 1800s,
preferred lifetime = 7d,
valid lifetime = 30d
8
Address list
Address list
MAC
MAC
MAC
MAC
MAC
MAC
Moving WLANs to IPv6 – confused
addressing
The network learns VLAN assignments and check for incorrect source
address as a security measure (e.g. anti-spoofing).
• IPv6 address discovery with SLAAC
(RFC 4862)
•
Controller assigns device to a pooled VLAN
and forwards the RS to only the appropriate
router
•
On receipt of an RS, the router sends an RA
to the all-nodes multicast address
•
RAs are broadcast over the air, all devices
receive them
•
Devices build multiple IPv6 addresses based
on heard & overheard RAs
•
VLAN 1
VLAN 2
RA
RA
RA
1. RS to ff02::2 ICMPv6 type 133 (RS)
2. RA to ff02::1 ICMPv6 type 134 (RA)
router lifetime 1800s,
preferred lifetime = 7d,
valid lifetime = 30d
RA
When a device starts to transmit, only one of
its IPv6 addresses matches the controller’s
VLAN mask. Packets with mismatched
source addresses are dropped.
9
Address list
Address list
MAC
MAC
MAC
MAC
MAC
MAC
Moving to IPv6 – Solving mismatched IPv6
VLAN 1 VLAN 2 VLAN 3
• IPv6 SLAAC with VLAN
pooling
• Where APs serve clients with
mixed VLANs, some percentage
of devices use the wrong address
and traffic is dropped
•
•
Solution: turn downstream
multicast to unicast
VLAN 1
But devices still hear all RAs on
the VLAN, regardless of where the
RS came from. This can be a
significant amount of extra traffic
VLAN 2
RA
RA
RA
Address list
MAC
10
RA
Address list
MAC
Moving to IPv6 – Unicast vs Multicast
•
Multicast-to-unicast of IPv6 SLAAC
RAs results in noticeably faster battery
drain
•
This appears to be a combination of the
client radio staying in receive mode for
longer periods (stays awake till it can
contend for an uplink trigger frame)…
•
And extra transmit operations to send
frames required to retrieve buffered
downlink and return to sleep mode
Multicast downlink frames
beacon
TIM
multicast
time
client radio in receive mode
Multicast to unicast downlink frames
beacon
TIM
multicast
unicast
data
trigger
client radio in receive mode
11
ack
&
sleep
client transmits
time
Moving to IPv6 – Solving mismatched IPv6
• IPv6 SLAAC with VLAN pooling
VLAN 1 VLAN 2 VLAN 3
• Where APs serve clients with mixed
VLANs, some percentage of devices
use the wrong address and traffic is
dropped
•
Solution: turn downstream multicast to
unicast
•
But now devices still hear all RAs on the
VLAN, regardless of where the RS came
from. This can be a significant amount of
extra traffic … and this unicast traffic is a
significant drain on battery life
VLAN 1
VLAN 2
RA
RA
• What to do? Either…
i.
Prune RA traffic to only those devices that have
outstanding RSs?
ii.
Make sure we don’t mix VLANs on an AP?
RA
RA
iii. Try making Wi-Fi VLAN-compliant?
Address list
MAC
iv. Other ideas?
12
Address list
MAC
Some of the forces driving WLAN (re)design
Consumer devices in
the enterprise
Migration to the
cloud
13
Migration to
IPv6
Consumer devices in the enterprise
• Consumer devices on a home
network
• Reference model is a small L2
network
i.
Not many devices, plentiful
bandwidth
ii.
Devices use multicast to discover
each other, and services by Type
and Name
iii. … through mDNS / DNS-SN /
Bonjour
14
mDNS and DNS-SD
mDNS Advertisement
- serviceType (e.g.PTR)
- domain
mDNS Query
App
advertises
service
- serviceType (e.g.PTR)
- domain
mDNS Response
- serviceName (e.g. AlphaPrinter)
mDNS Response
L2 network
mDNS Response
- serviceName (e.g. GammaPrinter)
App
requests
service
Announcements
ServiceType : Name
ServiceType : Name
ServiceType : Name
ServiceType : Name
- serviceName (e.g. BetaPrinter)
Queries
Responses
Announcements
Some DNS-SD Service Types
http://www.dns-sd.org/ServiceTypes.html
http http
ipp printer
appletv
Apple TV
home-sharing
iTunes Home Sharing
RFC 6762 Multicast DNS
RFC 6763 DNS-based
service discovery
DNS Domain Name Service
When a new service instance starts, it advertises the service to a multicast address with serviceType and serviceName.
Listening devices add the service to their cached list.
When an app requests a service by serviceType queries the OS-cached list for optional mDNS Query for the serviceType.
When an app wants to use a service, mDNS Queries resolve the chosen serviceName to a hostName and IP address + port
15
mDNS & DNS-SD
VLAN 3
• mDNS & DNS-SD
i.
Every service instance
publishes/advertises
when it comes up and
responds to queries on
multicast.
ii.
Within a given service,
all instances have
visibility of all other
instances…
iii. … except across VLAN
or L2 boundaries
VLAN 2
VLAN 1
iv. Default is to flood
packets
16
mDNS-participating network architecture
• mDNS & DNS-SD with
network participation
i.
‘Network’ learns groupings by
service and device
ii.
When a service instance transmits
(on multicast mDNS), the network
swallows the transmission
iii.
Network responds to mDNS DNSSD Queries on behalf of service
instances
iv.
v.
When other devices in the group
are in different VLANs, packets
are forwarded across VLAN
boundaries
Default may be to block mDNS
per-service
• Network intercepts mDNS service advertisements
• Transmits advertisements to selected devices on any VLAN
• Responds to service queries by sending selected responses
VLAN 1
VLAN 2
(ethersphere) #show airgroup status
AirGroup Service Information
---------------------------Service
Status
-----------airplay
Enabled
airprint
Enabled
itunes
Disabled
allowall
Disabled
(ethersphere) #show airgroup blocked-queries
AirGroup dropped Query IDs
-------------------------_touch-remote._tcp
_sleep-proxy._udp
_vnc._tcp
_mediatest._udp
_mediatest._tcp
17
81834
2
1819
91
22
Rules to determine control forwarding
(examples)
• Allow X service on the network
• Allow device/instance Y to see service
instance X because
- They are instances of the same service
- They are on the same AP
- They are in the same building
- They ‘owned’ by the same userid
- Y has been ‘authorized’ by the ‘owner’
of X
- They are instances of an ‘uncontrolled’
service
- X has been designated a ‘shared’
instance
Consumer devices in the enterprise
• mDNS & DNS-SD with
network participation,
network must be capable
of:
i.
Identifying whether a service
type is allowed
ii.
Identifying the ‘group’ which
should have visibility of each
service instance
18
@arubanetworks
Subnets, VLANs and multicast control
Multicast control: similar to VLANs but works across subnets
VLANs: network controls what a port can see
Subnets: L2 domains require a router to connect, breaks
multicast
19
‘Proxy’ multicast architecture is not new
•
ARP RFC 826
Multicast query
Unicast response
Proxy ARP has been a feature
of over-the-air WLANs for
years, to limit traffic and
provide security
•
Concept extends to multicast
control
•
Also extends to IPv6 duplicate
address discovery, neighbor
discovery
ARP proxy
(802.11v, u
e.g. ARP)
Over here,
mate!
Who has
A.B.C.D?
Multicast filtering
(802.11v FBMS
e.g. VRRP)
20
A.B.C.D
IPv6 Neighbor Discovery
Proxy
(e.g. NDP, ND, DAD)
mDNS-participating network architecture
• mDNS & DNS-SD with network
participation
i.
ii.
Network takes the role of service directory away
from the distributed mDNS model
External Configuration for
groupings, permissions
Network can add and advertise its own services
Internal policy
decisions
Policy layer
applies rules, e.g. “this device or service
instance is part of group X including these
other members”
mDNS
proxy
Traffic forwarding layer
Identifies, synthesizes and forwards
specific packets
mDNS
Advertisement
-
21
serviceType
domain
mDNS Query
mDNS Response
-
-
serviceType
domain
serviceName
(e.g. AlphaPrinter)
Some of the forces driving WLAN (re)design
Consumer devices
in the enterprise
Migration to
the cloud
22
Migration to
IPv6
Monitoring and control at the network edge
• Monitoring and managing corporate activity
from remote locations to cloud-resident
applications
i.
‘Conventional’ model brings traffic to the data
center from campus APs
ii.
And remote APs (VPN model over Internet)
Functions performed at the network edge:
Radio configuration, monitoring and management…
Authentication
Firewall rules
Traffic shaping and QoS
Monitoring & reporting
Access for troubleshooting
iii. As corporate locations become more distributed, and
apps & services become cloud-resident, network
managers become blind to corporate traffic
iv. The only touch point for network managers will be
an IT-supplied and managed AP
23
Some of the forces driving WLAN (re)design
Consumer devices in
the enterprise
Migration to
the cloud
Migration to
IPv6
• New WLAN features in response to specific problems
• Multicast control (filtering & forwarding) is a powerful new technology
• An opportunity to re-think network design
24
Why do we need VLANs?
IPv6
IPv4
VLANVLAN
1
2
VLAN
3
Increase the size, reduce the
number of VLANs to solve IPv6
issues
• VLANs split up L2 subnets to control
excessive broadcast & multicast traffic
• Solved by network multicast
control
• We sometimes use VLANs for security
• Solved (as well as it was by
VLANs)
• VLANs can help us manage geographically
distributed networks (addresses imply
location)
• Mobility-aware network does this
better
• We sometimes use VLANs to segregate
services and QoS
Single-VLAN networks can be an IPv6 overlay
over existing IPv4 designs…
Or an opportunity to simplify the whole network
25
Software Defined Networking (SDN)
•
Software-defined networking
decouples network control (routing
and switching traffic) from the
physical network topology
•
Network intelligence and state are
centralized, network topology is
abstracted and virtualized
•
The Open Networking Foundation
consortium is leading
standardization efforts
•
https://www.opennetworking.org/
•
OpenFlow is a protocol that
facilitates communication between
SDN Controllers and SDN capable
network elements.
* https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf
SDN Benefits
Centralized management and control of networking devices from multiple vendors
Increased network reliability, security, uniform policy enforcement, and fewer configuration errors
Granular network control with the ability to apply comprehensive and wide-ranging policies at the session, user, device, and application levels
Better end-user experience as applications exploit centralized network state information to seamlessly adapt network behavior to user needs.
26
Abstracting the network model
•
Abstract the network
model to a policy layer
•
Policy layer interfaces to
external APIs, OpenFlow
•
External APIs export
sensing information,
accept reconfiguration
Security / Remediation Server
Voice / Video Server
Required action
(response)
Can’t do this
one, try again
New device alert
Internal policy
decisions
Policy layer
applies rules, e.g. “this device or service
instance is part of group X including these
other members”
Traffic forwarding layer
identifies, synthesizes and forwards specific
packets
Connection
setup alert
Move to
another
AP
27
New
ACL /
firewall
Adjust
QoS per
stream
Sensing at the network edge
• Only at the edge can the
network sense
• Device radio characteristics
• Device authentication status
• Unassociated devices
radio
• All intrusion attempts
802.11 L2 traffic
mgmt & services
L3 traffic
& services
802.11 connected device
Radio
information
- Signal level
- SNR
802.11
management
- Associated
- Data rate
- Frame error
rate
- MAC
- Sleeping
Mobility
awareness
- Origin &
location
- Roaming
history
- AP load
- Neighbor APs
Authenticati
on
- Status
- Identity
- Role
- Blacklist
28
L2
- ARP
- VLAN
- mDNS
IP
- DHCP
- IP
address
Multicast
L4-7
- IGMP
- Sessions &
- MC
protocols
Neighbors - Destinations,
ports
- Rates
- QoS
Control at the network edge
• Only at the edge can the network control all aspects of association,
authentication, discovery and connectivity
• e.g. blacklist association based on traffic protocol
• e.g. move APs based on a new session
Blacklist
association
Move to
‘best’ AP
Devices &
services
discovery
Determine
Reachability
Synthesize
responses
Apply or
change
QoS
802.11 connected (or unconnected) device
Radio information 802.11 management
- Signal level
- Associated
- SNR
- Data rate
- Frame error rate
- MAC
- Sleeping
Mobility awareness
- Origin & location
- Roaming history
- AP load
- Neighbor APs
L2
IP
Multicast
L4-7
- ARP
- DHCP
- IGMP
- Sessions & protocols
- VLAN - IP address - MC Neighbors
- Destinations, ports
- mDNS
- Rates
- QoS
29
A better way to think about architecture
SDN policy decision layer
reconfigure network to allow for changes and coordinate
outside the wireless edge
Local policy decision layer
Abstract the wireless network model and make decisions
for authentication, service whitelisting, load balancing…
Policy enforcement layer
apply authentication rules, firewall rules,
QoS policy, multicast service manipulation
Sensing layer
report radio state, 802.11 state,
authentication, multicast services, traffic
30
Some of the forces driving WLAN (re)design
Consumer devices in
the enterprise
Migration to
the cloud
Migration to
IPv6
• The network hollows out
• The edge is used for sensing and reporting
• Policy definitions allow the network to dynamically reconfigure in response to
traffic & external events
• SDN APIs allow the network to dynamically reconfigure in response to external
requirements
31
Where we are going
32
@arubanetworks
@arubanetworks