[Attendee] Rogue RA

Wed Jun 17 14:27:35 UTC 2009

In a message written on Tue, Jun 16, 2009 at 06:25:15PM -0400, Tom Pusateri wrote:
> Shouldn't we see the same problem with rogue DHCP servers in v4?

There are two fundamental differences.  I've had long discussions with
some IETF folk about them.

* A rogue DHCP server does not break a working connection immediately.

  A common problem is someone boots their laptop with the 3G card still
  in it set up for sharing from where they were the day before, or
  similar.  They often find their own connectivity broken, or slow in a 
  matter of minutes, pull it out, and reconfigure.  Let's even assume
  they were using a DHCPv4 server on it.

  In IPv4+DHCP if you were already up on the LAN, the fact that a new
  DHCP server came up is uninteresting until you need to renew.  Since
  most leases are 7-30 days, and the broken laptop is in the broken
  config for a matter of minutes it's quite unlikely anyone will be
  broken, and if they are it is one or two folks.

  In IPv6+RA's, the second that laptop boots it sends RA's, and
  depending on a number of things that may break everyone on the lan in a
  matter of milliseconds.  Worse, when the person realizes and yanks out 
  the 3G card the software does not withdraw the route, so the folks
  that were broken in millisecond are now waiting for a two hour timeout
  during which the packets are blackholed.

* IPv6 has the assumption you want multiple addresses.

  Raise your hand if you've accidently plugged an ethernet cable into
  the wrong port on a switch before.  *looks*  Yeah, I think that's
  everyone.

  In IPv4+DHCP, if I take two, working subnets and accidently connect
  them (bridge) generally nothing happens.  DHCP renewals are even
  unaffected.  New clients may select the wrong network, but that's only
  an issue in highly dynamic networks.  Unplugging the cable instantly
  returns everything to a working state.

  In IPv6+RA's, if I take two working subnets and accidently bridge them
  in a matter of milliseconds the hosts detect this fact and every host
  numbers itself on both networks.  Worse, if I then unplug the network,
  because I realized 20 seconds later it was the wrong port on the
  switch, /I remove the ability for RA withdraws/ and every host in both
  networks is back to a two hour expiration.

The end result of all this is that from a theoretical level these
look like similar issues.  DHCP is unauthenticated.  RA's are
unauthenticated.  People run rogue versions of both.  However from
an operational level the RA model causes more outages, causes outages
faster, and makes them last longer.  In that sense, I've taken to
describing IPv6+RA's as less /robust/ than IPv4+DHCP in average
deployments.

What is the solution?  Well, there are, in my mind, three basic tracts
and I think it's important we go down all of them:

* "Secure RA".   There is an effort to secure, using crypto, the RA's
  in some useful way.  I have some concerns, but that is good work and
  should be continued.

* Make it possible to run DHCPv6 in the same way as DHCPv4, that is hand
  out a default router.  DHCPv6 relies on RA's to work.  In essence you
  can't turn off RA's and have a working network.  There are plenty of
  folks experienced with IPv4+DHCPv4, and for a lot of deployments it is
  "robust enough".  The fact that this option has been removed is a
  major step backwards in my mind.  DHCPv6 needs to be updated to allow
  operating an "RA-less" network, which probably also means finishing 
  VRRPv6.  I know IPv6 folks hate operators who say "make it work like
  IPv4", but in this case it is an option that should be on the table.

* Enhance LAN equipment to track RA's.  Those who need a more secure
  environment today prevent DHCP servers on "user" ports via DHCP
  snooping.  They make sure the host can only source IP from the address
  the DHCP server told them.  There's a set of 3-5 features, in the
  layer 2 switches to "lock down" dynamic addressing.  The same is
  needed for IPv6.  RA snooping, preventing user ports from advertising
  RA's, etc.

Anyone who's been to a NANOG or IETF has seen the issue with rogue
RA's.  Indeed, on a day to day basis I would say this is the only
thing left where I think there is a significant impediment to IPv6
deployment, and where IPv6 is significantly worse than IPv4 for all
of the typical cases.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
Url : http://mailman.nanog.org/pipermail/attendee/attachments/20090617/c1bf2a88/attachment.pgp 