If you didn't see it in last thread,
http://geekmerc.livejournal.com/699.html may provide some information
for you, but I can tell from your concerns that your current choice of
edge layouts is different than mine. As such, more below.
Mikael Abrahamsson wrote:
Now, take for instance the residential LAN case. There are several
models on how to do this, but they all (that I know of) reside around
the fact that each customer gets one or more globally routed IP address
via DHCP, and security against spoofing and "man in the middle"-attacks
is either done via forced-forwarding in the L2 device the customer
connects to, or it's done via setting L3 accesslists learnt via DHCP
snooping that inspect L2-packets in that same device. Often both is
done, and also things like "ARP inspection", rogue dhcp server
protection, MAC-rewrite etc is used. These are essential security
mechanisms because customers should be protected from each other when it
comes to these types of L2 attacks. Tracability (who had what IP at what
time) is done via DHCP option82 and logging of this information. So, the
L2 devices closest to the customer does a lot of "magic". All of these
mechanisms were developed in the first half of the last decade.
Unnumbered vlans and RBE support on cisco, I guess could be considered
forced forwarding in layer 2. It definitely makes for beautifully long
configurations and severely limits dslams to support enough vlans for 1
vlan per port, preferably with q-in-q. It also had the benefit of
separation of responsibility, as telco could play with dslams (atm or
vlans) and networking played with routers where tracking/policing was
implemented.
Of course, moving away from ATM terminated systems seems to be the big
deal, and not all systems support massive vlan terminations. I believe
the vendors said, "Why on earth would you want to do that! It's like
replicating pvc's!" Those vendors do cute things in their dslams such as
dhcp snooping and limiting broadcast domains. IPv6 changes this from
broadcast domains to multicast. Luckily, thanks to triple play, most of
these same dslams also understand multicast and do igmp snooping. Adding
support for multicast RA snooping is considered trivial by most, which
is why they haven't bothered with it yet.
Now, with IPv6 this model changes drastically. The proposed mechanisms
for IP number handout etc, is RA and DHCPv6. How does that fit into the
model above? It doesn't, and the L2 devices surely won't "sniff" it and
enforce security measures mentioned above.
Why not? They "sniff" igmp. What's the difference? Multicast is already
commonly supported by most dslam manufacturers using flat topology.
My ideal model would be to replace the above mentioned L2 device with a
small and simple L3 device (L3 switch) with very small TCAM (TCAM size
6-8 times port number should be enough), where this device uses
link-local with the CPEs (would require all customers to actually have a
router at home), hands out prefixes via DHCPv6-PD, inserts route towards
customer link-local address, provisions anti-spoofing ACLs on that port,
logs what prefix was given out to each port at what time, and off we go.
I suggest heavy testing of this. I'm not sure that CPE's will be happy
about doing PD requests without having received a prefix/IP for the
interface. It'll also create create problems for traceroutes. ;)
The other option that is extremely simple is statically assign /64 to
each port and then if they do PD, insert the route and do anti-spoofing.
This is, btw, what RBE sorta does with IPv6 in atm world.
So, how can we fit current IPv6 into the IPv4 security model? We can't.
Current L2 devices won't do any of the IPv6 security stuff needed, and
just turning on RA/DHCPv6 would make it work from a "let's move
packets"-aspect, but it wouldn't be secure (perhaps in some
forced-forwarding cases there might be a possibility of doing it
securely, but what devices will log what customer had what IP at what
time when it's done via RA?).
I'll agree that I haven't seen the necessary support by vendors for what
should be trivial to change as mentioned above. One reason I took the
headache of treating vlans like pvcs is lack of uniform support at layer
2 for security policies. Vlans, though. Simple. They either support the
required number, or they don't.
and the L2 device doesn't know anything about that). I don't know if
this has actually been done, but I see no theoretical problem with it,
if someone can come up with something, please do tell.
Depends on the L2 device and how it's configured to deal with multicast.
If you didn't think about multicast when deploying, then IPv6 is doing a
service by reminding people that it exists. ;)
So, my view on IPv6 is that I would love to roll it out to all
residential customers, but unfortunately all the development done for
IPv4 security has gone unnoticed by the people developing IPv6 and now
it's behind and needs to catch up, or pitch a different model and then
get vendors to develop products that do this.
Vendors are the ones who are behind. Talk to yours. Multicast is simpler
to manage in L2 than broadcast. As to the support by vendors, that's
another question. I can't say I've been impressed with the overall
vendor support. On the other hand, I'm the first to order equipment I
didn't like to begin with into the trash due to no IPv6 support. ;)
In the mean time, we do (and I encourage everybody else to do the same)
support 6to4 and Teredo, plus we do IPv6 native in the core and peering
where possible plus we give IPv6 to customers where we're able to
securely (mostly transit customers and corporate customers with IPv6
capable CPEs).
Hate Teredo, and 6to4 rarely works due to the billions of home routers.
The best one can hope for is securing down to the edge and customers
eventually will have to buy a new home router to get their IPv6. (Most
cheapy routers on the market now have 2MB flash. The current images for
download are ususally about 1.8MB in size. I don't see 2MB flash routers
supporting the additional overhead of IPv6 support.)
Jack
