Week 1 :: 06/02/2015
|
If you are a DREU participant and you are matched with a Professor at University of Florida, it is a good idea to learn the bus system. The campus is HUGE. The Computer Science building is pretty close to where I am staying.
First week of internship was nice. I got my own desk and computer. A lot of exciting work has been done with CISE and I’m looking forward to starting my work. It looks tough, but I’m sure I’ll catch on. I have some reading material and will be looking on the internet to become familiar with some of the terms they have been using. Wrote my first Kernel Module (really simple Hello World). I'll now read up on writing in SHELL/bash and also learn more about SEND (security for IPv6 Neighbor Discovery). 
My desk in the new building. Of course the setup is temporary because when I leave another grad student is coming back from California and he might have this desk.
|
Week 2 :: 06/09/2015
|
Next task was to find the differences between ARP and Neighbor Discovery. Spent the whole week doing research and writing up a report due Monday.
*I didn't see much of my mentor this week because there were deadlines for publications to be met. 
| ||
Week 3 :: 06/16/2015
|
Not much has really changed for me, even though it is the third week I've been here. Still reading and not much hands on experience. After completing my task of finding the differences between ARP and Neighbor Discovery, I was given a new objective. This time I was to read a portion of RFC 2461 : Neighbor Discovery for IP Version 6 (IPv6) and map it to the kernel code to find out where we should inject the security measures. Reading the RFC is not so difficult, but it was easier for me to just look through the code (1812 lines) and find where neighbor/router solicitations and advertisements were being sent and received. I have located where they are in the code and will be speaking with Professor Butler on Monday for the next step.
learn more about RFC 2461 here check out the neighbor discovery kernel code here |
Week 4 :: 06/23/2015
|
Dave (grad student) went through the ARPsec code and showed me where the modifications were. The plan is to do the same in ND code. We found a good spot to modify. I need to do a little more research before I feel comfortable modifying code on my own. Even though it seems like a simple transfer of code from one protocol to another, I just don't want to mess anything up.
Wrote a short paper on SeND's added features and some of its issues.
| ||
Week 5 :: 06/30/2015
|
During this week I worked on learning C. "Learn C The Hard Way" was my guide. Before starting, it was advised that the learner have some experience in programming. I do have experience in C++ and Java, but it has been a while since I programmed. I decided to take the advise and learn a new language; Python. ("Learn Python The Hard Way"). I'm glad I did. It was exciting and fun learning a new programming language and I think I like Python more than any other language I've learned. At the end of the lessons we are to create a game and publish it online, I chose not to do that because that would take away from the short time I have to learn C. I'll do the gaming at a later time.
I started working on C and don't find it all that difficult. My main focus was to learn about structs and functions. I haven't completed learning C, but I was able to go into the source code of neighbor discovery and add in a struct to get the MAC address, IP address of source, IP address of destination, and opcode (whether it is a solicitation or advertisement). I have a lot of trial and error to go through. I'm trying to figure out what variables to use in my struct so that they match what is already in the code. It doesn't seem that hard, but there is A LOT of code to go through with A LOT of variables, functions and pointers. Hopefully by next week I can have everything ready to build a stable kernel. |
Week 6 :: 07/07/2015
|
Kernel was compiled and stable with the edited ndisc.c source code. I am currently working in a kernel that has my own edited and added features! After all the trial and error and major frustrations, I can proudly say I have accomplished a huge task. Next I have to go through the arpsec daemon and added IPv6 functionality without "breaking" the IPv4 settings. This task seems to be much more difficult, though Dave says it's easier than what I just went through. I'm not so sure, because in the daemon there is socket programming. I've not even heard of that until I got here. So, it looks like that's another language I need to learn in order to be successful at this new task. Also, I need to prepare for a presentation that is supposed to be happening later this month. I'm not so good with public speaking, but I think I should be okay with talking about what I have learned and accomplished.
|
Week 7 :: 07/14/2015
|
Instead of working on the ARPsec daemon, I was able to shift my focus on security performance measures. In this task I would be testing the existing security measure SeND. I'm able to do this using NDprotector. I had this program installed and running on both of my machines. I had to create a local network and use ping6 to insure they were both communicating through IPv6. After doing this and installing NDprotector, I then created RSA key pairs for both machines and saved those; also configuring the host file to include the key paths. Both machines needed to have access to each other's public key. Example: Machine A has Machine B's public key stored somewhere and that path is added into the host configuration file. Along with Machine A's public key.
This is a successful ping between my two machines in their local network.
The first ping (first 64 bytes sent) is the longest because neither machine knows about each other. So Machine A must send out a multicast message to get information about Machine B. Once Machine B responds with the information needed (including the MAC address), Machine A will save it and then they can communicate freely.
Overall, everything has been successful. The one issue is that we find that (using Wireshark in a closed network setting) the messages being passed between Machine A and B are just normal NDP messages and not what we are looking for, which is SeND. Dave thinks we might have to do some kernel hacking or maybe some debugging because the SeND messages should be passing between the machines.
I've continued working on my presentation and timing myself. I'm pretty nervous to be giving this presentation, but I think I'll do fine. Tomorrow we should work on debugging. |
Week 8 :: 07/21/2015
|
My main focus this week has been on completing my presentation and my script. My presentation was on Monday and I believe it went well, the audience seemed interested in what I was discussing. My presentation covered ARP, ARPsec (security protocol created by Professor Butler and Dave), and NDP. I will include the powerpoint.
I did a little debugging here and there, but it was mainly so I would have a little bit more to talk about in my presentation. It seems like NDprotector is a little bit more buggy than we thought. We'll be working on it in the upcoming weeks.
| ||
Week 9 :: 07/28/2015
|
The debugging of NDprotector was a success. Incoming and outgoing packets are marked secure (as long as the RSA signature is correct) and incoming information is being stored for future reference.
Now that the debugging process is complete, the next step is to move into performance evaluation. In doing that we have to benchmark each component. I'm starting with NDprotector since it has a built in benchmark. I'm not sure how much time I'll have to look at the arpsec daemon, since benchmarking seems very lengthy. |
Week 10 :: 08/04/2015
|
My last week is coming to a close! It's been an awesome experience. I've learned so much more than I would have at my own home institution. This has given me a chance to experience real life scenarios and even graduate student life.
For my last week I've just been continuing the performance evaluations. These evaluations are being done on the ARPsec machines. 
ARPsec machines with TPM
I've run through ping6 for regular Neighbor Discovery and also with NDprotector. The process is to use ping command when no mac address is known and gather the information, then when the mac address is stored, we run ping again and gather that information. I noticed that with NDprotector running and mac address is known, a neighbor solicitation message is sent out periodically. We believe NDprotector might have an internal timer that clears the cache, but it's clearing too fast. The next step is to run regular Neighbor Discovery and NDprotector with a program that clears the cache after each ping and then gather those numbers. After that has been completed, we move into ARPsec and evaluate for IPv6. I've done so much this summer and I'm honored to have had such an amazing experience here at the University of Florida. I will definitely remember everything I've done. Thank you, DREU for giving me this opportunity!
| ||