[00:00.000 --> 00:01.200]  Good evening, IPv6 now.
[00:01.480 --> 00:02.940]  This is my first attempt.
[00:03.160 --> 00:06.760]  I'm surprised everybody's not out in town drinking, having a good old time.
[00:08.860 --> 00:10.280]  That's later, yes.
[00:11.140 --> 00:12.320]  I'm Joe Klein.
[00:12.740 --> 00:19.580]  I've been involved in the IPv6 Task Force for 10, 11 years, part of the IPv6 forum.
[00:19.900 --> 00:22.980]  The new startup, the Cybersecurity Task Force.
[00:24.160 --> 00:28.860]  We've also been a contributor to a bunch of government documents.
[00:28.860 --> 00:34.960]  The two more interesting ones are the SP-119, which is the IPv6 from NIST.
[00:35.300 --> 00:38.280]  And next week, the following week, the U.S.
[00:38.320 --> 00:43.540]  CIO will be announcing the Planning Guide Roadmap towards the IPv6 adoption.
[00:44.160 --> 00:52.900]  There is a very large security section in there on recommendations on implementing IPv6 for government and the commercial space.
[00:53.840 --> 00:58.080]  So, we've got a lot of information on the IPv6 task force, timelines, project plans, and again, security.
[01:00.220 --> 01:13.320]  Legal disclaimer, not my employers, not my last employers, the one before that, or anybody I work for, or in the future, or the IPv6 task force, or any of those people.
[01:15.060 --> 01:17.840]  Honestly, I'm here because IPv6 is now a must.
[01:18.060 --> 01:21.360]  It's not a should, it's not a like, it's something that we must do.
[01:22.700 --> 01:26.400]  Don't mean to scare you, we're going to talk about some security things.
[01:28.440 --> 01:36.640]  Please be aware that there is innuendo in this to discuss where vulnerabilities exist, some of the things I've done from research.
[01:37.260 --> 01:41.040]  If you write those down, those might be useful for additional research.
[01:42.800 --> 01:54.760]  Also, vendor neutral presentation, be aware that I will appraise or, you know, tear down anybody with bad products, so you're aware of it until they actually fix it.
[01:54.900 --> 01:59.540]  It's starting to work over the last few years, which is kind of fun.
[01:59.540 --> 02:08.580]  And also, Jim Bound, the former Jim Bound, who really was the IPv6 plumber, is what he was referred to as.
[02:10.180 --> 02:17.380]  He came to me at one point and he said, you know, I need somebody that thinks evil, because we have a lot of network people and security is not important 12 years ago.
[02:17.680 --> 02:26.440]  So, I want somebody evil to actually think about these protocols, come up with some solutions, work with the community quietly, try to get a bunch of things working.
[02:27.520 --> 02:30.360]  So, you know, really, I've been quiet for many years.
[02:30.680 --> 02:35.120]  The last eight years, I've started discussing things openly.
[02:35.880 --> 02:38.100]  So, that's what this presentation is about.
[02:38.680 --> 02:49.740]  Okay, starting right now, we have approximately 5.5 billion devices that are IPv6, that are on the IPv4 Internet.
[02:50.840 --> 02:54.200]  We're really vying for 4 billion addresses.
[02:54.500 --> 02:56.460]  And because of that, we have a lot of overhead.
[02:56.460 --> 02:57.760]  We have things like NAT.
[02:58.300 --> 03:04.380]  I'm in the process of writing a paper on the 10 issues that make IPv6 important.
[03:04.760 --> 03:13.020]  One of those issues is the power distribution, specifically, or the power utilization for the Keep Alive for all of our devices.
[03:13.020 --> 03:25.160]  Our devices, like our phones, several studies have shown that we can increase our phone life expectancy anywhere from 13% to 50%, just because of Keep Alive connections.
[03:25.580 --> 03:35.600]  They also account for a lot of heat in our routers because of all the additional refreshes that take place for every single application we're running on every single device we're dealing with.
[03:35.840 --> 03:38.780]  So, this would actually help us fix some of those things.
[03:38.780 --> 03:43.600]  We also only have 2.2 billion people on the earth right now.
[03:43.740 --> 03:48.620]  And that only covers 32% of those people have Internet access today.
[03:49.940 --> 03:52.320]  We're still seeing growth in the community.
[03:52.540 --> 03:55.440]  Also, the amount of devices that most of us have.
[03:55.780 --> 03:58.900]  I mean, I know Travis right here in the front.
[03:59.240 --> 04:03.820]  He probably has tens of devices, just like I do, just like a lot of you do.
[04:06.180 --> 04:15.320]  We're going to really require... Cisco's done a study and said approximately 50 billion unique addresses are really needed by 2020.
[04:15.780 --> 04:25.440]  And even with a lot of advanced NAT capabilities and a lot of other really great ideas, we're not going to be able to get there quick enough.
[04:25.600 --> 04:27.320]  We're really going to be forced to go to IPv6.
[04:29.120 --> 04:45.800]  Some of the IPv4 NAT and RFC 1918, a lot of these technologies were actually implemented specifically to give us enough time to get IPv6 ready to go.
[04:47.280 --> 04:58.580]  Because of that, we have some security implications with IPv4.
[04:58.720 --> 05:00.060]  Wow, it's even worse.
[05:02.480 --> 05:04.440]  I just see the top of your heads.
[05:04.700 --> 05:05.640]  That's pretty neat.
[05:07.360 --> 05:11.020]  So essentially what we have is we use this technology as stopgap.
[05:11.020 --> 05:17.040]  Right now, as we move forward to IPv6, on IPv4 we're really used to one interface address.
[05:17.820 --> 05:28.060]  In IPv6 we start with three and we could end up with 30, 600, 1,000, depending on how your systems are set up.
[05:28.280 --> 05:30.680]  That actually provides a real challenge to keep track of that.
[05:31.700 --> 05:38.760]  One of the other security problems right now that we have specifically with NAT and also with IPv6 is blacklisting.
[05:38.760 --> 05:47.100]  We have so many people through so many different NATs, that all we can say is whatever that front end NAT is, that's where we stop the traffic.
[05:47.280 --> 05:48.840]  We ignore everything behind NAT.
[05:48.960 --> 05:56.720]  In some cases we've heard of seven levels deep of NAT for email and for other services, which is pretty crazy.
[06:00.300 --> 06:01.100]  Let's see.
[06:06.460 --> 06:19.620]  As of today, IANA has already delivered as of February 3rd all of the blocks, think of them as the main warehouse or the main production, for IPv4.
[06:19.840 --> 06:23.040]  They've provided all those out to the regional registries.
[06:23.040 --> 06:38.360]  The challenge now is that for growth, we're depending on the regional registries to manage enough IPv4 address space long enough so that we can have IPv6 bootstrapped into operation.
[06:39.540 --> 06:43.820]  Was that date to February of 2011 or February of this year?
[06:44.320 --> 06:44.960]  2011.
[06:45.280 --> 06:45.540]  Okay.
[06:45.780 --> 06:46.100]  Yeah.
[06:47.440 --> 06:49.000]  Yes, this is the other one.
[06:49.300 --> 06:52.720]  The RIRs already have problems.
[06:52.740 --> 07:00.960]  As an example, if you are in Asia Pacific, you have to depend on your carrier to have an IPv4 address.
[07:00.960 --> 07:03.160]  In most cases, they do not.
[07:03.400 --> 07:09.180]  They now deliver only IPv6 addresses and they provide some type of translation.
[07:10.120 --> 07:18.740]  One of 18 different translation types or tunneling types to get through and get you to the IPv4 infrastructure.
[07:19.200 --> 07:22.380]  We also see Europe is approximately 16 days away.
[07:22.680 --> 07:28.860]  So if you do business or, I don't know, whatever you do, kind of important.
[07:28.860 --> 07:31.260]  North America, we're talking 73 days.
[07:31.660 --> 07:40.560]  I don't know how you are but most of the clients I deal with, it takes more than 73 days just to get justification to, you know, change things.
[07:41.500 --> 07:48.200]  This is a very short-term issue and we'll talk about the implications, both from a security and operational standpoint.
[07:49.740 --> 07:52.720]  Latin America and Africa, they're following up very quickly.
[07:52.720 --> 08:14.800]  Some of the implications is that a lot of these carriers have made decisions that will slow down communications, manipulate communications, interfere with trust paths of the communications, which, you know, if you're intercepting traffic, great.
[08:14.800 --> 08:21.280]  But if you want reliable traffic back and forth, you really have to think about it.
[08:21.820 --> 08:25.940]  And again, 75 days to Europe, that's a very, very short time.
[08:27.360 --> 08:33.240]  By the way, what the carriers in the Pacific are doing is they're using several different technologies.
[08:33.240 --> 08:40.860]  One technology is IPv6 tunneled over IPv4, very similar to a protocol called 6-to-4.
[08:42.010 --> 08:45.720]  We now refer to that protocol as 6RD.
[08:46.100 --> 09:02.680]  What that requires is a piece of software on the router, the customer edge device, to be able to do this translation and then be able to connect in either IPv4 or IPv6 on the other side.
[09:02.820 --> 09:04.960]  So there's manipulation of the endpoint.
[09:05.360 --> 09:10.500]  We also have dual-stack light, which has its own challenges.
[09:11.240 --> 09:15.300]  And we also have NATPT, which is a translator.
[09:15.640 --> 09:25.000]  The problem with translators at this point is it tries to look far enough into the packet to deal with the TCP dataset.
[09:25.500 --> 09:32.940]  But if your application is dependent on an IP address, this can cause a lot of problems, both security and corruption of data.
[09:38.920 --> 09:39.540]  Let's see.
[09:39.680 --> 09:51.960]  And also many businesses, and specifically U.S. ISPs, are trying to figure out how to make this transition and how to do it cheaply.
[09:52.800 --> 09:58.820]  A lot of them are putting this process off by using one of these 18 transition protocols.
[09:58.820 --> 10:11.900]  Each of these transition protocols have their own security problems, their own management problems, their own ability or non-ability for intrusion detection, prevention, to be able to parse the packets.
[10:12.560 --> 10:15.600]  This is a very difficult problem.
[10:15.600 --> 10:20.740]  We're starting to see vendors starting to address this.
[10:21.040 --> 10:25.520]  But based on some testing, we're really not seeing complete testing.
[10:26.280 --> 10:36.800]  A lot of these transitions also have the ability to provide very easy denial service to these particular systems, which is a real hassle.
[10:38.220 --> 10:57.540]  Some of the impacts right now for the ISPs is that if you are using one of these ISPs and you rely on their mail server, and they do not have a dual stack mail server and DNS, you could literally lose traffic from certain places in the world.
[10:58.460 --> 11:06.180]  Right now we're seeing Sweden, Norway, and countries like that moving natively to IPv6 only with no IPv4.
[11:06.380 --> 11:14.180]  So if you're doing business or communicating or testing their networks, it really takes a rethink on dealing with that.
[11:15.080 --> 11:20.700]  And also, connections are real slow, or you'll have an inability to connect.
[11:21.290 --> 11:23.640]  User experience is horrible in many cases.
[11:25.400 --> 11:40.460]  Also, a lot of carriers are now implementing what they call carrier grade NAT, which means that one IPv4 address is mapped to anywhere from 100 to 1,000 customers behind it.
[11:41.480 --> 11:42.640]  Oh, that's nice.
[11:43.380 --> 11:44.020]  Cool.
[11:47.890 --> 11:48.730]  We're back.
[11:49.050 --> 11:49.830]  There we go.
[11:50.810 --> 11:53.750]  Anywhere from 100 to 1,000 customers behind it.
[11:53.750 --> 12:09.210]  Some of the problems is if you are using lots of connections, you may exhaust the connection pool for that particular NAT PT, that carrier grade NAT, which they're working on trying to avoid that as a denial of service.
[12:10.090 --> 12:12.030]  Also, a lot of applications stop.
[12:12.210 --> 12:19.990]  It's great for carriers that want to create a walled garden to control where you go and how you can get there.
[12:19.990 --> 12:23.970]  But for a lot of people, they're not going to be very happy about it.
[12:25.990 --> 12:30.890]  Also, for businesses and anybody that really wants to communicate, you have your own server.
[12:31.030 --> 12:34.590]  If you're not doing IPv6, you're really creating a self-imposed denial of service.
[12:42.480 --> 12:48.240]  So, it's really your fault at this point.
[12:48.740 --> 12:50.960]  Some of the security implications...
[12:51.920 --> 12:57.740]  We're seeing a lot of organizations trying to just slap this up and opening up all kinds of security holes.
[12:57.740 --> 13:14.760]  Simple things like not copying... opening IPv6 up on the firewall, but not copying the layer 4 and above specific protocol configurations and firewalls and IDSs and making sure they also work on IPv6.
[13:15.180 --> 13:17.440]  Just, you know, doubling the rules, essentially.
[13:18.280 --> 13:20.700]  We're also seeing a lot of lack of training.
[13:21.060 --> 13:27.620]  I get calls regularly from customers saying, this is how I need to implement IPv6.
[13:27.620 --> 13:30.260]  But they're really thinking from an IPv4 standpoint.
[13:30.280 --> 13:33.380]  They're not aware of some of the intricacies of IPv6.
[13:33.380 --> 13:35.780]  And we'll talk about this as we move forward.
[13:37.260 --> 13:38.920]  Also, many, many mistakes.
[13:38.920 --> 13:46.520]  Everything from subnetting addresses to just bad configurations.
[13:47.260 --> 13:49.060]  And I want to show you...
[13:49.860 --> 13:50.840]  There we go.
[13:55.210 --> 13:58.390]  What we have from the business side right now.
[14:02.860 --> 14:04.920]  Oh, did I do signal?
[14:11.760 --> 14:13.060]  Still lost signal?
[14:14.720 --> 14:16.140]  Plug in, plug out.
[14:36.340 --> 14:38.020]  I lost a display here.
[14:38.440 --> 14:38.960]  Oh, there we go.
[14:40.120 --> 14:40.240]  Yay.
[14:42.520 --> 14:43.420]  Here's the error.
[14:47.830 --> 14:49.930]  It helps when that is plugged in.
[14:50.710 --> 14:51.590]  Thank you.
[14:55.340 --> 14:55.940]  Yeah.
[14:57.620 --> 14:58.560]  There we go.
[15:01.690 --> 15:14.570]  This is a very nice website that gives you a list that NIST keeps on the ability for companies and government agencies to support IPv6 and DNSSEC.
[15:14.810 --> 15:20.790]  And as you notice, we won't attach company names to it, not too much.
[15:24.930 --> 15:26.610]  This is primarily the U.S.
[15:26.770 --> 15:28.030]  corporate world.
[15:31.660 --> 15:33.500]  Wow, we're through B now.
[15:39.130 --> 15:43.710]  So if you're interested, go up to this site, which is on NIST.
[15:43.710 --> 15:48.890]  You can just do a search on NIST, IPv6, DNSSEC, and you'll get to this site.
[15:50.210 --> 16:01.130]  The more interesting thing about it is those that are implementing IPv6 are not implementing DNSSEC in the corporate world.
[16:02.070 --> 16:09.910]  Therefore, they're not going to be able to take advantage of some very powerful new tools from a security perspective.
[16:18.750 --> 16:19.810]  No, that's not good.
[16:25.480 --> 16:26.770]  No, not again.
[16:32.710 --> 16:33.630]  There we go.
[16:35.150 --> 16:35.830]  Who cares?
[16:42.210 --> 16:43.030]  Come on down.
[16:47.430 --> 16:48.270]  There we go.
[16:49.230 --> 16:53.850]  Some of the federal government, they actually have a timeline right now.
[16:54.790 --> 17:10.690]  As of December 10th, procurement policy came out, which if you're in any other organization, you may want to be aware of this, which pretty much states that you have to be signed off to be able to support IPv6 on your products as you ship them.
[17:12.290 --> 17:17.450]  You can get exceptions, but then that is actually managed and documented in several different places.
[17:18.030 --> 17:24.830]  So if you're selling products to the federal government or you're in the federal government, you're supposed to support it.
[17:24.970 --> 17:35.030]  One of the funny stories that I've heard, and this is really, it's a procurement challenge, is that I was within one customer who created a procurement policy.
[17:35.190 --> 17:35.910]  It makes sense.
[17:36.090 --> 17:43.730]  They just kind of forgot to tell the people that do boilers and alarm systems and systems like that to support IPv6.
[17:43.970 --> 17:49.730]  Therefore, when they started making the move to a dual stack environment, they had a lot of products they had to repurchase.
[17:50.450 --> 17:53.810]  So be aware this can be very expensive.
[17:53.810 --> 18:05.990]  We also see as of September 30, there's a challenge within the federal government to have all of the Internet facing services support IPv6.
[18:06.190 --> 18:18.790]  That means if a consumer needs website access, it's non-encrypted, needs to receive or send mail from the federal government, and also do queries based on DNS, that's real important.
[18:18.790 --> 18:32.010]  By 2014, they want the ability of internal systems to be able to reach out through secure connections, so that they can connect to IPv6, native IPv6 and dual stack web servers.
[18:34.010 --> 18:35.410]  Some of the impacts.
[18:36.510 --> 18:50.210]  The USG is really pushing the ISPs to support IPv6 or making some real interesting demands on the carriers, which will help the corporate world.
[18:50.450 --> 18:52.870]  One of the challenges, though, is early vulnerabilities.
[18:53.090 --> 18:56.350]  There's a lot of research on making sure that they're protected.
[18:56.910 --> 19:03.170]  And there are some links on the slides that will point you to policies and more scorecard.
[19:03.910 --> 19:06.230]  Are you guys interested in seeing the government scorecard?
[19:17.940 --> 19:18.980]  A lot more green.
[19:19.220 --> 19:20.220]  Let's go to the top.
[19:23.640 --> 19:28.620]  This is the growth at this point of servicing DNS.
[19:31.080 --> 19:37.700]  And there's as of the eighth how many domains have been moved over.
[19:38.440 --> 19:43.600]  And you can see a lot more green here in the federal government.
[19:44.440 --> 19:48.420]  A lot of organizations are completely green with dual stack environments.
[19:55.190 --> 19:55.910]  Okay.
[20:00.580 --> 20:02.060]  Trying to get to that bottom.
[20:02.240 --> 20:02.360]  Okay.
[20:04.260 --> 20:08.480]  A lot of DOD components supporting it right now.
[20:12.180 --> 20:13.440]  Back to this.
[20:20.450 --> 20:27.330]  So the vast majority of IT and security staff at this point are still really unaware.
[20:27.330 --> 20:37.510]  Even interviewing people in the IT security domain, routing, switching, admins.
[20:37.730 --> 20:40.230]  Their typical attitude was turn IPv6 off.
[20:40.610 --> 20:54.330]  Unfortunately, if you've done that on things like a Microsoft machine, Microsoft 2008 R2, what happens is in many cases it will require reinstall of the operating system and all the applications.
[20:55.810 --> 20:59.930]  So be aware turning it off may cause a lot of pain for you.
[21:00.950 --> 21:03.990]  So, which is a real pain in many different ways.
[21:04.290 --> 21:10.150]  They're also unaware of the risks and they, again, they don't set up the host-based firewalls correctly.
[21:10.270 --> 21:16.130]  If they're using some kind of anti-malware software or say they have a blacklist.
[21:16.130 --> 21:19.850]  A lot of them are assuming that their current blacklist, blacklist IPv6.
[21:20.170 --> 21:28.310]  Well, there's only one that does it and it only for email and it's really not associated with too much.
[21:28.590 --> 21:33.350]  They only do email and only very small populations.
[21:33.350 --> 21:37.010]  So you really can't see spam coming in, which is interesting.
[21:38.290 --> 21:44.670]  Another group that I'm finding some real interesting things with is the auditor's assessment and penetration testing folks.
[21:44.950 --> 21:49.310]  A lot of them are not aware of it or don't know the right tools to use.
[21:49.410 --> 21:51.590]  We're going to talk at the end about some of the right tools.
[21:52.970 --> 21:59.190]  Also, security performance monitoring systems are not in parity with IPv4.
[22:00.790 --> 22:04.170]  So you're really unable to see a full picture of what's going on.
[22:04.310 --> 22:09.830]  A lot of times you'll be able to see, if you're using NetFlow, you'll be able to see that you have IPv6 packets.
[22:09.950 --> 22:24.790]  But unless you have it configured for tunnels and somebody doesn't do something crazy like a IPv6 packet with three or four extension headers that you can't parse down with your tools, then you're not going to be able to see inside this packet.
[22:24.910 --> 22:25.830]  So that's a real problem.
[22:26.770 --> 22:35.330]  Some of the recommended sources is the DNS, the DISA STIG, Juniper has a real good document, Cisco and Microsoft.
[22:40.620 --> 22:42.920]  Okay, let's dig into this a little bit deeper.
[22:44.840 --> 22:50.640]  One of the big issues for addressing was the ability to create a hierarchical addressing strategy.
[22:51.480 --> 23:08.900]  This is a good example of it where we have IANA delivering or manufacturing the addresses, shipping it to the regionals, sending it to either regionals or nationals, locals and ISPs, and then down to the actual end user.
[23:10.340 --> 23:15.560]  I want to mention that the address space is mapped exactly the same way.
[23:17.360 --> 23:18.940]  This is pretty neat.
[23:19.980 --> 23:23.800]  This is very useful if you're applying access control lists.
[23:24.120 --> 23:27.440]  This is very useful if you're doing some limitations.
[23:27.440 --> 23:33.640]  This is something that's not really discussed a lot of places as far as application.
[23:35.520 --> 23:41.880]  By the way, only one-eighth of the address space has been allocated for IPv6 at this point.
[23:41.880 --> 23:50.440]  And we've only used just a less than one-tenth of one percent of addresses even allocated, which is kind of interesting.
[23:51.700 --> 23:56.340]  If you notice from the IANA, they can hand it to regionals.
[23:56.800 --> 24:01.520]  And then we have four different categories based on where in the world.
[24:01.680 --> 24:09.680]  Mostly these are political constructs that have been created within countries and within organizations and ISPs.
[24:09.680 --> 24:11.340]  So be really aware of that.
[24:11.560 --> 24:14.760]  You can look some of this information up on the WHOIS database.
[24:17.780 --> 24:21.300]  Now, one of the challenges is although...
[24:21.920 --> 24:22.880]  We'll go back one.
[24:23.580 --> 24:31.860]  Although we used to have RC3177, which said our minimal address for provider was a slash 48.
[24:32.360 --> 24:34.300]  48 was for large organizations.
[24:34.600 --> 24:36.580]  54 was for small businesses.
[24:36.860 --> 24:38.500]  And 64 was for an end user.
[24:40.060 --> 24:52.260]  When we tried to implement this in an operational standpoint across the Internet over the last three, four years, especially as it's starting to become popular, we found that things don't work.
[24:52.480 --> 24:57.060]  As an example, there are cloud providers handing out slash 128s.
[24:57.740 --> 25:09.600]  Therefore, instead of you getting enough addresses to address multiple cloud environments that you should be able to deal with, they're only addressing a slash 28.
[25:10.020 --> 25:19.240]  Also, they identified that, hey, if we address, if we allocate all these addresses very quickly, we're going to have a big problem.
[25:19.320 --> 25:20.660]  We're going to run out of addresses again.
[25:20.660 --> 25:21.840]  They did some projections.
[25:22.040 --> 25:26.360]  Okay, it's probably past, you know, when we've all retired in this room.
[25:26.980 --> 25:30.540]  But they're still trying to be a little bit more frugal than they have before.
[25:31.480 --> 25:35.700]  So they've taken the boundary off of the address.
[25:36.080 --> 25:45.140]  You now have to justify with your upstream provider how much space that you need for your particular organization.
[25:45.140 --> 25:48.180]  Also, by doing this, it's easier to get an address space.
[25:48.360 --> 25:56.860]  Sometimes it's very difficult to get a larger address space if you're a cloud provider or carrier, or you're doing something interesting or unique.
[25:59.120 --> 26:08.680]  One of the other issues is that they recognize sites aren't the same, and they have different shapes and sizes, and we should be able to allocate addresses appropriately to that.
[26:09.720 --> 26:13.980]  Also, they opened up the possibility of NAT66, God help us.
[26:15.900 --> 26:27.360]  The justification at this point was from two of the router vendors was specifically to deal with multiple ISP connections.
[26:28.100 --> 26:30.780]  There are other solutions around this space.
[26:30.960 --> 26:34.030]  Too many to discuss on this particular forum.
[26:35.020 --> 26:43.880]  But that's one solution, and it's been proposed, and some of us are not very happy about it, but whatever.
[26:45.300 --> 26:51.460]  Also, based on the additional projection, the growth rate should be a lot easier now.
[26:51.780 --> 27:03.440]  So if we look at the bottom of the screen, a slash 48 is still the provider, the minimal side for provider independent that may need the NAT or use multiple carriers.
[27:03.820 --> 27:10.040]  But now you can make a request with anything from a slash 32 to a slash 64 or anything in between.
[27:10.040 --> 27:13.080]  You can even do it on nibble boundaries if you decide.
[27:13.360 --> 27:17.280]  So that's a decision you make based on your address plan.
[27:23.950 --> 27:24.590]  Programmers.
[27:24.590 --> 27:25.230]  Yes.
[27:28.070 --> 27:36.430]  Do you know how many programmers are unaware that their layer seven application has, I don't know, layer three code?
[27:36.430 --> 27:40.290]  Have misconfigurations.
[27:40.870 --> 27:46.790]  We're going to talk about those in detail based on some research I'm doing at this point.
[27:47.430 --> 27:56.050]  The research is based on reviewing all the current vulnerabilities that are in the National Vulnerability Database.
[27:56.190 --> 27:58.350]  And what the actual cause of those are.
[27:58.350 --> 28:03.330]  And also, I've been doing some testing and validation of other products.
[28:03.650 --> 28:05.170]  So this has been really interesting.
[28:05.550 --> 28:08.770]  I'm only going to give you a piece of it that's actually part of a whole day class.
[28:08.910 --> 28:13.310]  But from a security standpoint, I thought that this was something you guys need to hear.
[28:14.790 --> 28:24.650]  So it's real interesting how the programmers will do things like create cookies that have addresses in the cookies.
[28:25.810 --> 28:27.010]  Pretty neat.
[28:27.990 --> 28:32.810]  But the receiving code is only defined for 32 bits.
[28:34.650 --> 28:37.310]  So how do you process the rest of the bits?
[28:39.290 --> 28:40.230]  Kind of interesting.
[28:41.350 --> 28:43.530]  A lot of places where there's buffer overflows.
[28:43.710 --> 28:46.570]  Those of us that have been fuzzing for a while trying to get things fixed.
[28:47.790 --> 28:49.710]  A lot of places for buffer overflows.
[28:50.550 --> 28:52.990]  So let's go and do a little bit of a deep dive.
[28:54.490 --> 29:02.590]  I'm using this XP screen just as a visual to say, well, XP, by the way, doesn't support IPv6 first.
[29:03.270 --> 29:07.730]  But the second piece is just to give you some ideas of some of the problems.
[29:07.750 --> 29:13.730]  As an example, how does your system allocate or receive an address?
[29:14.050 --> 29:17.910]  Is it static, link local, or DHCP?
[29:18.270 --> 29:20.030]  Are you using neighbor discovery?
[29:20.250 --> 29:31.150]  Some applications at layer 7 try to attempt to go around the APIs and do their own query instead of going through the standard API for addresses.
[29:31.150 --> 29:34.710]  We also have the number of addresses allocated.
[29:35.030 --> 29:42.070]  We have a precedence in IPv6 where if the address is a link local, we communicate via link local.
[29:42.270 --> 29:47.630]  If it's a unique local address which is used within an enterprise, we select that.
[29:47.630 --> 29:49.910]  If it's a global address, we reply with that.
[29:50.650 --> 29:55.170]  A lot of applications don't know how to use it and don't know how to reply correctly.
[29:55.170 --> 30:04.150]  Therefore, you can run an application and suddenly find that it can't connect because it suddenly received the wrong address or didn't see it.
[30:05.410 --> 30:06.570]  Kind of a problem.
[30:06.870 --> 30:14.930]  Again, most IPv6 systems have three, or excuse me, two unicast addresses and three multicast addresses.
[30:15.610 --> 30:19.430]  Another problem is the dotted quads.
[30:19.790 --> 30:21.430]  How are you going to parse this?
[30:23.110 --> 30:30.990]  We have well-known parsers to know that, you know, we have one to 255 for each of those addresses.
[30:30.990 --> 30:32.630]  How do you parse that user interface?
[30:33.030 --> 30:35.870]  Can somebody put additional hex characters in this?
[30:36.990 --> 30:38.070]  Kind of interesting.
[30:39.510 --> 30:41.230]  And also the length of it.
[30:41.370 --> 30:42.970]  The actual parsing of the length of it.
[30:43.150 --> 30:47.710]  Again, applications that have problems with this.
[30:48.190 --> 30:49.350]  Also the subnet.
[30:51.750 --> 30:54.330]  How do you actually address the subnet issue?
[30:54.530 --> 30:56.910]  How do you store the address itself?
[30:57.470 --> 30:59.730]  There are multiple ways of storing address.
[30:59.730 --> 31:04.930]  We can use it uncompressed with all 128 bits, or we can go compressed.
[31:05.730 --> 31:11.310]  Well, does your application uncompress it before it actually does a compare?
[31:11.810 --> 31:13.990]  Or is it required in compression?
[31:14.270 --> 31:21.610]  What happens if you have two sets of zeros separated by an A or additional character?
[31:21.830 --> 31:22.950]  How do you compress that?
[31:23.070 --> 31:25.730]  Do you compress the set of zeros to the left or to the right?
[31:25.730 --> 31:30.430]  Again, your algorithms can be wrong and it can cause some real headaches.
[31:32.830 --> 31:36.450]  Also network representation of the default gateway.
[31:36.670 --> 31:41.030]  By default, we can get this through neighbor discovery.
[31:41.390 --> 31:44.330]  Using FFO2 colon colon one.
[31:46.210 --> 31:51.070]  But depending on the application, it may not be able to find the default route.
[31:51.870 --> 31:54.130]  If you just move the application over directly.
[31:55.530 --> 31:57.670]  Another thing is how are you getting DNS?
[31:58.090 --> 32:00.130]  Is the application doing the DNS?
[32:00.690 --> 32:02.590]  Or is the...
[32:03.670 --> 32:07.030]  Do you have your own DNS query?
[32:07.210 --> 32:12.790]  As an example, the browsers currently have their own DNS services that...
[32:12.790 --> 32:14.010]  And caches.
[32:14.790 --> 32:16.430]  If you don't have...
[32:16.430 --> 32:22.010]  If you're not understanding how they work, you can have applications bring in the wrong data.
[32:22.250 --> 32:22.950]  Which is pretty neat.
[32:25.410 --> 32:26.970]  We also have memory structures.
[32:28.370 --> 32:28.810]  Storage.
[32:30.190 --> 32:30.630]  What...
[32:30.630 --> 32:31.230]  How do you...
[32:31.230 --> 32:32.030]  How do you process?
[32:32.190 --> 32:34.710]  How do you manipulate these things in memory?
[32:34.970 --> 32:36.070]  How do you store them?
[32:36.170 --> 32:37.410]  Do you store them in a database?
[32:37.710 --> 32:39.150]  Again, compressed, uncompressed.
[32:39.150 --> 32:43.010]  There is 17 ways that you can compress it.
[32:43.090 --> 32:45.050]  And you have to have that as a standard.
[32:45.990 --> 32:47.830]  Also, in-core memory.
[32:48.310 --> 32:50.470]  How do you store them as a file when you...
[32:50.470 --> 32:51.410]  As a configuration file?
[32:51.710 --> 32:56.530]  I found several applications just by putting an IPv4 and an IPv6 address in it.
[32:56.750 --> 32:57.350]  Malformed.
[32:57.550 --> 32:58.370]  It crashes.
[33:00.290 --> 33:01.770]  How do you parse that data?
[33:01.910 --> 33:03.690]  And also, how do you, again, validate it?
[33:09.250 --> 33:10.110]  Ah, yes.
[33:10.230 --> 33:10.930]  The ASICs.
[33:13.150 --> 33:21.450]  A lot of our devices have layer 3 and layer 4 optimization on our network cards.
[33:22.270 --> 33:24.570]  This is a real problem, isn't it?
[33:26.970 --> 33:36.770]  Well, depending on the provider and the age of the device, your device may not have the ability to process in an ASIC.
[33:36.890 --> 33:41.890]  It has to then go to the operating system to do whatever processing takes place.
[33:42.930 --> 33:44.070]  Real problem.
[33:44.910 --> 33:46.910]  It can cause a real slowdown.
[33:47.230 --> 33:51.090]  Especially if you're processing lots of addresses.
[33:51.350 --> 33:52.770]  Addresses it doesn't understand.
[33:53.190 --> 33:56.770]  Addresses with lots of extension headers on it.
[33:57.590 --> 34:00.670]  There are routers and switches and other devices.
[34:02.570 --> 34:10.250]  Speed up cards that essentially will crash, die, lock up based on the ASIC that's in there.
[34:10.390 --> 34:15.810]  Some of the other things you've got to be careful from the ASIC standpoint is how much memory is allocated.
[34:15.810 --> 34:30.930]  Some of these ASICs have not enough memory to be able to deal with or allocate 128 bits two or three times plus your equivalent IPv4 address range if you're running dual stack.
[34:30.930 --> 34:34.110]  So be aware these are decisions you're going to have to make.
[34:34.230 --> 34:35.450]  And not just in your routers.
[34:35.570 --> 34:37.130]  You're going to have to make this in your switches too.
[34:39.330 --> 34:46.430]  I have a reference down here to a SANS conference I spoke at a week and a half ago, two weeks ago.
[34:46.810 --> 34:50.630]  His slides are up on the net talking about even more details on the ASIC.
[34:51.370 --> 34:53.250]  Or you can contact me.
[34:57.070 --> 34:58.950]  So, IPv6 launch day.
[34:59.150 --> 34:59.710]  Woohoo!
[35:00.190 --> 35:01.710]  I waited all my life for this.
[35:01.870 --> 35:03.730]  Well, a long time it feels like.
[35:04.090 --> 35:05.710]  I was so young then.
[35:06.610 --> 35:07.870]  We have...
[35:07.870 --> 35:11.430]  A lot of organizations participated in the launch day.
[35:11.590 --> 35:14.330]  This was supported by the Internet Society.
[35:15.010 --> 35:20.190]  And the particular carriers on here made a specific commitment.
[35:20.190 --> 35:24.750]  So if you have any of these carriers, you might find this interesting.
[35:24.990 --> 35:41.290]  What they committed to is if you are a new customer or a customer that's requesting IPv6, you're supposed to get native IPv6 access at your home, at your business, at wherever you need access.
[35:41.550 --> 35:46.950]  So be aware that was one of the requirements to be able to get through IPv6 World Day.
[35:46.950 --> 35:58.670]  Some of the more interesting things is on the IPv6 World Day, 1.1 of websites were enabled out of the million in the database.
[35:59.030 --> 36:09.430]  It was interesting that from Germany's standpoint, we had a bigger percentage, even though they have less websites up on the Internet that's supporting IPv6.
[36:09.430 --> 36:16.490]  If we look at the U.S., we had very little participation, although we account for about 45% of all the websites out there.
[36:16.490 --> 36:18.450]  Kind of sad.
[36:19.290 --> 36:24.090]  Some of the more interesting things is Akamai saw an increase in traffic.
[36:24.090 --> 36:28.690]  It went up to 74 hits per second, which is pretty cool.
[36:29.090 --> 36:39.290]  We saw page views, about 27.2% page views for the people that turned on IPv6 were using the clients were IPv6 enabled.
[36:39.290 --> 36:42.750]  We saw Amsterdam increase by 50%.
[36:42.750 --> 36:46.310]  We saw the overall Internet traffic.
[36:46.310 --> 36:52.230]  Yes, it went from 0.024 to 0.041.
[36:52.510 --> 36:56.950]  The last time I spoke, it was 0.004.
[36:57.490 --> 36:59.150]  So we increased.
[37:03.070 --> 37:06.450]  Here's what the increase looked like over a couple of years.
[37:07.610 --> 37:11.230]  Note the colors of the lines.
[37:11.590 --> 37:13.430]  This is really important.
[37:14.170 --> 37:20.630]  If we take a look at it, we'll notice that the green is native IPv6.
[37:20.630 --> 37:22.250]  There is no tunneling involved.
[37:22.630 --> 37:24.970]  The other colors are tunnels.
[37:25.450 --> 37:30.790]  Specifically, if you notice the red, after hounding Microsoft for all this time.
[37:33.310 --> 37:40.450]  Teredo, if you call it that, has lost interest or use out on the Internet.
[37:40.450 --> 37:44.870]  Also, notice the conversion of 6 to 4 and IPv6.
[37:45.870 --> 37:49.790]  If you remember, I mentioned the carrier grade NAD and 6RD.
[37:49.990 --> 37:53.830]  That's basically a spin-off of 6 to 4 addressing.
[37:54.230 --> 37:56.070]  So, some of those are intermixed.
[37:56.250 --> 38:03.270]  So, Google sees right now approximately 0.67 traffic on the Internet on a regular basis.
[38:06.410 --> 38:08.650]  So, let's take a look at the evolving defense tools.
[38:11.770 --> 38:12.650]  There we go.
[38:12.650 --> 38:14.490]  First, we have the addresses.
[38:17.310 --> 38:25.950]  If you're going to brute force, that is starting at 0000, 0000, 0000, blah, blah, blah.
[38:26.210 --> 38:30.090]  And we want to go to the end of a specific network address space.
[38:30.550 --> 38:32.150]  It's going to take a long time.
[38:32.670 --> 38:35.870]  I've been talking about this publicly for years.
[38:36.130 --> 38:41.270]  Mostly because it's really fun to get a call from a client saying, Somebody's scanning my net.
[38:41.850 --> 38:45.430]  And they're at AF.
[38:46.170 --> 38:47.510]  Should I be concerned?
[38:47.510 --> 38:53.290]  Well, your addresses are, you know, that's the last octet.
[38:53.290 --> 38:59.550]  Your addresses are FFFF colon 6C72.
[38:59.870 --> 39:00.930]  Yeah, I calculated.
[39:01.030 --> 39:01.850]  That's about 40 years.
[39:01.910 --> 39:02.830]  You'll be retired by then.
[39:02.910 --> 39:03.770]  Don't worry about it.
[39:04.310 --> 39:04.790]  Okay?
[39:05.030 --> 39:07.390]  So, I get this on a pretty regular basis.
[39:08.190 --> 39:17.230]  Fortunately, we've now started seeing people talk about some of the techniques that I actually taught in a class a few years ago.
[39:17.230 --> 39:21.270]  Which is really smart address searching.
[39:21.930 --> 39:29.570]  But one of the projects that I've been working is to identify which addresses those are so we can avoid those addresses.
[39:30.610 --> 39:51.210]  But within a large local space, if you have the ability to avoid addresses that are easily discovered, based on either a single ping, ping address query, or actually trying to enumerate DNS, or trying to enumerate the addresses themselves based on somebody calling one of their devices dead beef,
[39:51.350 --> 39:52.110]  as an example.
[39:52.810 --> 39:54.710]  There are ways of stopping that.
[39:55.270 --> 40:14.890]  Therefore, the nice thing about this is from a separability standpoint, if somebody's querying your network on addresses, on your local network on addresses that don't exist, this is a good indication of you have a worm, you have an adversary, or you have an application going mad.
[40:15.750 --> 40:16.350]  Okay?
[40:16.530 --> 40:23.750]  So this is a good way of actually getting some upfront time to respond to something like this.
[40:24.770 --> 40:33.650]  We also have large networks, and if they're sparsely assigned, they're large enough where it is also hard to identify.
[40:34.430 --> 40:41.710]  Especially addresses where the public addresses are not exposed out on your DNS, or not published someplace.
[40:42.170 --> 40:47.550]  You can put a spreadsheet out on Facebook to say, here's all my cool new IPv6 services.
[40:47.950 --> 40:56.870]  We also have local address ULAs, which is like it's a private address space, unique local addresses.
[40:56.870 --> 41:09.070]  They have a real advantage, and that is it provides you an additional address space that is not global routable, but has the ability to be globally unique within your infrastructure.
[41:09.350 --> 41:23.090]  So if you have to tie into somebody else very quickly, say you have to throw up a VPN, disconnect a VPN, whatever it is, it gives you the ability to have very quick routability and be able to apply security controls really well.
[41:23.090 --> 41:36.150]  We've also seen research on identity-based Internet protocol networking, where the address itself contains information about the device, or the user on the device, or the host.
[41:36.150 --> 41:56.510]  We've also seen a fast maneuvering technique, where, if your network's being scanned, and the adversary, it's predictable where the scan's coming to, the ability for a device to change addresses, so that it can't be scanned from an address space standpoint.
[41:56.510 --> 42:00.750]  So this is some of the more interesting things that are taking place.
[42:00.750 --> 42:02.170]  Think about a cloud environment.
[42:03.290 --> 42:06.170]  It might be useful in many cases.
[42:06.450 --> 42:07.590]  We also have IPsec.
[42:08.030 --> 42:13.270]  IPsec in the IPv4 domain has host-to-gateway, gateway-to-gateway, and host-to-host.
[42:13.690 --> 42:31.230]  What we can do with IPv6 is we can actually create a construct that, if you've ever been through, if you've ever been to a football game, you have the first set of people check you out and say, yeah, you're okay, and then you have to go through the next keeper of the tickets,
[42:31.450 --> 42:35.190]  and then maybe you have to go through another, you know, review or TSA.
[42:36.930 --> 42:43.410]  IPv6 provides the ability of having chained extension headers, IPsec.
[42:43.810 --> 42:51.970]  So essentially you can create these enclaves where things can become more and more secure as you go into the center enclave.
[42:52.330 --> 42:58.970]  That particular technique is called server enclave domain isolation.
[42:59.310 --> 43:01.310]  It's available on Microsoft today.
[43:01.550 --> 43:03.570]  It's part of one of their product space.
[43:03.570 --> 43:07.150]  There's some work being done to do that to Linux also.
[43:07.690 --> 43:13.570]  One of the other cool things specifically on IPsec and extension headers is Calypso.
[43:13.690 --> 43:23.430]  Calypso gives us the capability, if we have one of those trusted environments, to create an extension header that identifies the sensitivity and the classification of a packet.
[43:23.650 --> 43:28.010]  So the router then has the ability to drop information if needed.
[43:28.810 --> 43:30.850]  Again, another really good defensive thing.
[43:30.850 --> 43:33.990]  Identity management, another extension header.
[43:34.290 --> 43:41.510]  There is a proposal for a SCADA header that's specifically to try to protect and authenticate for SCADA.
[43:42.870 --> 43:46.330]  DHCP has been redone from a four handshake to a two.
[43:46.670 --> 43:48.090]  There's some signing available.
[43:48.090 --> 43:53.390]  We also have multicast NTP now with key signing.
[43:54.050 --> 44:01.730]  Also the ability to push, from a multicast standpoint, malware signatures.
[44:02.230 --> 44:14.210]  So essentially all your devices connect to a rendezvous point and you can point, you can with one push, push your anti-malware signatures out or maybe your IDS signatures.
[44:14.210 --> 44:16.410]  So we're seeing work in that space.
[44:17.070 --> 44:18.470]  It's very neat.
[44:19.190 --> 44:25.530]  Also the ability to leverage, the ability to put keys in your DNS secs so you can have trusted paths.
[44:26.190 --> 44:27.150]  That's another thing.
[44:27.310 --> 44:28.610]  There's many, many more things.
[44:28.850 --> 44:37.110]  The disadvantages, most of these are best in an IPv6 only environment, not in a dual stack environment.
[44:37.110 --> 44:38.150]  Kind of a problem.
[44:41.360 --> 44:41.960]  Okay.
[44:42.140 --> 44:42.340]  Tools.
[44:43.840 --> 44:44.440]  Yay.
[44:44.700 --> 44:47.400]  Nmap renamed its product to Nmap 6.
[44:47.420 --> 44:48.580]  Actually 6.1.
[44:50.060 --> 44:54.140]  Now it has the ability to do IPv6 OS scanning detection.
[44:54.310 --> 44:55.500]  They did a great job on that.
[44:56.360 --> 45:00.360]  Also they do the smart host detection now.
[45:00.560 --> 45:05.460]  So they can tell you from the outside or the inside, is the address wrong?
[45:06.640 --> 45:08.940]  You know, lots of other things, which is pretty nice.
[45:09.380 --> 45:11.100]  They allow you to do raw packets.
[45:11.200 --> 45:17.420]  So now you can script up an extension header or five extension headers to see what is happening with your product.
[45:19.080 --> 45:21.560]  The THC toolkit, great toolkit.
[45:21.920 --> 45:24.500]  It's just been updated, lots of additional tools.
[45:27.380 --> 45:29.940]  Metasploit, it's pretty much IPv6 clean.
[45:29.940 --> 45:32.140]  There's been a lot of contributions.
[45:32.480 --> 45:41.730]  I've worked with Mubix to come up with some ideas and he's coded the tools to support IPv6, which is pretty cool.
[45:42.580 --> 45:51.640]  And Fernando's also created a really nice toolkit that allows you to validate your flow control, fragmentation and all these other things.
[45:51.640 --> 46:03.290]  So you can actually fuzz these to see if your router switches, you know, hosts, operating systems, will flip over and die or continue working.
[46:07.690 --> 46:13.330]  Okay, places to look if you decide you want to look for IPv6 vulnerabilities.
[46:17.730 --> 46:18.400]  Good.
[46:19.820 --> 46:21.180]  Individual specifications.
[46:21.920 --> 46:26.340]  Go and take a look at the RFCs that are out there.
[46:26.580 --> 46:30.220]  You'll find a lot of times there's discussion on potential vulnerabilities.
[46:31.110 --> 46:32.900]  Also IEEE specs.
[46:32.940 --> 46:34.940]  You may or may not be aware of it.
[46:35.620 --> 46:53.200]  IPv6 is now being defined as the default Internet protocol for cars, for home devices, for healthcare, for a lot of other technologies to do end-to-end.
[46:54.060 --> 46:56.080]  Zigbee's got several gateways for it.
[46:56.280 --> 46:59.160]  So be aware that this is real interesting.
[46:59.380 --> 47:01.070]  Also interactions between RFCs.
[47:02.670 --> 47:07.500]  Discover specific or one RFC will say something, another RFC will say something.
[47:07.500 --> 47:14.280]  And by thinking through that you can find conflicting issues that can cause opportunities.
[47:14.660 --> 47:15.980]  Also the implementation.
[47:16.520 --> 47:20.980]  A lot of vendors don't fully implement the IPv6 specs.
[47:21.400 --> 47:32.320]  They may fully implement a spec or they could do only the musts or shoulds or should pluses or must pluses.
[47:32.320 --> 47:34.760]  They may also decide to change.
[47:34.900 --> 47:37.300]  As an example, if I'm going to do a for Microsoft.
[47:38.140 --> 47:44.740]  They justify changing the ability of a Microsoft.box to respond to a ping.
[47:47.480 --> 47:53.160]  FF02 colon colon one to be able to come back with address to say that it exists.
[47:53.560 --> 48:02.040]  They've modified their stack and justified that said that if anybody was to do this, this puts our systems at risk to be detected.
[48:02.400 --> 48:04.280]  So they've actually changed it.
[48:05.460 --> 48:17.640]  Fortunately, it was discovered, not by myself, that the ability to put one single extension header in that ping allowed you to get around that issue.
[48:17.860 --> 48:24.260]  So now you can put a specific extension header, extension header 35, and then still do the ping.
[48:24.260 --> 48:27.260]  And magically all your Microsoft boxes will still respond.
[48:27.520 --> 48:27.960]  Win.
[48:30.040 --> 48:31.160]  Configuration implementation.
[48:31.200 --> 48:34.800]  Again, people will misconfigure their implementation.
[48:36.400 --> 48:38.180]  NetWitness is a great product.
[48:38.640 --> 48:39.860]  Wonderful product.
[48:41.040 --> 48:46.780]  Just the formation of the IP addresses were flipped around in several different versions over the years.
[48:47.040 --> 48:51.320]  Now you can get real... the addresses work after, you know, poking at them.
[48:52.340 --> 48:53.320]  Operational experience.
[48:53.480 --> 48:56.180]  A lot of people don't have operational experience with IPv6.
[48:57.440 --> 48:59.700]  Talk to the people that have the most experience.
[48:59.700 --> 49:01.640]  They can teach you a lot of lessons.
[49:02.000 --> 49:05.180]  Those that don't, they don't implement it correctly.
[49:05.180 --> 49:11.720]  I just had to deal with an issue of the appropriate address on the gateway for devices.
[49:11.720 --> 49:24.540]  Well, if you inappropriately address it, it provides an opportunity to take the CPU on your upstream router and bring it to 100%.
[49:24.540 --> 49:26.280]  Great if you're a WoW gamer.
[49:28.380 --> 49:37.240]  One of the problems is that it also will fill up the neighbor cache table and cause the system to crash.
[49:37.240 --> 49:40.580]  So, there's actually two attacks within that space right now.
[49:42.440 --> 49:43.760]  Also, the training material.
[49:44.140 --> 49:46.740]  One of the more interesting things I've run across...
[49:46.740 --> 49:48.740]  Well, let me ask you a question, the group.
[49:49.240 --> 49:55.020]  Is it okay if the rest of the world knows what your VLAN construction is?
[49:55.920 --> 49:56.740]  Is it okay?
[49:56.960 --> 49:58.180]  Is that a no or a yes?
[49:58.960 --> 50:12.320]  Well, there's a well-known vendor in their training material that states that you should really encode the VLAN address in your addresses for all your routing infrastructure.
[50:12.460 --> 50:13.200]  Could this be good?
[50:13.940 --> 50:15.320]  That's up to your policy.
[50:15.940 --> 50:18.360]  And that's up to, you know, your paranoia.
[50:18.640 --> 50:22.960]  But be aware, we're seeing this on a regular basis.
[50:22.960 --> 50:26.700]  I read a lot of other people's training material and it's pretty fun to do.
[50:27.780 --> 50:29.680]  Also, integration with other systems.
[50:31.440 --> 50:43.820]  Although a lot of devices are tested for the ability to follow the spec and beta interoperate, a lot of them don't have the ability or haven't been tested for performance.
[50:43.820 --> 50:53.480]  I know of one DPI that I did some testing on a while back that it worked wonderfully at 100 megabit.
[50:54.140 --> 50:55.160]  Life is good.
[50:55.580 --> 51:00.960]  Unless I fragmented packets and then I could only get about 6K through the device.
[51:02.180 --> 51:02.700]  Okay.
[51:02.980 --> 51:04.840]  There was some rework that had to be done.
[51:05.020 --> 51:08.240]  But be aware that we're seeing that kind of thing.
[51:08.240 --> 51:14.120]  And we're also seeing things where they're not aware of how they've configured their products.
[51:14.380 --> 51:16.640]  So, again, they can cause problems.
[51:16.840 --> 51:20.040]  And also your policies, procedures, practices, testing.
[51:21.820 --> 51:23.440]  Again, a big problem.
[51:23.940 --> 51:32.900]  A while back, the policy for the credit card processing systems required that all your networks had NAT.
[51:33.620 --> 51:35.720]  It was part of the specification.
[51:36.500 --> 51:39.220]  Therefore, it kind of precluded the use of IPv6.
[51:39.760 --> 51:42.280]  That changed a little bit over a year ago.
[51:43.140 --> 51:43.660]  When?
[51:44.880 --> 51:49.520]  But we're also seeing a lot of other procedures and practices that have to change in your environment.
[51:51.960 --> 51:56.260]  Some of the issues that are also still on the table is resilient to attack.
[51:57.100 --> 51:58.540]  We haven't seen...
[51:58.860 --> 52:04.800]  I've been tracking IPv6 attacks for 14 years now.
[52:05.060 --> 52:08.260]  And we haven't seen a lot of them in the news.
[52:08.860 --> 52:15.400]  Mostly because people don't have sensors or not aware that they're running IPv6 on their infrastructure.
[52:15.400 --> 52:22.600]  It's not uncommon for somebody to use something like GogoNet, which is one of the tunnel providers.
[52:24.960 --> 52:28.060]  An individual of the company loaded on their system.
[52:28.260 --> 52:31.580]  But misconfigure it so it turns into the default router.
[52:32.100 --> 52:33.380]  And do it at home.
[52:33.840 --> 52:36.940]  And then bring it into the data center to troubleshoot the network.
[52:36.940 --> 52:43.200]  And then suddenly all they see is, I don't know, UDP, whatever packet, or TCP.
[52:43.600 --> 52:48.460]  And all their outbound connections are only tunneled connections.
[52:48.760 --> 52:49.800]  They see no HTTP.
[52:50.180 --> 52:51.040]  They see nothing else.
[52:51.580 --> 52:55.820]  This is a common problem that I see right now.
[52:57.270 --> 53:03.820]  We also see the attack tools really aren't on parity with what we have in the IPv4 domain.
[53:03.820 --> 53:09.200]  There are a lot of tools within, as an example, Backtrack, that haven't been updated, need to be cross-coded.
[53:09.640 --> 53:15.240]  And some of those actually have vulnerabilities in them that you have to be careful of if they're running with IPv6.
[53:16.200 --> 53:20.580]  And again, there's bag loads of vulnerabilities and bugs to be disclosed.
[53:20.720 --> 53:21.600]  I mean, it's wonderful.
[53:22.300 --> 53:30.020]  Some of the devices, firewalls, IDSs, IPSs, penetration testing tools, vulnerability assessments, scanning, audits, SIMs.
[53:30.020 --> 53:45.920]  We found one well-known SIM that wasn't providing a full IPv6 address with its, try not to use the brand names, connector, I guess.
[53:46.280 --> 53:51.160]  That it was only providing 32 bits of the 128 bits upstream.
[53:51.160 --> 53:54.000]  Therefore, it always looked like it was the wrong address.
[53:55.920 --> 54:00.100]  As of last week, it's still occurring and we've asked the vendor to fix it.
[54:02.120 --> 54:05.280]  A lot of wireless access points don't support IPv6.
[54:05.420 --> 54:06.220]  They have to be upgraded.
[54:06.400 --> 54:10.060]  A lot of protection and things like that have to be upgraded.
[54:10.060 --> 54:13.660]  I know of one IDS, IPS solution.
[54:14.160 --> 54:20.700]  It only provided the ability of stopping seven types of attacks.
[54:21.040 --> 54:24.180]  You couldn't put an eighth signature on the device.
[54:25.100 --> 54:25.820]  Okay?
[54:26.200 --> 54:29.620]  So, again, be aware that these are real issues.
[54:31.290 --> 54:34.100]  Also, you have to tweak your security policies.
[54:34.100 --> 54:38.500]  Now, if you're putting a firewall policy on, you're going to put it on twice.
[54:39.280 --> 54:40.960]  Make sure it's configured correct.
[54:41.120 --> 54:45.520]  Or maybe three times if you're using unique local and also global addresses.
[54:47.860 --> 54:49.620]  It's an issue you're going to have to deal with.
[54:50.340 --> 54:51.940]  Also, compliance standards.
[54:52.120 --> 54:56.720]  Make sure that your compliance auditors know what the heck's going on and you know how to actually tweak those.
[54:57.680 --> 54:58.240]  Education.
[55:00.320 --> 55:04.240]  The GUI administrators in the world like to point and click.
[55:06.560 --> 55:12.660]  Based on which vendor you're using, IPv6 fully isn't GUI compatible at this point.
[55:12.840 --> 55:14.080]  A lot of the interfaces are broke.
[55:14.560 --> 55:18.320]  As an example, Microsoft 2003, if you're running it at all.
[55:18.960 --> 55:24.740]  The plumbing is there, but there's no way of really communicating and managing it easily.
[55:25.280 --> 55:28.480]  And you'll find that it is a real pain.
[55:28.640 --> 55:30.180]  There's some things you really can't do.
[55:30.180 --> 55:31.580]  So, it forces you to upgrade.
[55:31.880 --> 55:35.960]  So, those are the kind of lessons that I've learned over the years.
[55:37.000 --> 55:37.520]  Education.
[55:38.180 --> 55:41.920]  Get those people trained on IPv6 because they all make many mistakes.
[55:42.820 --> 55:46.520]  Train your engineers, technicians, and definitely security personnel.
[55:46.520 --> 55:47.920]  Get them out there and trained.
[55:48.690 --> 55:53.760]  Again, the IPv4 mindset shouldn't bleed into the IPv6 environment.
[55:54.180 --> 55:57.060]  It's a different mindset on how things are working.
[55:57.420 --> 55:58.720]  And your developers.
[55:59.200 --> 56:01.360]  Get your developers upgraded.
[56:01.600 --> 56:05.020]  Make sure your libraries are supporting IPv6 fully.
[56:06.920 --> 56:08.340]  It's very important.
[56:09.790 --> 56:10.500]  Questions?
[56:11.670 --> 56:13.620]  Yes, I wanted to end with a bang.
[56:13.620 --> 56:14.560]  And the
[56:24.510 --> 56:36.910]  IPv6 environment for a customer who would insist on translating and that translation to another IPv6 rules just throwing their old network into the cloud environment.
[56:37.270 --> 56:39.710]  But I don't know if you can hear about that kind of work.
[56:39.930 --> 56:52.390]  So, is there a best practice of talking that we might as a, our defender requests neatly or whatever so that we're not getting into something in relation where we're ready to do something
[56:58.230 --> 57:04.210]  Can I suggest that you take a look at the upcoming IPv6, the CIO document.
[57:04.630 --> 57:08.410]  It includes a whole section on just cloud and some of the issues with cloud.
[57:09.030 --> 57:12.690]  And also cloud security and how the federal government's dealing with cloud.
[57:12.810 --> 57:14.570]  It points you to the FedRAMP stuff.
[57:14.770 --> 57:18.410]  But it talks specifically on IPv6 issues.
[57:18.790 --> 57:20.890]  Or you can get hold of me at...
[57:23.880 --> 57:24.600]  my blog.
[57:25.640 --> 57:27.320]  Any other questions, sir?
[57:27.460 --> 57:35.080]  How many organizations have you run into that say, we're not going to move the internal network into IPv6, we're going to use an IPv4 to IPv6 gateway?
[57:35.760 --> 57:38.600]  The gateways, a lot of people say that.
[57:38.840 --> 57:42.120]  Mostly it's a decision from a financial standpoint.
[57:43.000 --> 57:48.860]  One of the lessons that the federal government's learned is creating the procurement policy.
[57:48.860 --> 57:54.460]  And then over time, making sure everything from that day forward is definitely supporting IPv6.
[57:54.660 --> 57:58.600]  Therefore, your network is ready over time to be able to enable it and go.
[57:58.900 --> 58:08.020]  There's some organizations, it may be 2020 before you completely native v6 internal or 2025 based on your refresh cycle.
[58:08.020 --> 58:10.700]  But you have to do it.
[58:10.820 --> 58:15.180]  And you have to really get to that procurement policy and train those people to deal with it.
[58:15.480 --> 58:20.420]  Otherwise, you'll end up with medical equipment that doesn't support IPv6.
[58:20.720 --> 58:24.880]  That you want to use all the new features on IPv6 from a security or whatever.
[58:25.140 --> 58:34.420]  And then you have to have individual translators on every single Ethernet or create VLANs that are completely isolated from everything else.
[58:34.420 --> 58:36.520]  That's a lot more management headache.
[58:38.400 --> 58:39.600]  Any other questions?
[58:40.560 --> 58:41.660]  Here's my blog.
[58:41.960 --> 58:43.740]  These will be posted tomorrow morning.
[58:44.500 --> 58:46.120]  I have a lot of videos.
[58:46.360 --> 58:48.140]  Oh, sorry, you were in the light.
[58:49.040 --> 58:49.820]  Go ahead.
[59:01.970 --> 59:03.350]  Do you use NetFlow?
[59:07.090 --> 59:07.690]  Okay.
[59:08.070 --> 59:16.530]  One of the wonderful things about having end-to-end connections, especially if they're devices that are... depending on how they're configured.
[59:17.190 --> 59:18.490]  Keep track of that.
[59:18.770 --> 59:24.090]  Because what you can do is if the last 64 bits is an EUI.
[59:24.410 --> 59:26.930]  You can use that to determine what brand it is.
[59:27.410 --> 59:33.850]  And use the second part of it for the approximate age of how long it's been there, which is really nice.
[59:35.270 --> 59:40.550]  If it's not, it's probably a Microsoft device with some kind of random or it has privacy addresses on.
[59:41.710 --> 59:45.350]  Also, that at least gives you what your upstream device is.
[59:46.050 --> 59:51.010]  So you can find that... you can trace route to it and find out what that upstream device is.
[59:51.110 --> 59:55.530]  And if it's a router, there's a good chance it's a well-known endpoint.
[59:55.530 --> 01:00:02.750]  It makes it really nice for intrusion detection and identifying endpoints very quickly through environment.
[01:00:03.070 --> 01:00:09.690]  It kind of allows you to find the hidden IT infrastructures that exist in every organization very quickly.
[01:00:10.050 --> 01:00:11.770]  So NetFlow is a good solution.
[01:00:11.770 --> 01:00:21.890]  Or if you have the ability to do the upstream SNMP v3, just look for the MAC addresses, look for the other information.
[01:00:22.990 --> 01:00:25.170]  Make sure you switch supports IPv6.
[01:00:26.750 --> 01:00:27.750]  Any other questions?
[01:00:30.980 --> 01:00:34.160]  You mentioned training for new people and staff.
[01:00:34.660 --> 01:00:37.040]  And I know a lot of shops for small reasons.
[01:00:37.720 --> 01:00:40.780]  So you've got to take a shop that has no experience IPv6.
[01:00:40.960 --> 01:00:42.560]  They've been ignoring it at the SAM.
[01:00:43.380 --> 01:00:50.640]  Is there anything that you know that is a good, like, almost don't use for IPv6?
[01:00:50.640 --> 01:00:52.560]  Like, start here at least.
[01:00:53.360 --> 01:00:55.620]  All the smaller companies start...
[01:00:55.620 --> 01:01:01.220]  A good reference is if you go to he.net, Hurricane Electric.
[01:01:01.640 --> 01:01:06.360]  They have a really base course on IPv6.
[01:01:06.360 --> 01:01:19.980]  And it's really about setting up your home computer and your home servers to be able to route IPv6, to be able to deal with the addressing issue, to configure your DNS, to configure your external facing devices.
[01:01:19.980 --> 01:01:21.620]  It's a good kickstart.
[01:01:22.560 --> 01:01:24.620]  Also, there's a lot of stuff on YouTube.
[01:01:25.140 --> 01:01:30.240]  My blog, everything I can find, I'm throwing up on that and referencing other training material.
[01:01:30.520 --> 01:01:33.140]  The EU has some training material out there.
[01:01:33.460 --> 01:01:38.120]  There's lots of people talking about it at this point.
[01:01:38.120 --> 01:01:45.000]  Especially in the APNIC world and in Europe.
[01:01:45.180 --> 01:01:49.980]  There's a lot of communications going on with IPv6 and a lot of training material that's free.
[01:01:50.760 --> 01:01:58.460]  So, and then you have SANS and you have Cisco and Juniper and they all have kickstart toolkits and such.
[01:01:59.520 --> 01:02:00.680]  Any other questions?
[01:02:01.260 --> 01:02:02.520]  Another one in the light.
[01:02:09.680 --> 01:02:17.240]  I've heard the argument that IPv6 is very complex and maybe that that's slowing down into the deployment of it.
[01:02:17.380 --> 01:02:17.660]  I don't know.
[01:02:17.780 --> 01:02:20.060]  Are you happy with IPv6 as it is?
[01:02:20.240 --> 01:02:23.420]  Or is that just kind of sour grain from the part that you don't want to deploy?
[01:02:23.700 --> 01:02:30.140]  Yes, when you're running dual stack, when you're running both IPv4 together and IPv6, it is very complex.
[01:02:30.660 --> 01:02:37.140]  From a networking protocol, think of the first time you had to sit down and set up a wireless access point.
[01:02:37.400 --> 01:02:44.900]  And then configure all the clients and the complexity of dealing with routing and MAC address isolation and keying and all the other things.
[01:02:45.100 --> 01:02:47.740]  It took some time to understand how that works.