We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Recent Advances in IPv6 Security

00:00
subtitles
off
playback rate
1
subtitles
off
English (auto-generated)
playback rate
0.25
0.5
0.75
1
1.25
1.5
1.75
2
quality
576p
17
 Cite
 Share
 Download Purchase
No logo availableBerkeley System Distribution (BSD), Andrea Ross
 Fernando, Gont

Formal Metadata

Title
Recent Advances in IPv6 Security
Title of Series
Number of Parts
24
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
During the last few years, the UK CPNI (Centre for the Protection of National Infrastructure) carried out the first comprehensive security assessment of the Internet Protocol version 6 (IPv6) and related technologies (such as transition/co-existence mechanisms). The result of the aforementioned project is a series of documents that provide advice both to programmers implementing the IPv6 protocol suite and to network engineers and security administrators deploying or operating the protocols. Part of the results of the aforementioned project have been recently published, leading to a number of improvements in many IPv6 implementations. Fernando Gont will discuss the results of the aforementioned project, introducing the attendees to the "state of the art" in IPv6 security, and providing advice on how to deploy the IPv6 protocols securely. Gont will also discusss recent advances in IPv6 security areas such as Denial of Service attacks, firewall circumvention, and Network Reconnaissance, and will describe other IPv6 security areas in which further work is needed. Additionally, he will demonstrate the use of some attack/assessment tools that implement new network reconnaissance techniques or that exploit a number of vulnerabilities found in popular IPv6 implementations. The IPv6 protocol suite was designed to accommodate the present and future growth of the Internet, and is expected to be the successor of the original IPv4 protocol suite. It has already been deployed in a number of production environments, and many organizations have already scheduled or planned its deployment in the next few years. Additionally, a number of activities such as the World IPv6 Day in 2011 and the upcoming World IPv6 Launch Day (scheduled for June 2012) have led to an improvement in IPv6 awareness and an increase in the number of IPv6 deployments. There are a number of factors that make the IPv6 protocol suite interesting from a security standpoint. Firstly, being a new technology, technical personnel has much less confidence with the IPv6 protocols than with their IPv4 counterpart, and thus it is more likely that the security implications of the protocols be overlooked when the protocols are deployed. Secondly, IPv6 implementations are much less mature than their IPv4 counterparts, and thus it is very likely that a number of vulnerabilities will be discovered in them before their robustness matches that of the existing IPv4 implementations. Thirdly, security products such as firewalls and NIDS's (Network Intrusion Detection Systems) usually have less support for the IPv6 protocols than for their IPv4 counterparts, either in terms of features or in terms of performance. Fourthly, the security implications of IPv6 transition/co-existence technologies on existing IPv4 networks are usually overlooked, potentially enabling attackers to leverage these technologies to circumvent IPv4 security measures in unexpected ways.
The Technical BSD Conference 20122 / 24
00:00
VideoconferencingRankingoutputInformation securityPresentation of a groupPresentation of a groupInformation securityType theoryKey (cryptography)Arithmetic progressionXMLComputer animation
00:45
Presentation of a groupComputer configurationInformation securityTelecommunicationMereologyCASE <Informatik>Computer configurationStapeldateiPhysical systemForcing (mathematics)Online helpNumberPresentation of a groupInternetworkingDefault (computer science)Computer animation
02:43
Presentation of a groupInformation securityMereologySystem identificationInformation securityImplementationMereologyVulnerability (computing)Latent heatPresentation of a groupProjective planeCASE <Informatik>Patch (Unix)Density of statesMultiplication signStaff (military)Computer animation
04:51
UnicastingverfahrenAddress spaceFile formatIntrusion detection systemInterface (computing)Embedded systemIP addressAddress spaceString (computer science)WordCASE <Informatik>Interface (computing)Slide ruleFacebookGroup actionMereologyComputer configurationMathematicsSoftwareBitConfiguration spaceDifferent (Kate Ryan album)ResultantObservational studyMobile appIRIS-TDemoscene3 (number)RechentafelRule of inferenceSubject indexingPosition operatorPhysical systemComputer animation
07:53
SpacetimeAddress spaceNumber1 (number)System callSpacetimeLoop (music)Point (geometry)Address spaceBitTheory of relativityComputer animation
09:12
Network operating systemAddress spaceRouter (computing)Computer networkInformation privacyWeightMenu (computing)MeasurementMountain passState observerObservational studyAddress spaceRouter (computing)InternetworkingSign (mathematics)StatisticsSystem administratorResultantNumberOpen sourceWindowMeasurementCASE <Informatik>Physical systemFile Transfer ProtocolWeb 2.0Table (information)Client (computing)Service (economics)Information privacyBitServer (computing)Multiplication signInterface (computing)Slide ruleForm (programming)Computer virusShared memoryInterprozesskommunikationImplementationTransport Layer SecurityMathematicsBit rateConfiguration spaceSelectivity (electronic)MereologyFigurate numberLevel of measurementLine (geometry)Solid geometrySoftware maintenancePhysical lawStudent's t-testComputer animation
13:33
Address spaceFeasibility studySpacetimeSelf-organizationSoftwareNeuroinformatikAddress spaceSelf-organizationBitGame theorySquare numberCuboidInformationSlide ruleMathematicsSpacetimePhysical systemPurchasingInterface (computing)Type theoryCASE <Informatik>Server (computing)Internet service providerPhysical lawRight anglePresentation of a groupElectronic mailing listService (economics)Computer networkLattice (group)SequenceResultantComputer animation
18:30
Address spaceVisualization (computer graphics)SpacetimeVMware ESX ServerRange (statistics)Address spaceDifferent (Kate Ryan album)VirtualizationBitCASE <Informatik>Configuration spaceSpacetimeSlide ruleRange (statistics)CuboidWordWorkstation <Musikinstrument>RippingBeat (acoustics)Computer animation
20:13
Address spaceSpacetimeType theoryCASE <Informatik>Address spaceDigitizingRange (statistics)SpacetimePresentation of a groupState of matterService (economics)Computer animation
20:57
Address spaceSpacetimeSpacetimeCASE <Informatik>Interface (computing)MathematicsBitSoftwareSelf-organizationRight angleComputer animation
21:51
Address spaceSpacetimeInterface (computing)Video trackingHTTP cookieInheritance (object-oriented programming)Identity managementLeakHeuristicLine (geometry)Process (computing)CASE <Informatik>Scaling (geometry)SoftwareHTTP cookieInterface (computing)Physical systemIdentity managementAddress spaceInformation privacyWeb 2.0Server (computing)Food energyService (economics)Fitness functionComputer iconComputer animation
24:00
Video trackingAddress spaceInformation securityRandom numberAdditionClient (computing)AdditionAddress spaceServer (computing)Information privacyWeb 2.0Point (geometry)Physical systemInterface (computing)Proof theoryMultiplication signRandomizationConfiguration spaceUniqueness quantificationService (economics)TrailRight angleCovering spaceRule of inferenceSoftwareDemosceneData managementMathematical analysisComputer animation
27:00
Address spaceLogical constantVideo trackingAddress spaceDifferent (Kate Ryan album)TrailUniqueness quantificationPhysical systemMathematicsWindowMultiplication signInterface (computing)Port scannerAlgorithmHypermediaService (economics)Stability theorySlide ruleText editorComputer animation
28:41
Type theoryConfiguration spaceAddress spaceInformation privacyOrthogonalityPersonal digital assistantAddress spaceVideo gameSoftwareSlide rulePattern languagePredictabilityIntrusion detection systemInterface (computing)Information privacyType theoryServer (computing)Lattice (group)Computer animation
29:58
Address spaceInformation privacyInterface (computing)FunknetzPulse repetition frequencyFunction (mathematics)Hash functionLink (knot theory)Local ringDefault (computer science)Address spaceHash functionInterface (computing)Multiplication signParameter (computer programming)Functional (mathematics)Key (cryptography)Subject indexingResultantSoftwareNumbering schemeMechanism designInformation securityCost curveEndliche ModelltheorieComputer networkRight angleFilm editingComputer animation
31:46
Function (mathematics)Address spaceInterface (computing)Intrusion detection systemComputer networkInformation privacyHash functionPulse repetition frequencyLink (knot theory)Local ringFunknetzDefault (computer science)Address spaceGoodness of fitPhysical systemInterface (computing)CASE <Informatik>MathematicsPredictabilitySoftwareAlgorithmIntrusion detection systemComputer configurationView (database)Standard deviationLine (geometry)Revision controlPoint (geometry)Stability theoryArithmetic meanMobile appMultiplication signHypothesisGame theoryRight anglePower (physics)ImplementationCollisionConnected spaceSemiconductor memoryLattice (group)Mathematical analysisComputer animation
34:51
Information privacyAddress spaceFunction (mathematics)Computer networkAssembly languageRouter (computing)EmailSystem identificationInformation securityDensity of statesField (computer science)Assembly languageEmailBitPrice indexCASE <Informatik>Right anglePredictabilityDifferent (Kate Ryan album)NumberCommunications protocolSheaf (mathematics)ImplementationWhiteboardInterface (computing)Intrusion detection systemInformation securitySystem identificationDirect numerical simulationDatabase transactionComputer animation
36:36
AlgorithmPhysical systemOpen setElectric currentFreewareRandom numberPatch (Unix)Dependent and independent variablesComputer configurationResultantRevision controlSingle-precision floating-point formatAlgorithmImplementationSystem identificationPredictabilityWindow1 (number)Sampling (statistics)LinearizationCASE <Informatik>Physical systemDifferent (Kate Ryan album)Multiplication signActive contour modelLie groupExecution unitComputer animation
38:50
Information securityDifferent (Kate Ryan album)Standard deviationPhysical systemCASE <Informatik>Interactive televisionImplementationRouter (computing)1 (number)TheoryLatent heatSoftwareArithmetic meanDifferent (Kate Ryan album)Table (information)Computer animation
40:18
Information securityDifferent (Kate Ryan album)Standard deviationInclusion mapAtomic numberMixed realityNormal (geometry)CASE <Informatik>Software testingImplementationTable (information)Arithmetic meanEnvelope (mathematics)System callEmailBitReal numberLatent heatCuboidTranslation (relic)Message passingProgrammable read-only memoryAtomic numberFamilyBeat (acoustics)Computer animation
42:49
Windows VistaPay televisionFreewareOpen setElectric currentPatch (Unix)Dependent and independent variablesPhysical systemEmailAtomic numberCommunications protocolVulnerability (computing)PredictabilitySystem identification1 (number)Right angleProcess (computing)Point (geometry)Multiplication signRevision controlIdentifiabilityCore dumpParticle systemImplementationMessage passingInformation securityElectronic program guideOpen setComputer animation
44:59
Information securityParity (mathematics)Computer networkDynamic Host Configuration ProtocolInformation securityServer (computing)Parity (mathematics)MeasurementWordLevel (video gaming)EvoluteWater vaporTheoryReading (process)JSONComputer animation
46:15
Information securityFundamental theorem of algebraKolmogorov complexityRouter (computing)Link (knot theory)Message passingComputer configurationCASE <Informatik>InformationMögliche-Welten-SemantikRight angleInheritance (object-oriented programming)Multiplication signComputer animation
47:31
EmailExtension (kinesiology)CASE <Informatik>Public key certificateComputer configurationMechanism designDifferent (Kate Ryan album)InformationGoodness of fitTerm (mathematics)ImplementationSymbol tableLevel (video gaming)SoftwareConfiguration spaceInclusion mapArmRouter (computing)Point (geometry)Group actionMultiplicationComputer animation
50:15
Block (periodic table)AuthorizationRemote Access ServiceConditional-access moduleInformation securityKolmogorov complexityFundamental theorem of algebraExtension (kinesiology)Dynamic Host Configuration ProtocolEmailRouter (computing)Different (Kate Ryan album)Mechanism designMessage passingRight angleWhiteboardGodCASE <Informatik>Data managementThermal expansionComputer animation
51:07
Extension (kinesiology)EmailMultiplication signRight angleRule of inferenceOperator (mathematics)Form (programming)Position operatorVector potentialImplementationSystem callGroup actionSet (mathematics)Router (computing)Intrusion detection systemBitComputer animation
52:09
AuthorizationBlock (periodic table)Remote Access ServiceStatement (computer science)ChainEmailFirewall (computing)ChainImplementationMultiplicationBitFilter <Stochastik>CASE <Informatik>EmailLatent heatSound effectPresentation of a groupComputer animation
53:16
EmailEntire functionChainAreaBlock (periodic table)Entire functionNumberExtension (kinesiology)CASE <Informatik>ChainEmailGroup actionMathematicsComputer wormView (database)Computer animation
54:16
MultiplicationAddress spaceError messageComputer configurationDependent and independent variablesError messageCASE <Informatik>Computer configurationType theoryInternetworkingAddress spaceMessage passingFinite-state machineComputer animation
55:17
Information securityImplementationVulnerability (computing)Latent heatCASE <Informatik>Presentation of a groupMixed realityParticle systemInternetworkingImplementationInformation securityComputer animation
56:13
Hacker (term)EmailInformation securityElectronic mailing listJSONComputer animation
Transcript: English(auto-generated)
00:05
So disclaimer for this presentation, it assumes that you know the basics of v4 security and all the basics of IPv6 security. And the reason for which I include this disclaimer is usually when you watch v6 security presentations,
00:25
half of the presentation is IPv6 introduction. So there's nothing like this in here, or shouldn't be much of that. And the second one is that this is, again, a work in progress. So if you have comments, criticisms, and that kind of stuff, it's welcome.
00:43
So what's the motivation for this presentation? During or later, you will be deploying IPv6. And in practice, most likely, you have already at least actually deployed it. Because in the case of most general purpose operating systems, they already ship IPv6 support enabled by default.
01:04
Even if you cannot use it to access the global internet, that support is still there, at least for local communications. We all know that there are a number of challenges, security challenges, and also operational challenges that come with IPv6.
01:21
So the question here is what we can do about them. And I will kind of go through the possible options. And even when some of them may sound funny or may look funny, there are different communities that adopt each of the different options. So option one is essentially to ignore those challenges.
01:46
Even when this may sound stupid or it is stupid, you may see that many of the problems of IPv6, in some cases, this is kind of like the case in some tax forces, to my experience.
02:02
They think that discussing IPv6 security issues goes against IPv6 deployment. So for the most part, they try to ignore them and try to prevent discussions of those things from going on. Option two, it's essentially, well, sometimes it's a consequence of option one.
02:22
So you're ignoring the IPv6 security issues. But eventually, you find out about them, and it doesn't look or they don't look nice. And option three is the path that we are trying to follow, which is about discussing the security implications of IPv6 and trying to do something about them.
02:45
As I mentioned before, I think since 2007 or so, I've been working most of the time on IPv6 security research. So far, the project has been about analyzing the IPv6
03:04
specifications and trying to find out ways in which you could actually break an IPv6 implementation. We didn't just look on the specifications themselves, because usually, there are many things that are left to implementations.
03:21
So in many cases, we also looked at what implementations were doing. And when we actually found the things that could break, we produced tools to actually assess those issues. And in those cases in which we were able to confirm that there were vulnerabilities or there were things that could be used for DOS or, yeah,
03:46
even complete DOS of some implementations, we tried to contact vendors and have them patch their own implementations in the hopes of improving IPv6 security. Part of this stuff has already been taken to the ATF.
04:03
And not all of the stuff, not all of the work that we have produced so far, because in some cases, there are vulnerabilities that have not yet been patched. So we are trying to take most of the stuff to the IETF. And the idea is that during this year,
04:20
we'll complete the rest of the stuff that we have not yet submitted there. Well, this talk is about ongoing work, our ongoing work to improve IPv6 security. Again, this presentation shouldn't be taken as a lecture, but actually as a way of proposing ideas of fixing things.
04:41
So if you have a different idea or a different approach on how to approach many of the issues that I will be discussing, so please speak up. So first one is about advances in IP addresses. This is the only slide that I have as a kind of introduction to the topic.
05:00
This is the syntax of global IPv6 addresses. Essentially, they are the same as B4 addresses. You have a global routing prefix, which is the prefix that is assigned by your app string. Then you have a few bits for the subnet ID, which is the same thing that you do for B4 already. And then finally, probably the only difference
05:22
is that in IPv6, you have an FASID, which is analogous to the host ID part in the IPv4 addresses. The only thing that changes in the case of IPv6 is that the interface ID is much larger. And there are actually different ways in which you can select that value.
05:42
Of course, typically in the case of B4, since the addresses are scarce, usually select them sequentially. Whereas in the case of IPv6, since you have 64 bits, you have several options for selecting the interface ID.
06:00
So the possibilities are, well, the first one, which is the traditional stateless auto configuration, is to include the MAC address in the interface ID. There are some bits that are changing, some bits that are flipped. But essentially, you include the MAC address there. Another possibility is to include the B4 address
06:21
in the interface ID. That's usually done, for example, in infrastructure devices. In which, for example, if you recall, if you remember the IPv4 address of a system, then it's kind of like straightforward to generate the interface ID in that way, so that the IPv6 address is also easy to remember.
06:43
Then in the third bullet, low byte addresses. Essentially, when you have low byte addresses, you set the interface ID to all zeros. And then you just change the last byte. That's usually the result of manual configuration. If you are going to manually configure an address,
07:00
you don't select so many bytes randomly, but you just set them all to zeros, and then you just change the last one. Then you have worthy addresses that are not that usual, but are still there in real networks. In this case, for example, the address includes the word dead beef.
07:20
And for example, last year, during the whole IPv6 day, I think Facebook's address was encoded in a similar way to this. There are some addresses like this, even when it may sound funny or, yeah. And finally, the last bullet talks about transition and coexistence technologies.
07:41
For example, if you have 624, or you have Tirido or other transition technologies, in some cases, they mandate the way in which you have to select the interface ID. So let's take a look at some of the problems that these possibilities have.
08:01
You may have here the URL relation that sends to the increased IPv6 address space. IPv6 host scanning attacks are impossible. Actually, this wasn't just a quote that I randomly produced, but actually I looked IPv6 scanning on the web, and this is one of the ones that came up.
08:20
There are worse numbers. These guys say that it should take something like 500 million years to produce this host scanning attacks, but there are other guys that produce even larger numbers. So the idea is to try to analyze this, what I think is a duration, and try to find out whether this is true
08:41
or whether it isn't. So as a kind of introduction to the problem, usually the guys that come up with these numbers assume that if you have to scan an IPv6 subnetwork, you have to go through the entire slash 64. So the question here is whether,
09:02
at the point in which you want to scan an IPv6 subnet, the search space is really 64 bits or not. So this is the only study that I could find in which some guy, David Malone, measured how IPv6 addresses are assigned in practice.
09:23
There is a couple of problems with this study. The first one is that it dates back to 2008, which means that it's a bit old, and since the way in which v6 addresses are generated over time, for example, as time has passed by,
09:41
there are more systems that implement temporary addresses and other things. So probably you could argue that these results are obsolete or a little bit obsolete nowadays, but so far, this is the only work, the only research work that I have been able to find that has taken care of measuring
10:02
how addresses are selected in the internet. So what this guy did essentially was he set up, I think it was a web server, had different clients connect to them, to the server, and he just logged the addresses and tried to analyze the different ways in which those services were selected.
10:21
So for the case of host, which of course were the systems that connected to his web or FTP server or whatever, this guy found out that 50% of the addresses were the result of stateless auto-configuration, which means that they were addresses that were including the MAC address in the interface ID.
10:41
Then there was a 20% of addresses that included an IPv4 address in the interface ID, then a 10% of Terido addresses. For the most part, they are usually the result window systems, even when they are open source implementations, I would say that Terido provides a very poor user experience.
11:08
Pure. And then we have 8% of low byte addresses and a 6% of privacy addresses, which are what are usually called or known as temporary addresses.
11:23
Again, if you look at this table, you can sort of tell that these statistics have probably changed over time. And one of the reasons are, for example, that in the last few years, privacy addresses have been incorporated into more implementations.
11:43
So for example, Windows, FreeBSD and other same thing that OpenBSD implemented that not that long ago. So these numbers are supposed to be changing if they have not changed already. And another thing that could be a sign that this study didn't actually measure
12:02
like a broad population of host is that it found out 20% of IPv4 base addresses. And usually, only manually configured host have a IPv4 base addresses. So it's very likely that most of the users
12:21
that were accessing the web server or FTP server were kind of like technical users that had configured IPv6 manually. So these numbers should change. Now, if you take a look at the second table that provides the statistics for router addresses,
12:41
you can see that there is a 70% of low byte addresses, which means that in most cases, and this shouldn't come up as a surprise, 70% of the addresses are manually configured. So that's why they are low byte. The interface ID is set to all zeros and the administrator just changed the last byte.
13:01
Then you have a 5% of IPv4 base addresses and then the rest of the numbers are mostly marginal. This slide contains the URL of this study and I find it like quite interesting and important to follow because it was one of the few guys that actually cared to measure the IPv6 internet.
13:22
So I have been chasing this guy who reproduced the same study again and hopefully either this year or next year, he will repeat this study so that we get more up-to-date numbers. So let's take a look at those addresses types that had the larger percentage.
13:42
One of the address types that I described was those addresses that we saw from Slack or Autoconfusion. And essentially those addresses include the MAC address in the interface ID. So this slide describes or illustrates
14:00
the syntax of just the interface ID, not the global routing prefix or the subnet ID, but just the interface ID. So what you can see is that essentially what you do is you split the MAC address in two and you stuff two bytes, which are like fixed in the middle, okay? There's actually an additional change that you do, which is flipping one of the bits in the IEEE OUI,
14:24
which is the universal and local bit. But essentially what you do is you split the MAC address in two and you stuff those two bytes in the middle. So let's assume that you know
14:44
or you can guess the first three bytes and what is the reason for which you could know those first three bytes? Let's say that an attacker is trying to perform an IPv6 of a target network. And let's just assume that that target network is that of a big computer vendor.
15:03
And it wouldn't be that crazy to assume that all of the systems or most of the systems that have been deployed on that network are manufactured by that vendor itself. So if you were to scan, let's say an HP network, well, it's most likely the case that there are HP servers in that network
15:23
and you could tell what the first three bytes of the interface ID or put another way, what is the IEEE OUI for that vendor. So if you assume that you can guess or know first three bytes, then the two fixed bytes,
15:44
of course, are known. And then you're left with only 24 bits, which would mean that you have reduced the search space from the original slash 64 to only 24 bits. That doesn't necessarily mean that it's going to take a couple of minutes to scan an IPv6 network,
16:02
but it's certainly a big change when compared to the slash 64 bits that was assumed or that is usually assumed. Now, there are other things that should be taken into account. For example, if it's a large organization, they usually don't purchase just a single system, but they usually purchase systems in a bunch of them.
16:24
And one thing that we have found is that the last three bytes of the MAC address, even when they could be like randomly selected, they're usually sequentially selected. So let's say if I buy 100 boxes from the same vendor,
16:41
chances are that the MAC addresses are sequential, right? So if you have that kind of information of the target network, rather than just trying random addresses in that IPv6 subnet, you could just buy random places in the other space, like playing, I don't know if it's a popular game here,
17:03
novel battle, when you know that you have a ship that has four squares. So you don't need to shoot like every square. But if I know that the ship is, let's say two squares, I shoot here and here and there. So that's one possible approach to actually scan an IPv6 network.
17:20
If you know, for example, that the target network has purchased equipments or boxes in large bunches. Another thing that we have found, and we are actually working on some document to publish these results, is that even if the same organization doesn't own all the consecutive MAC addresses,
17:42
usually the consecutive MAC addresses are within the same, are geographically close, because usually there was some company or some provider that bought those bunch of boxes. So then usually they sold those boxes to places or companies or organizations that are in geographically close locations, right?
18:04
So that means that if, for example, you have any kind of information about the MAC addresses of vendor or of some vendor in the region, and if you know that there is some organization that has purchased equipment from the same vendor recently,
18:22
then that information can be useful to actually perform an IPv6 scan on the target network. So more about the IPv6 addresses that embed the MAC addresses. Another interesting case is that of virtualization.
18:41
For example, if you take a look at VirtualBox, they always select the MAC addresses from the same IEEE UI. So in this case, it's 080027, which means that if your IPv6 scanning attack is targeting VirtualBoxes,
19:01
then you don't even have to guess the first three bytes of the MAC address. They are actually known. VMware is even a more interesting case because, for example, if you use automatic MAC addresses, which means that you didn't manually configure them, they use a fixed IEEE UI,
19:20
and then the next 16 bits are taken from the IPv4 address of the real host. The only bits that change are the low other eight bits, which means that the search space, it's reduced in that case to only eight bits. In the case of manually configured MAC addresses
19:42
in VMware, they use a different IEEE UI, which is 005056, and for the rest of the bits, they don't really randomize them, but select them from the range that is specified in this slide. I mean, they randomize the value,
20:00
but they don't use the whole space that is available, okay? So in that other case, manually configure MAC addresses in VMware, the search space is reduced to 22 bits. Taking a look at the other address types that have kind of like large percentage,
20:24
if you look at IPv6 addresses that embed an IPv4 address, they typically look as that address in the second ballot. Well, actually I missed a digit there, but essentially the idea is that since they embed an IPv4 address,
20:43
the search space is the same as in the IPv4 case. So if you know the v4 range that they are using, essentially you just scan, you just search through the v4 range, but not just randomly. In the case of low byte addresses, of course this is trivial.
21:01
So usually what you find is that they set the interface ID to all zeros and they just change the last byte. So in that case, the search space would be, for example, just eight bits, but there are other cases, for example, we have found that some organizations, they don't change just the last byte,
21:21
but for example, they change the, let's say the second byte starting from the right, or the third byte starting from the right. So there are a few other variants, but in any case, if you were to get kind of network, you could probably try the first few values
21:40
in the last byte, then the first few values in the second last byte, and so on. So in the worst case scenario, usually the search space is eight bits or 16 bits. So this was the first problem. And the bottom line is that IPv6 host scanning attacks are really feasible.
22:02
I'd say that the only thing that will probably change when compared to IPv4, is that in IPv4, the scale of the problem was so small that even doing a poor job was good enough. Now, in the case of v6, if you just try to go through the entire slash 64,
22:21
yes, you are not going to be able to find anything there. But if you were to implement like heuristics in your scanning tool, then my take is that these scanning attacks are possible. There is another issue with IPv6 addresses. If you look at the traditional,
22:41
the way in which addresses, IPv6 addresses are generated with Slack. As I said before, they typically include the MAC address in the interface ID. So what's the problem with that? The MAC address is a globally unique value, which means that you are including like a kind of a super cookie in the interface ID,
23:00
which means that even as you move from one network to another, the interface ID is going to be constant. I connect to his web server, and then I connect to that other web server, and then I move to another network, and I connect to the same two servers, they can tell that I'm in the same system that was accessing them in the other network.
23:22
So this is just one example. In the first, in this bullet, you can see that there is a node that generates an address in which the subnet ID, if you want, is just one. Then in the second case, the subnet ID could be two,
23:41
but in the two cases, the interface ID is the same, because again, it is including the MAC address in the interface ID. So this introduces a problem that we didn't have in IPv4, which is a problem with privacy. You are kind of like disclosing the identity of your own device.
24:01
So I will just go through the two mitigations that have been around for these two problems, then we'll comment on why they are not really effective, and then I will try to describe what we have suggested on this topic. So when it comes to the problem of host tracking,
24:22
the solution that the IETF produced years ago was what is usually known as privacy addresses or temporary addresses. Essentially, they are addresses that are randomized. So the idea is that if you use random addresses, of course, it's not going to be possible to track you at least,
24:40
just looking at the interface ID. The problem is that the way in which the privacy addresses were specified, they require you to have not just privacy addresses, but also the traditional Slack addresses. So the idea is that you use these temporary addresses in addition to the traditional
25:01
auto-configuration addresses, but not in replacement of those addresses. So what are the problems of that approach? First of all, temporary addresses are difficult to manage. I know of many, many people that are disabling these addresses, because if these addresses are enabled on their network,
25:22
let's say that some system gets infected, and then they notice that, let's say a couple of days later, so they say, okay, what was the system that was using this blah-blah IPv6 address? Since these IPv6 addresses change over time, it's not possible to tell that, right?
25:41
And since auto-configuration doesn't require like central management, you don't have any kind of central log that tells you which system was using which address at which point in time. So this is one of the reasons for which many people are disabling them. Another problem with this is that, as I said before,
26:00
these addresses are used in addition to the Slack addresses. So even when tracking a host that employs these addresses harder, it's not really impossible. Let's say that he's connecting to my web server. When he connects to my web server, I could obtain his Slack address, and then at some other point in time,
26:21
when he connects from some other network, I can always actually, for example, send a ping or Samsung kind of proof packet to the stable address, to the traditional Slack address, and find out whether that system is there or not. So the idea is that the problem with the temporary or privacy addresses is that they don't replace the addresses
26:43
that include the Mac address, but are used in addition. And as long as there is some kind of address that uses a globally unique value, using those addresses will still be possible to track.
27:02
There are some things that have been done in the industry to mitigate the problem of host scanning. If you take a look, for example, I think it's from Windows Vista and on, what they do is they have replaced the IPv6 addresses that include the Mac address in the interface ID,
27:20
and what they do is they just randomize the interface ID. Essentially, they use the same algorithm as for temporary addresses, the only difference that that address doesn't change over time. So same algorithm, and they use it twice, once for the stable address, once for the temporary address,
27:40
with the only difference being that for the temporary addresses, the addresses are generated over time. Of course, this mitigates the problem of host tracking, because the idea, or partially mitigates the, sorry, it mitigates the problem of host scanning,
28:00
because if you generate the addresses randomly, those addresses will not follow any specific pattern, so you can actually mitigate host scanning attacks this way but as I mentioned before, since these addresses are still stable, they are going to, there is going to be a unique ID value
28:23
that is used over time, so it is still possible to track systems even if they implement this feature. So this mitigates host scanning attacks, but it still makes possible the host tracking attack.
28:44
So this slide tried to summarize the type of interface IDs that we have for auto-configuration. So I've made two categories, stable and temporary, unpredictable and unpredictable. So for example, if you take a look at the addresses
29:02
that include the MAC address in the interface ID, they are of course stable and predictable, predictable in the sense that of course they follow a pattern. If you take a look at temporary or privacy addresses, they are unpredictable because of course they are,
29:23
they are randomized and they are also temporary. But the thing that we are missing is addresses that are stable, addresses that for example you want to use for a server, for example, that again are stable but not predictable. So the idea is that if I have, for example, 100 nodes connected to the network
29:41
and I wanted those nodes to have stable addresses, I still don't want the addresses to follow a pattern and I still want to be able to make the life of an attacker harder when it comes to scanning that network. So this is the scheme that we have proposed.
30:04
It's very straightforward and it has actually been modeled about RFC 1948. Essentially the idea is to produce the interface ID as a result of a hash function over a prefix,
30:20
interface index, network ID and a secret key. Of course the idea is that this function F has to be cryptographically secure. So and of course the security of this mechanism relies on the hash function being secure and also on the secret key being actually secret, right?
30:42
So the idea is that as long as you are connected to the same network or whether you go out of that network but you reconnect to the same network again, all the parameters that you include or you send to the hash function are going to remain the same, right?
31:00
You don't change the secret key, the prefix is going to be the same, the interface index is going to be the same, the network ID is going to be the same, so being the hash function the same thing and being all the parameters the same thing, going to produce the same interface ID all the time. So the idea is I connect to the network, I get one address, I go somewhere else,
31:22
come back to the network, exactly the same address. So the address is stable within that network, within just one network. Now let's say that I move to a different network, at least the prefix is going to change. So if the prefix changes, then the resulting interface ID is going to change.
31:42
So what we get with this function is that we get addresses that are stable within each network, which means that it's something good from an operational point of view. But at the same time, the interface ID changes when I move from one network to another, okay?
32:02
So this is kind of like having the best of both worlds. So in the case of addresses that include the MAC address, the good thing was that the addresses were stable, so they were easy to manage, but they were predictable, so that was a problem. Then on the other hand, you have temporary addresses, which were not predictable,
32:21
but since they were varying over time, they were hard to manage. So what we want here is to have addresses that, again, are stable within each network. So within your network, the addresses are stable, but when you move from one network to another, they change. This proposal was sent to the IETF a few months ago, and it has already been accepted
32:43
by the six-month working group. The only minor comment here is that, from my perspective, some standards should have been formally updated, and for reasons that are not exactly clear, they want to standardize this,
33:01
but without formally updating some of the standards that we have for producing interface ID. So bottom line is that, even when we publish this as an RFC, you could still be compliant even if you were producing predictable interface IDs. But again, I think that even then,
33:22
it's good to have some kind of standardized algorithm for producing interface IDs that don't suffer from the problem I was describing before. Yeah? Well, there are two options for that.
33:42
In the current ID, the ID that I think dates back to a month ago or so, I didn't address that point because it's not even addressed in any other case, right? So it wasn't actually that I didn't want to address that, but I was asking, well, should we address this problem
34:01
in all the documents, or this is something that is kind of like left to implementations? What I'm probably going to do in the next revision of this document is to include a counter here. So the idea is that if you find a collision, you just increase the counter. Now, in that case is that if you want the address to be stable, then you should somehow record the address
34:22
in a stable memory, right? Because let's say that I connect to a network, okay? So there was some system using the same address. So I find a collision, so I need to generate another address. Now let's say I disconnect back, but when I come back, that system is not there. So I will be configuring that system's address.
34:41
So the problem in that case is that you should record the address somewhere, but, well, there's no other way to go, okay? So a couple of comments about fragmentation and reassembly. This is the IPv6 fragment header.
35:02
Essentially, it includes all the fields that you already had in the fixed IPv4 header, but in this case, they are just included in an optional header. So far, we are mostly concerned about only these two fields, fragment offset and identification.
35:22
So first of all, let's start talking a little bit about the fragment identification value. The security implications of predictable fragment IDs have been known for so many years. The implications are denial of service, ADACs, EDIL scans, and so on. And in the case of IPv6,
35:47
I mean, if we were to have a problem with this, the problem could potentially be worse because of two problems. Well, essentially the packets are going to be larger, so it's more likely that we're going to be using fragmentation.
36:00
So we should really get this right, or we were supposed to get this right. Before actually looking at implementations, I found that I didn't find any implementations that had problems with the interface ID because it was so known that probably it was fixed already.
36:21
And actually, we kind of like faced the same problem for different kinds of IDs in the TCP IP protocols, from port numbers to DNS transaction IDs and other values. But the thing is that not in all cases they were using unpredictable values.
36:41
So these are the results that I got while assessing some implementations. For example, there was Windows and Linux and Solaris that had predictable fragment identification values. Of course, the worst options were the ones
37:02
being employed by Windows and Linux because they were using a global counter that was, again, global counter, and it was initialized to zero. So if you could sample just a single fragment identification value, you could tell the fragment identification that those systems were going to use in the future.
37:21
Then you have, for example, in the case of Solaris, they are predictable, but it's not so bad because they use a per-destination counter rather than a global counter. So it's not as bad as the case of Linux or Windows.
37:40
There were different algorithms in use by different implementations, at least the last time they had checked. For example, FreeBSD was using, was randomized, I think it was a linear congruential generator for FreeBSD, I don't recall. But then, for example, we found out that in OpenBSD they were using a more interesting algorithm
38:01
based on the Skip Shack algorithm. Well, we produced tools to actually automatically assess whether an implementation was generating predictable values or not, whether they were using a per-destination counter or a global counter, and so on.
38:21
And the good news with this is that there were a few systems that were patched as a result of this work. For example, I don't recall which is the version of Solaris that fixed this, but they have already patched this one. Well, there is a problem here. I think, yeah, Linux, I think was in November last year,
38:41
they patched their fragment identification algorithm and they are now doing unpredictable fragment identification values. Another problem has to do with overlapping fragments. The problems with overlapping fragments, again, have been known for so many years. There's the Tasek and Yusham paper
39:04
that was published in the late 90s about how you can evade a network interaction detection system by means of overlapping fragments. So the idea here is exactly the same, with the only difference being that in the case of IPv4, there was a legitimate reason for overlapping fragments
39:23
because in IPv4, routers can fragment packets and then packets can be duplicated, follow different paths and so on. So there is in theory a legitimate case for overlapping fragments. In the case of IPv6, there is not a legitimate case for them, but overlapping fragments were still alone
39:43
by the ITF specifications. I think it was last year, a couple of years ago, RFC 5722 was published and essentially they say that the use of overlapping fragments was forbidden. So if you were to receive overlapping fragments,
40:01
you had to just drop the two fragments. The implementations that we checked so far, most of the current ones already implement RFC 5722, most of them. I don't know if, okay, so I didn't include the table here
40:21
but if you look at our blog, there is a big table of all the tests that we did with different implementations to try to assess the fragment reassembly policy that implement. I mean, in the blog, it's not just about whether they allow overlapping fragments or not, but also in the case that they allow overlapping fragments
40:43
whether they use the first copy, the last copy or whatever. So there is a special case of overlapping fragments which has to do with what we ended up calling atomic fragments, which are IPv6 fragments,
41:03
that IPv6 packets that include a fragment header that have a fragment offset of zero but that have the more fragment bits set to zero. Essentially, it's a first fragment without any following fragments, okay? And the reason for which those packets can be generated
41:22
in practice is because of translating devices, at least as far as the ITF specifications go, they say that there are these translation boxes that require packets to have a fragment header if they need to fragment that packet in the IPv4 world.
41:43
So if, for example, you were to receive a packet-to-big message advertising an MTU smaller than 1,280, which is the IPv6 MTU, you are not required to actually fragment but you still need to include a fragment header and that will result into an atomic fragment.
42:01
The problem or the special thing with these atomic fragments is that if you were to receive one of these fragments, you don't need to mix these fragments with real fragments, right? Because the whole thing, the whole packet is included in the same fragment. It's just a first fragment without any other fragments following,
42:21
which is another way to say that the packet is not really fragmented, it just contains a fragment header. So our proposal was obvious. The idea was that if you were to receive a packet that had a fragment offset of zero and the more fragment bits set to zero,
42:42
you had to process that packet without actually mixing it with other fragmented traffic. So this is an assessment that we did for some implementations. Some of them were already implemented
43:00
this improved processing of atomic fragments, even before we actually worked on this. And there were a few other ones that implemented this behavior when we published our internet draft. I think, I don't recall if it was, I think OpenBSD, PATCH?
43:21
This was kind of great. Okay. But it was a little difficult. Yeah, yeah. Okay, but the idea again is that, well, if you were, this is something that shouldn't be hard to implement, and that at the same time can prevent
43:43
fragmentation attacks to be performed against any system. One thing that you should have in mind is that in IPv6, you could actually cost a system to include a fragment header just by sending a packet to BigMessage.
44:01
So at the point in which they start including the fragmentation header, you can start forming or you can start exploiting fragmentation attacks. So I think it's very important to get the atomic fragment thing right and also the fragment identification thing right. The bad news about this is that
44:21
I was lucky enough to have, I don't know if you know a guy called Ivan Arce. He's from Core Secure Technologies, a company that does a lot of vulnerability research. And the guy did a very good review of the document which led to many, many improvements. And then when I published a revision addressing all his comments, I announced that on the relevant IETF list,
44:44
and some guys argue that we have to do nothing about this. So essentially, some people seem to think that we can go wrong with a predictable fragment ID or predictable identifiers in protocols.
45:02
A couple of comments about what is sometimes referred to as IPv6 first hop security. Well, the idea with first hop security is that, well, first hop security are security measures that you can employ in your local network, either in your host, either in your local switch
45:20
or in the first hop router. This concept is not really new from the IPv6 world. It's something that is there already with IPv4. For example, in the IPv4 world, you can monitor ARP with tools such as ARP watch. And there are also things that you can do such as DHCP snooping,
45:42
which means, for example, that you have a switch here and you say, okay, I'm going to run a DHCP server. I'm going to connect the DHCP server on port one. So the other ports shouldn't be able to send DHCP server packets, right? So that kind of functionality, at least in theory, allows you to block attacks based on DHCP server packets.
46:05
The idea is, of course, that we like to have parity of features with IPv4 in IPv6. So this is a problem that you usually find when you try to actually achieve that parity of features.
46:25
The problem is really that in IPv6, for example, all the traffic for other resolution, for example, is done with IPv6 packets rather than link layer packets, as in the case of ARP in the v4 world.
46:44
So for example, an attacker could produce a router advertisement message that includes, for example, a couple of destination options here, and then the actual router advertisement. But before actually sending the packet, the attacker could fragment that packet into two pieces.
47:00
So you end up with these two packets, and it's impossible to actually find out what information is inside the packet unless you reassemble the packet, right? But the idea is that you implement this kind of mitigation at the switch. So you should be really crazy to actually think about fragment reassembly at the switch, right?
47:21
Or if you were to try to do that, then you'd open the door to a bunch of other attacks that you don't really want there. So what are the proposals that we have for bringing some level of sanity to the neighbor discovery traffic?
47:40
So one of the proposal is essentially to forbid the use of fragmentation for neighbor discovery. In practice, you don't really need to fragment packets in neighbor discovery. And for example, if you wanted to include lots of configuration information in a router advertisement, you could just split that information in different packets.
48:03
You don't need to include all that in the same packet. The only legitimate case that there could be for fragmented neighbor discovery traffic is the use of send. Send essentially needs to include certificates in those packets. So if the certificate is large enough,
48:22
you have no other option than to split the packet with fragmentation. But the thing is that if you were lucky enough to get a send deployment right, which probably you don't want to, relying on fragmentation wouldn't be a good idea because you have spent all this effort in deploying send,
48:42
and then an attacker could just disable send by sending fragmented traffic. So if, for example, you are going to send the certificates in multiple fragments, and I was an attacker connected to your network, I could just send fragments that collide with your ARM fragments, and I could D-O-S send. So there is, I don't think it's a good idea at all
49:02
to actually use fragmentation even for send. Yeah. Yeah, exactly, yeah. Actually, I seem to recall, but I don't recall the actual implementation, but I think to recall playing with some implementation
49:20
that already do that. A point not because, I don't know whether they meant to do that, but that's the way they work in practice. So for example, with tools, I was sending a router advertisement, but fragmented into two pieces, and they were ignoring the packet. So that's a good thing to do. And at the point in which you actually forbid
49:41
the use of fragmentation, possible to actually monitor the neighbor discovery traffic or anything because you have all the information in a single packet. So you don't need to do like a stateful inspection. So we send a proposal to the IETF.
50:01
Apparently there was support for it, but they didn't want to talk about adoption of this document at the last IETF in Paris. And the six-month working group is supposed to be pulled about this in the short term. Another mechanism that we have in IPv6 is what is called router advertisement guard.
50:23
Essentially, it's kind of like the same thing that we have in IPv4 for the HCP. The HCP is snooping. But in this case, what we want is to filter router advertisement messages based, for example, on the port on which they are received. The problem with router advertisement guard is essentially the same
50:41
or very similar to the one that we discussed before. For example, if I was an attacker, I could send my packets in this way. Let's say include different extension headers and then fragment them. And since router advertisement guard is a stateless mechanism, kind of like hard to actually figure out
51:02
whether packets should be passed or not. One of the problems with this is that the IETF published two RFCs about router advertisement guard. I think they were, well, the router advertisement guard was proposed by a big router vendor. And that big router vendor's implementation
51:21
was trivial to circumvent. And not just that, but when we came up with a problem, and when we actually reported the problem, the answer was that, well, we don't need to fix that because the solution to this problem is to use send. Well, if you could deploy it, right? So after quite a bit of effort,
51:42
we ended up getting our IDE accepted by one of the IETF working groups v6 operations. And that document has just passed the working group last call. The idea is that we specified a set of rules to filter router advertisement packets
52:03
trying to minimize the potential for false positives. And just finishing this presentation, couple of comments about IPv6 firewalling. I mean, there's a lot of work to do
52:21
with IPv6 firewalling. This is just like a single bit of it. This is very related with what I discussed before. In IPv6, the IPv6 header chain can span across multiple fragments, right? So that's not something that could happen in IPv4. In IPv4, you could have fragments,
52:41
but you will always have at least the transport header, for example. In the case of v6, you could have a situation such as this in which you receive this packet and you cannot really tell what's inside that packet. The same thing with the second one. So that essentially means that if you wanted to implement stateless filtering,
53:00
in practice, you cannot. So the only way in which you could actually do firewalling in v6, if you know everything that the specifications allow, is to do stateful filtering. So what we propose here is to actually forbid this case and actually require all packets to have the entire IPv6 header chain in the first fragment.
53:22
So if you fragment packets, you better include all the header chain in the first fragment, okay? Our proposal was originally to require the whole header chain to be included within the 1280 bytes, which means the IPv6 MTU, but then some guys are against that and say that, well, probably a better number
53:41
would be to use the path MTU. In practice, I've never seen a packet in the real world that has 1,000-something extension headers, right? And if you were to have such a packet, then you have more headers than payloads, so you don't really want that case. But in any case, there was people arguing against this.
54:02
So this is something that was presented at the last ITS meeting, and the six-month working group is supposed to be pulled about adoption of this document. Yeah? An internet draft, yeah, a proposal,
54:22
but it has not been published as an RFC yet. And last one has to do with amplification ADACs. You may have read that, or you may, yeah, you may have read that in IPv6, you cannot have small-like ADACs because, for example, hosts are required to ignore, for example, ping packets sent to multicast addresses,
54:41
but there are cases, there are some specific packets that can generate responses even when sent to multicast addresses. One of the cases is to send packets with unrecognized options of type 10 and then whatever. So our proposal in this case is essentially to ignore those packets
55:01
and not to react by sending error messages. I mean, when it comes to an amplification ADAC, you don't care what's the response that you get, but as long as you get responses to something that you sent to a multicast address, you get amplification. So that's a proposal that we send to. So conclusions.
55:21
Many vulnerabilities that have been found in IPv4 have been reimplemented in IPv6. In some cases, in the specifications, in some cases in implementations, there are possible reasons for which that may have happened. One is that we didn't learn the lesson from the v4 world.
55:42
Another possible reason is that different people was working on one stack and on the other. In some cases, the specifications don't really make it straightforward to implement the protocols, so I think that there is room for improvement there, and there may be a mix of all these reasons involved.
56:00
Conclusion of this presentation is that there is still a lot of work to do when it comes to IPv6 security, and since we need to deploy v6 on the internet, we need to work to improve it. So I don't know if there's any question.
56:21
So there's my email address, and we have an email list for discussing these v6 security things. Thank you.