Transcript PPT Version

Rogue IPv6
Router Advertisement
Problem Statement
Tim Chown
[email protected]
Stig Venaas
[email protected]
IETF 70, November 2007
Vancouver
draft-chown-v6ops-rogue-ra-00
Discussion at IETF69






Presented the rogue RA issue to v6ops and
dhc sessions
Some discussion of issues
Existing thoughts and community comments
documented in this draft
Agreement that a problem exists
Various solutions could be applied
One or two side issues arose
draft-chown-v6ops-rogue-ra-00
Structure of the draft

Scenarios




Methods to mitigate


Administrator misconfiguration
User misconfiguration
Malicious activity
Varying degrees of complexity/practicality
Other considerations
draft-chown-v6ops-rogue-ra-00
Scenarios

Administrator misconfiguration




User induced accidents



Directly on an interface configuration
VLAN misconfiguration causing RA ‘flooding’
Perhaps with a bad lifetime
Host acting as 6to4 router
Perhaps a laptop brought from home to work, where it was
a router (connection sharing?) at the home network
Malicious

Some attempt to capture/redirect/etc
draft-chown-v6ops-rogue-ra-00
Some possible solutions

(In no particular order)
Manually configure the default router


Use SeND/IPsec


Potentially complex, only one public implementation?
Implement RA ‘snooping’ in switches


Liable to introduce mistakes and management complexity
Attractive for its simplicity, but requires configuration
Use router preference option (RFC4191)

Optional feature, can be used by attacker anyway
draft-chown-v6ops-rogue-ra-00
… solutions continued

Use L2 admission control (e.g. 802.1x)


Use host-based packet filters


Needs to be configured, possible issue with updates
Use some auto-deprecate tool


Denies attacker access to IP layer
e.g. rafixd… feels somewhat kludgy…
Enhance DHCPv6 to add default router support


Radical change to IPv6 model
Mentioned as desirable by a number of enterprise admins
(but just pushes security issue to a different place)
draft-chown-v6ops-rogue-ra-00
‘Side’ issues arising

Network management/monitoring




Detecting incorrectly addressed nodes?
Detecting ‘bad’ RAs?
How/whether hosts are capable of recovering to
their correct state
Changes to DHCPv6

New gateway option for DHCPv6?


Contentious… and just moves the problem elsewhere
New onlink prefix option for DHCPv6?
draft-chown-v6ops-rogue-ra-00
Next steps


Is this problem statement useful?
It doesn’t (yet) make any detailed comments on the
advantages or disadvantages of the currently cited
solutions…


Which solution spaces are worth investigating?


The ‘RA snooping’ approach seems attractive
Can potentially good solutions be better promoted?


Should it?
We noted that SEND seems to share similar ‘complexity’
concerns as Authenticated DHCP, for example
What do people think is best practice?
draft-chown-v6ops-rogue-ra-00