Subject: Operational comments on RAs vs DHC

From: Tim Chown <[email-masked]>
Date: Mon, 19 Mar 2007 15:42:35 +0000

Hi,

Please don't shoot the messenger, but there was one v6ops related topic I 
was hoping to bring up this morning but for which I wasn't able to prepare
some discussion slides.

The mail about 'rogue' Router Advertisements at the IETF reminded me.

A number of administrators that I know of deploying IPv6 (dual-stack) have
commented on a common problem, specifically the problem of handling 'rogue'
RAs in their networks.   This includes one admin at our site.

We typically see the problem in our wireless networks, where perhaps a 
user brings in a laptop that's set to be a 6to4 router at home, but shouldn't
be one on our wireless.   But we also have seen it where an admin makes
a config error typically in a VLAN config and one or more RAs leak to
additional subnets/links.   Use of VLANs seems to be rising, and mistakes
maybe more common.

The general problem is how to control the rogue RA, and/or to recover from
a misconfigured state should that arise.   One of the worst cases is probably
an additional (unwanted) RA sent with infinite lifetime.

There are various tools that could be used to mitigate rogue RAs, e.g.
- Use of SEND (as and when it's implemented)
- Vendors adding RA snooping to L2 devices (doesn't help shared media though)
- Using a higher precedence RA (assuming hosts/routers support it)
- Requiring L2 authentication, e.g. 802.1x (but that doesn't help against
  unwitting users)
- Using RA authentication (but then who does DHCP auth today?)
- Using host-based packet filters (but these need configuring)

There really isn't a readily deployable countermeasure today, and I think
that's causing mild unrest with admins.   Of course, one can just wave the
issue away saying it's no different to rogue DHCP servers, though at least
there is DHCP snooping on some L2 equipment.

The related issue is whether certain timers that have been standardised 
are appropriate in the face of deployment experience.   Recovery from
an administratively configured 'errant' RA is another consideration.
The above measures may be of no benefit if the 'trusted' party messes up.
However one could also say a similar issue exists today for a host getting
a bad DHCP lease for a period should a DHC server be misconfigured.

What I hear is some admins wanting an environment for IPv6 deployment that
they're comfortable with with IPv4 today, i.e. DHCP.   So they'd use DHCPv6
for address configuration.  No problem.   But they also ask 'why not use 
DHCPv6 for default router configuration?' - they would seem to like a 
trust model in their network that they're already familiar or comfortable 
with.   Whether it's a safe model is another question, but they're asking.

I also heard this morning of a site using manually configured default
routes on hosts to avoid the rogue RA problem.

Maybe vendors are already working on L2 RA snooping, but that doesn't help
wireless environments.   The higher precedence (rfc4191) could be used as
a defence against unwitting users, assuming there is host (or router)
support.

One concern here is there may be a push to define a default gateway option
(and maybe MTU option) for DHCPv6 if the people I have heard from are
typical of other admins.   

Is there a WG viewpoint on the practical short and long term solution to
this problem?

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Mar 2007 17:27:10 +0000

On Mon, Mar 19, 2007 at 07:22:23PM +0200, Rémi Denis-Courmont wrote:
> On Monday 19 March 2007 17:42:35 Tim Chown wrote:
> 
> Not sure what you mean... switches that trash RAs? how do they know which 
> ports leads to the legitimate router(s) - often different from the switch 
> itself?

Just like DHCP snooping today, you preconfigure it.
 
> Some people listen for RAs on the link, and send spoof RA with a zero 
> lifetime, to pretend the offensive advertiser goes down. Of course, this 
> assumes that the advertiser only does multicast RAs, *or* L2 switch infra 
> does not support IPv6 multicast. Also this could break local ACLs.
> 
> Oh, and yes, that's ugly.

That's why I dscounted that option from the outset :)  I think Itojun wrote
the first such 'zapper', but it's a very ugly 'solution'.

> Yes. It's easier to fix DHCPv4 problems because:
> - the victims users will usually get no connectivity at all, so they reboot or 
> whatever until this gets fixed,
> - the exposure time window is very limited.

The thing to consider (as well) is recovery from misconfiguration.  

-- 
Tim

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 19 Mar 2007 19:00:31 +0100 (CET)

> - Vendors adding RA snooping to L2 devices (doesn't help shared media though)

I think this is quite possible option. I discussed a vendor a year ago to 
implement something that allow sending RA only from preconfigured MAC 
addresses. They think they might be able implement something like that 
in their switches. No commitment yet...

> - Using a higher precedence RA (assuming hosts/routers support it)

This not really helps. Malicious RA advertisers can use high priority 
also.

> - Using host-based packet filters (but these need configuring)

I would list an other option also. Logging ICMPv6 activity - especially 
RS/RA. If the controlling/monitoring station is detecting incosistency 
then alert the administrator about the MAC addresses of malicious 
"routers".

> Is there a WG viewpoint on the practical short and long term solution to

In short term I think logging can alert admins. I long term a kind of 
switch assisted solution would nice to have. I am willing to invest some 
more time to investigate the problem....

Regards,
Janos Mohacsi
Network Engineer
NIIF/HUNGARNET

---

From: Gert Doering <[email-masked]>
Date: Mon, 19 Mar 2007 19:08:04 +0100

Hi,

> (and maybe MTU option) for DHCPv6 if the people I have heard from are

Actually, having DHCPv6 announce a default route, *and* have something
like VRRP for v6 would make "my admin life" more happy.

I don't trust RAs and RA client implementation - and yes, I've brought
our office network IPv6 down by connecting a router to "just quickly 
upgrade its firmware" that sent out "wrong" RAs.  (Yes, don't do that).

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  98999

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Mar 2007 18:24:47 +0000

> upgrade its firmware" that sent out "wrong" RAs.  (Yes, don't do that).

If you check the dhc meeting agenda, there's a potentially appropriate
talk next to last to raise the question.

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Mar 2007 18:38:49 +0000

> This not really helps. Malicious RA advertisers can use high priority 

It could help for 'accidental' RAs coming from the unwitting user's laptop.

> more time to investigate the problem....

Tools to detect unintended RAs and alert administrators would be useful,
I agree.
 
-- 
Tim

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 19 Mar 2007 20:09:46 +0100 (CET)

On Mon, 19 Mar 2007, Rémi Denis-Courmont wrote:

> Yes. Though logging has not been very satisfactory from my personal
> experience. Even after the "offensive" node was brought down (disabling its
> port through SNMP), it still took a full week to remove the stall prefix from
> every other nodes. Worst yet, unplugging the offensive host actually broke
> everything - it kinda works, albeit slowly and insecurely, as long as the
> bogus advertiser is up and running.

I am not claiming that log+alert is perfect solution. For a short term, 
until proper solution is in place, it is better than nothing. The admins 
knows at least he has to work.... In SLAAC there is no methods to enforce 
reconfiguration for that one you should use DHCPv6. However I doubt there 
is lots of DHCPv6 implementation supports server initiated 
reconfiguration.

By the way, I think It is matter of time that the poorly 
(auto)configured system will use the higher precedence in their RAs.
Maybe a statement would be useful somewhere in IPv6 autoconfig spec, that 
higher precedence value in RAs must be used only on manually configured, 
and managed routers....

 	Regards,
Janos Mohacsi
Network Engineer
NIIF/HUNGARNET

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Mar 2007 09:27:12 +0100

In your previous mail you wrote:

=> I strongly agree... We can avoid rogue RIP announces using a password
(poor for security but well suited for this) but there is nothing
for rogue default routers when preference is not deployed and nothing
at all for rogue prefix infos.

=> when I looked at implementing SEND I began by a filtering mechanism
for this reason. BTW with a modern IPsec it is easy to discard rogue
RAs by some extra SPD entries.

   - Vendors adding RA snooping to L2 devices
    (doesn't help shared media though)

=> I believe I understand your idea but it is not real "snooping".

=> this works only for the default router, i.e., solve only a part
of the whole issue.

=> doesn't help in the real world.

=> isn't SEND or a part of SEND? About DHCP auth, it doesn't work in
the real world, and network access control is not the job of DHCP
(cf. DHCPv6 list).

=> IMHO it is the best current solution and it can be done with IPsec.
Of course as you say it needs configuring... But how to recognize rogue RAs
without some kind of configuring?

=> it took many years to recognize a precedence is very useful (I have still
the (negative) answers when I tried this) so I am not very optimistic.
One can say that SEND is more than recommended in environments which
are not fully under your control too...

Regards

[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 22 Mar 2007 14:37:39 +0900

At Mon, 19 Mar 2007 15:42:35 +0000,

> additional subnets/links.   Use of VLANs seems to be rising, and mistakes

I'm not going to say that we don't have to worry about this type of
trouble, but I think we should check the severity carefully.

As far as I know, the only implementation that could act as this type
of rouge IPv6 router in practice was IPv6-enabled Windows XP.  I also
hear that Windows Vista doesn't enable 6to4 when normal IPv6
connectivity is provided.  And both XP and Vista support RA preference
(as defined in RFC4191).  Is my understanding correct?

If so, the problem may not be that severe as we are now worrying about
because IPv6 is not enabled in Windows XP by default; so there is less
probability that normal innocent users are trapped.

Again, I'm not saying this is not an issue to be considered.  But if
my understanding described above is correct, it seems to me it's at
least not worth introducing a drastic paradigm change in operation
and/or in protocol specification (such as using DHCPv6 just due to
this and/or introducing a 'default-router' option to DHCPv6).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]