Aerospace Village - Deep Space Networking
Chappell, Laura
The Deep Space Networking workshop in the Aerospace Village at DEFCON Safe Mode will challenge your ability to investigate and find important data within complicated technological communications. Trace file provided by Vint Cerf from the original test lab for Delay and Disruption Tolerant Networking. (DTN)!! Presented by Laura Chappell, Chappell University.
 Hi, this is Laura Chappell and welcome to this video on Deep Space Networking Traffic Analysis. In this video I'm going to show you how I open up a trace file inside of Wireshark and begin the process of customizing Wireshark for Deep Space Networking Traffic Analysis. And we'll go through and learn about the bundle protocol and we'll learn about the TCP convergence layer. So let's go over to Wireshark and get started. In Wireshark I've opened up the trace file depicting the Deep Space Networking Traffic. Now we're talking about delay and disruption tolerant networking here or DTN we simply refer to it as. And in this scenario we have a host that is sending a bundle of data in bundle segments to another host to be relayed to a third host. So let's see what we have in this trace file. First of all we have some traffic that doesn't have anything to do with our DTN communications. It's this OSPF traffic. So I'm going to get that out of the way. Now what we're left with are some interesting packets here. First of all these top packets that you see, they're UDP packets, they're kind of sprinkled throughout the trace file. If you were to select one of those packets and look down in the packet bytes window what you would see is in the data portion it appears that we have a host that is announcing its DTN endpoint ID. So 10.0.0.1 is announcing that its endpoint ID is N1. Kind of like its name. On the second packet there we have 10.0.0.2 announcing its endpoint ID as N2 and the next packet 10.0.0.3 announcing its endpoint ID as N3. Alright that information right there is very interesting but it's not a data transfer process. That is just an announcement. What we're interested in are the TCP CL packets. So frame number 7 there is the first time we see a TCP convergence layer packet and this is just a keep alive. By looking at these keep lives we can get a general idea of which hosts can see which hosts. So in frame number 7 we have 10.0.0.3 sending a keep live to.4. The next packet we have.1 sending a keep live to 3. In packet 9 we have 3 sending a keep live to 1 and then in a little bit further on we see in packet 19 we have.2 sending a keep live to 4. Alright we can build a picture from this. This is what we know so far. It appears that we have 4 hosts and based on the keep lives we can see which hosts are talking to which hosts. So we can see based on the keep live that.1 can see.02,.2 can see 4, 4 can see 3, 3 can see 1 but we don't see any keep lives going between.1 and.4. We don't see any keep lives between.2 and.3. So perhaps we have something in the way between those two hosts. It could be something like a planet. So here I have a picture, one of the various pictures of Venus with a color filter on it. Now let's go back to the trace file. So let's take a look at when data actually begins to be sent here. We see an awful lot of those endpoint ID announcements and we see a bunch of keep lives and we see some acknowledgments for those keep lives. When we get down to frame number 57 that's the first time we see a larger length frame that probably has some data in it. So let's create a profile in Wireshark and we'll begin the customization process to help us analyze deep space networking traffic. So in the bottom right hand corner on the status bar in Wireshark it says Profile Default. I'm going to right mouse click on that column there on the bottom and say New and I'm going to name this profile DTN Example and I'll say OK. Now Wireshark takes me back to the default settings for profiles and this font is way too small. There's no way I'll be able to see that. So I'm going to zoom in here using the enlarge button on the main toolbar until I get to a font size that I like. Now with all of my profiles I always add one special column. I like to have it up with all the work that I do analyzing traffic. And that column is one that will tell me the conversation numbers in the trace file. Wireshark numbers all the UDP conversations and it numbers all the TCP conversations, it starts numbering each of them at zero and they are exclusive of each other. I'm going to go into the very first packet in here and inside the UDP header there is a field called the Stream Index field. And I want to add this as a column. To add a field as a column you simply right mouse click on that field and say Apply as column. I'm going to right mouse click on that column heading and choose to Align Center for the contents of that column. Now we've started creating this great column but we're not quite finished yet because our TCP traffic is not showing up with a Stream Index number. We've only told Wireshark to add a Stream Index column for UDP. So I'm going to right mouse click on that column header and I'm going to choose to Edit the column. And I can see right here that the field that it's based on is UDP.stream. I'm going to add on to this to say or TCP.stream. It doesn't matter if you do TCP.stream or UDP.stream or this direction, it doesn't matter either way that will work and I'm going to say OK. There we go. Now as conversations are intertwined it's easier for me to see which conversation I'm currently working in because I have the conversation number on the left hand side. So the next thing I want to do is I want to pull out the most active conversations in this trace file. I'm going to go up to Statistics and Conversations and I'm interested in the most active conversations based on the TCP layer. I'm going to sort based on the byte count from high to low and there I can see I have two conversations of interest here. These top two are what I want to look at. That's data flowing. So I'm going to right mouse click on the very first line here which is traffic between.3 and.1. I'm going to right mouse click and prepare a filter based on the selected value going in both ways. Then I'm going to go to the second line and I'm going to right mouse click, prepare a filter and this time I'm going to say or selected going in both directions. Mark Shark builds the filter for me in the background and I can see exactly what this filter is based on, the IP addresses that it's based on. I'll go ahead and I'll just apply that filter now. So I have two conversations, the top two conversations showing in this trace file. I'm going to go to File and I'm going to save this as a separate trace file now. These two conversations. I'll go to File, Export Specified Packets and I'm going to call this DTN Example. Now I'm going to open up that trace file called DTN Example because by default Mark Shark only saves the filtered packets. So here we go. Now we have some keep alive segments. Let's take a look down in the packet details window. Here we can see we have an Ethernet header, an IP header, a TCP header and then after the TCP header we have the DTN TCP Convergence Layer Protocol or TCP CL. It has its own header and for keep alive all we have is this single little field here saying that it is a keep alive. I want my keep alive to kind of melt into the background here. So I'm going to set up a coloring rule to change the way these show up in the packet list pane so they kind of melt away. I also don't need my capture filter anymore. So in the detail window I'm going to right mouse click on this keep alive packet and I'm going to colorize this with a filter and create a new coloring rule. There's the syntax put in there for this coloring rule and I'm just going to call it TCP CL, keep alive. On the bottom of this coloring rules window I'm going to click the background button and I'm going to change the background color to sort of a kind of a washed out grayish color let's say. I'll click OK and OK. Now those keep alive have their own background color of this gray showing up. The next thing I want to do is I want to look for anywhere where it says bundle protocol and I should expand the protocol column so you can see what's marked as TCP CL. Frame number 14 shows up and in the info column it says bundle TCP CL segment, TCP segment of a reassembled protocol data unit. Wireshark's TCP reassembly function is on and we'll talk about how that affects the view in just a little bit. But if we look inside of frame 14, I'm going to move this up, what we can see is we can see that we have the TCP header and then right after that Wireshark is telling us that three different segments have been reassembled to create this bundle segment. Let's stop for a moment and let me show you how bundles relate to bundle segments which relates to TCP segments. So the bundle protocol is essentially an application and you would have some other application that uses it. So let's say you wanted to do FTP across the galaxy, you could do that. You would type in your FTP commands but that command would go through the bundle protocol to transfer data. So we would have a bundle here of data and bundles need to be transferred around. It could be scientific information, it could be video, it could be pictures of the surface of a planet or something like that. It doesn't matter. We have this big bundle of data and the bundle protocol is a store and forward protocol. Again, it's covered in RFC 5050 if you want to go look up some information about this. But when a bundle of data is going to a target system, it can be split up into bundle segments and that is what we see in this trace file. In this trace file, the bundle that is being transferred from the first host to the relay has split the bundle up into four different segments. When we look at it on the cabling system, it's really strange because we're so used to an application sending down a certain amount of data and then the TCP segments go all the way to the end of the data and stop. That's not the way it's done with the bundle protocol. A TCP segment may have some data from bundle segment A and it may have some data from bundle segment B inside of it. You can see that if this first bundle segment is going across the network, it's got a TCP segment, another TCP segment, and then part of the third TCP segment is part of segment A. Then bundle segment B goes out, but part of bundle segment B is sitting in the third TCP segment here. Then we have a TCP segment devoted to bundle segment B, another one, and then we only needed part of another TCP segment. But why stop the TCP segment and create a new one? Nope. We will have bundle segment C and it starts in the middle of a TCP segment. Literally, you will see a header inside of this segment right here indicating that this new bundle is coming up. Same thing with the final bundle segment. There will be a header right at the beginning of this bundle segment saying that this is the start of a new set. So let's go take a look at these bundle segments as they show up delivered by TCP segments. So in the Info column we see on frame number 14 it says bundle TPCL segment. When we click on it, we have an indication here of which packets were required to put together this first bundle segment. Frame number 11, frame 13, and frame 14. And the numbers in parentheses are how much data fits into this bundle segment. Now we can also see below this. This is the TCP convergence header and unlike the TCP CL keep alive, there are more fields. There are a total of four fields in this TCP convergence header. So we have the packet type field. So this is data. Then we have this is indented. So don't get stuck on this. These are not new fields. This is the summary line for these two below. There is one bit that would indicate if this is the start of the entire bundle. And there's another bit that indicates if this would be the last packet of the entire bundle. And then we have a line that tells us what that, how, I should say how large that TCP bundle segment is. That is a bundle segment length. So let's do some customization of Wireshark based on these fields. Number one, I want to take the packet type field and I'm going to right mouse click on this and apply this as a column. There we go. It's easy now to see the difference between keep lives there and where data packets are. And then I also want to do the same thing for segment contains start of bundle. I'm going to right mouse click here. And this is the start of bundle packet. So I'm going to apply this as a column and we can see that it's true. I'm going to center align that. And then this next field segment contains end of bundle. I'm going to add that as a column as well. And I'll center align that. Now it's pretty easy to look through the trace file and see which packets are the start of the bundle. And then farther on we'll be able to see which packets are the end of the bundle. That's the end of the entire bundle. Not the bundle set or bundle segment but the bundle itself. To make it even easier to detect these, I'm going to set up two coloring rules. I'm going to set up one coloring rule that turns all packets that are the start of the bundle a green color and then the end of the bundle red. So in frame number 14 I'm going to right mouse click on this line that says segment contains start of bundle. And I'm going to choose colorize with filter, new coloring rule. And it's already set to a one because this is the start. So I'm going to just name this start of bundle. And then for the background I'm going to choose sort of a lime greenish. Now by setting that coloring up it's very easy for me to detect where the start of the bundles are in the trace file. Three of the packets should have matched that. Here's another thing we can do. We can right mouse click on that field and just simply prepare a filter based on the selected value. That just puts that filter to detect the start of bundle packets up in my display filter area. And on the far right hand side of the display filter area there's a little plus there. I'm going to click that plus and I'm going to turn this into a button. I'm going to give the button a label which is going to be S-bundle. That to me means start of bundle. I'll say OK. Now I have a button when I click on it any packets that have the start of bundle bit set to a 1 will show up. Let me clear out the filter that the button just applied. I want to do the same thing with the end of bundle. I want to give it a color. I'm going to give it a vibrant red. And then I'll make a button so I can easily detect the end of bundle and just show those packets. Now this packet has the end of bundle bit set to a 0. I'm going to change that to a 1 when I do my coloring rule. I'm going to change that to a 1 when I do my display filter button. So I'm going to right mouse click on this packet, colorize with a filter, new coloring rule, name it end of bundle. And I'm going to give it a background color of this vibrant red. I'll say OK. OK. So now it's very easy. Oh, I forgot to change the number. Well, it's good for you to see how to edit coloring rules. To edit a coloring rule we go to view, coloring rules. And I wanted to change this to a 1 at the end. There we go. All right. So now we can see there's the start of a bundle. There's the end of a bundle. There's a start of a bundle. And there's the end of a bundle right here. The first start of bundle we see going from 10.0.0.1 to 10.0.0.3. So the first thing we see in here is we see a bundle being transferred from dot 1 to dot 3 in bundle segments. So that bundle is done right there, then down on frame 37 we see another bundle starting. And this bundle is from dot 3 to dot 4. This is the first bundle being forwarded on by dot 3. So it's being relayed on. And then we see the end of that bundle after it's been relayed. And the very last packet that we see here from 3 going back to 1, it's a little strange. It's its own bundle. We can see that the start of bundle is set at true and the end of bundle is set at true. First of all I want to pop up a button up here for end of bundle. Well I'll use this packet since it has the end of bundle bit set on. I'm going to go inside the TCP convergence layer here, right mouse click. Just going to prepare it as a filter based on the selected value. There it is. That's what I want to build the button on. So I'm going to click plus and give it a name. E bundle. That means end of bundle to me. So now if I want to see the end of bundle packets only, I can click on the second button. I want to see the start. I can click on the first button. I'm going to go ahead and clear this out. Now you'll notice that after this bundle has been relayed from 3 to 4, there's this package, this strange packet here, where it has the start and end of bundle bits set on. That means it's its own little bundle. And this is actually a reporting packet. So let's go inside of it and take a look. Let me bring up this. Let's see. I'm going to bring this sort of up so we see it up on top. And it is frame 49 we're interested in. And when we look inside of frame number 49, we see the TCP convergence layer indicating it's the start of a bundle and the end of a bundle also. So we're obviously not transferring a bunch of data here. And then we'll see the primary bundle header. And if we look a little bit further in here, we will see a payload header. And beyond this, we have the administrative record. So this is indicating right here that this is a bundle status report. That's the purpose of this packet. I don't want this packet to be colored red just because it hit the end of bundle coloring. I want this packet to have its own coloring. So I'm going to right mouse click on the line that says administrative record type bundle status report. And I'm going to choose to colorize this with a filter, make a new coloring rule. There's that line, admin record type 1. And I'm just going to say that this is the admin report. I'm going to turn the background yellow for this one, say OK. And now there we go. This is the admin report. And that admin report is being sent from dot 3 to dot 1 to say that I successfully delivered the bundle on for you. So now let's go up and just take a look at some of the packets in here and how this works. In frame number 14, Wireshark says this is a bundle segment. And sure enough, if we look inside, we can see the data packets that were required to make up this bundle segment. Packet 11, packet 13, packet 14. And we can see the amount of data in each of those segments to make up in each of those TCP segments to make up this bundle segment. And then when we look down at frame number 18, again on the right-hand side, it says bundle, TCP CL segment. And if we look inside of that frame, we can see which TCP segments were required to make up this bundle segment. And there's the weird one right there. So some of the data that's in packet number 14 is part of bundle segment A, whereas some of the data in packet 14 is part of bundle segment B, the second bundle segment. That's very interesting. It's a bit of a different protocol. And if we keep looking down here, and frame number 26, frame number 26 is listed here as bundle, TCP CL segment. And if we look inside of there, we can see, oh, let's see, 14. I think I did that one before. Let's clear that out, and let's go beyond that to the next bundle segment. Oh, maybe I didn't. I don't remember. So I'm clicking on frame number 26, and in frame 26, oh, it just hadn't clicked. I didn't click on frame 26 before. It was still selecting frame number 18. So now I'm on frame number 26 that says some of its data is in frame number 18. Some of it is in 23, 24, and 26. And then the last bundle segment is actually the one that finishes up the whole bundle. So frame number 32, we can see its data. And if we look down here, we can see exactly which frames were required, which TCP segments were required to get this bundle segment across. It is pretty, it can be pretty confusing to look at this because we have bundle segments and then we have TCP segments, and they don't necessarily align. Along the way here, we had some acts showing up. So here we have the first bundle segment up here, and then we have an act down here on frame number 20. This frame number 20 act that we see, it is acknowledging receipt of this bundle segment. This act down here on frame 27 is going to be acknowledging this bundle segment. The act counts up. So if I look at frame 20, I see an acknowledgement saying act length 4096. That was how much data was in the first bundle segment. I go to the next act and it says now I'm acting up to 8192 bytes because it's now acknowledging the second bundle segment. We'll see the next act coming up right here. This act is acknowledging the third bundle segment. So this guy is acknowledging this bundle segment, which of course includes those packets. And we can see that it's counted up to 12,288. And then we have the last act here, which is counting up also the very last bundle segment. It can be sort of confusing to see what's happening when, especially when we have wire sharks reassembly feature built into it. But what I did is I made a little TCP spreadsheet that goes through what's happening here. We have bundle segment A, bundle segment B, bundle segment C, bundle segment D there. And these are the frames required and the amount of data in each of those frames. When we add the data up in the bundle segment, we subtract 3 for the TCP convergence layer overhead and that leaves us with the actual segment of data, the amount of data in there. Same thing here on the second one. It required four packets to get this across, subtract the TCP CL overhead and we're at 4096 here, another 4096 bundle segment, and then the last one isn't quite as long. So I'll bring that back in in a moment when we talk about the bundle header itself. So all of that was the bundle being transferred from 10.0.0.1 to 10.0.0.3 and then all of a sudden we see 10.0.0.3 transferring this data over to 10.0.0.4. And the same thing, we have data, data, data, data, interestingly enough, we have some acts that show up later but for something else. So when we look at this, let's reassemble what is being transferred across this network as this bundle is being relayed. We can go into any one of the Stream 1 packets and just right mouse click on the frame in the packet list pane and select follow TCP stream. This is the data that is being transferred by this bundle. At the top of this bundle, you have these at signs and those are Keepalives. So when you click on those, you can see you can click and that wire shark will take you to the Keepalive packets in the background. What is following that immediately, the next three bytes is actually the TCP convergence layer for the very first bundle. After that we have a bundle header and after that, this is all the bundle header, and then after that we have the payload header. So when we look at our segments going across, we have a bundle header that is applied only on the first bundle segment. Every single one of these bundle segments though starts with a TCP convergence layer header. That's how we know it's the beginning of a bundle segment. The very first bundle will be followed by a bundle header and then it will be followed by a payload header. So these are the header structures that you would see in something like this. We need to have that TCP CL header in there because that provides us with the interface between TCP and the bundle protocol, it's kind of the shim between the two of them. In this slide I'm showing you the amount of data that is carried in each one of these TCP segments and when we add those up, these are the payload values. When you look at the acts, we just count up from 4096, then we count up from there until we get to our final value. Let me just finish up by taking you into the bundle header for a moment. We're going to go all the way down here to let's pull frame number 32. This is the last frame of the bundle after it has been forwarded to, oh wait, nope, that's not the one I want. I want to go up to the first, hang on, I've got a filter on there, no wonder. So let's go to, it doesn't matter which one of the red packets we go to, they'll basically have this very similar information in them. I'm going to go to this frame 46, let's say, that is the final packet of the bundle after it's been forwarded to 10.0.0.4. And let's go into the bundle header and let me bring the bundle header up in that top window, there we go. There are some strange things about the bundle header here. For example, one of the big things that catches people is that this bundle header length field does not include the whole entire bundle header, it includes only the fields that follow the bundle header length field. So the bundle header is actually 49 bytes. And then the payload header is another 4 bytes. So this packet is telling me the last packet of each of the bundle segments. And then I can see down here, this is the amount of payload. Now this is different than the final AC. So if I come up here, and let me just show you what I'm talking about here, this AC right here that we saw, this AC says that the amount of payload is 15,272 bytes. Sure enough, that's what it is if we add up all of the payload from each of the bundle segments. But when we look inside of a bundle header to see how much payload it thinks has crossed the network. It's giving us a different value. It's giving us 15,219. And the way it gets there is we have to subtract out the 49 bytes of the bundle header plus the 4 bytes of the payload header. We got to get rid of 53 bytes from the extra payload headers and bundle header at the front. So that's how we get to that particular number. So I've shown you how we can add columns. I've shown you how we can add buttons into Wireshark. And I've shown you how we can add coloring rules into Wireshark to make analyzing the bundle protocol and the TCP convergence layer protocol a little bit easier.
 Hi, this is Laura Chappell and welcome to this video on Deep Space Networking Traffic  Analysis.  In this video I'm going to show you how I open up a trace file inside of Wireshark  and begin the process of customizing Wireshark for Deep Space Networking Traffic Analysis.  And we'll go through and learn about the bundle protocol and we'll learn about the  TCP convergence layer.  So let's go over to Wireshark and get started.  In Wireshark I've opened up the trace file depicting the Deep Space Networking Traffic.  Now we're talking about delay and disruption tolerant networking here or DTN we simply refer  to it as.  And in this scenario we have a host that is sending a bundle of data in bundle segments  to another host to be relayed to a third host.  So let's see what we have in this trace file.  First of all we have some traffic that doesn't have anything to do with our DTN communications.  It's this OSPF traffic.  So I'm going to get that out of the way.  Now what we're left with are some interesting packets here.  First of all these top packets that you see, they're UDP packets, they're kind of sprinkled  throughout the trace file.  If you were to select one of those packets and look down in the packet bytes window what  you would see is in the data portion it appears that we have a host that is announcing its  DTN endpoint ID.  So 10.0.0.1 is announcing that its endpoint ID is N1.  Kind of like its name.  On the second packet there we have 10.0.0.2 announcing its endpoint ID as N2 and the next  packet 10.0.0.3 announcing its endpoint ID as N3.  Alright that information right there is very interesting but it's not a data transfer process.  That is just an announcement.  What we're interested in are the TCP CL packets.  So frame number 7 there is the first time we see a TCP convergence layer packet and  this is just a keep alive.  By looking at these keep lives we can get a general idea of which hosts can see which  hosts.  So in frame number 7 we have 10.0.0.3 sending a keep live to.4.  The next packet we have.1 sending a keep live to 3.  In packet 9 we have 3 sending a keep live to 1 and then in a little bit further on we  see in packet 19 we have.2 sending a keep live to 4.  Alright we can build a picture from this.  This is what we know so far.  It appears that we have 4 hosts and based on the keep lives we can see which hosts are  talking to which hosts.  So we can see based on the keep live that.1 can see.02,.2 can see 4, 4 can see 3, 3  can see 1 but we don't see any keep lives going between.1 and.4.  We don't see any keep lives between.2 and.3.  So perhaps we have something in the way between those two hosts.  It could be something like a planet.  So here I have a picture, one of the various pictures of Venus with a color filter on it.  Now let's go back to the trace file.  So let's take a look at when data actually begins to be sent here.  We see an awful lot of those endpoint ID announcements and we see a bunch of keep lives and we see  some acknowledgments for those keep lives.  When we get down to frame number 57 that's the first time we see a larger length frame  that probably has some data in it.  So let's create a profile in Wireshark and we'll begin the customization process to  help us analyze deep space networking traffic.  So in the bottom right hand corner on the status bar in Wireshark it says Profile Default.  I'm going to right mouse click on that column there on the bottom and say New and I'm going  to name this profile DTN Example and I'll say OK.  Now Wireshark takes me back to the default settings for profiles and this font is way  too small.  There's no way I'll be able to see that.  So I'm going to zoom in here using the enlarge button on the main toolbar until I get to  a font size that I like.  Now with all of my profiles I always add one special column.  I like to have it up with all the work that I do analyzing traffic.  And that column is one that will tell me the conversation numbers in the trace file.  Wireshark numbers all the UDP conversations and it numbers all the TCP conversations,  it starts numbering each of them at zero and they are exclusive of each other.  I'm going to go into the very first packet in here and inside the UDP header there is  a field called the Stream Index field.  And I want to add this as a column.  To add a field as a column you simply right mouse click on that field and say Apply as  column.  I'm going to right mouse click on that column heading and choose to Align Center for the  contents of that column.  Now we've started creating this great column but we're not quite finished yet because our  TCP traffic is not showing up with a Stream Index number.  We've only told Wireshark to add a Stream Index column for UDP.  So I'm going to right mouse click on that column header and I'm going to choose to Edit  the column.  And I can see right here that the field that it's based on is UDP.stream.  I'm going to add on to this to say or TCP.stream.  It doesn't matter if you do TCP.stream or UDP.stream or this direction, it doesn't matter either  way that will work and I'm going to say OK.  There we go.  Now as conversations are intertwined it's easier for me to see which conversation I'm  currently working in because I have the conversation number on the left hand side.  So the next thing I want to do is I want to pull out the most active conversations in  this trace file.  I'm going to go up to Statistics and Conversations and I'm interested in the most active conversations  based on the TCP layer.  I'm going to sort based on the byte count from high to low and there I can see I have  two conversations of interest here.  These top two are what I want to look at.  That's data flowing.  So I'm going to right mouse click on the very first line here which is traffic between .3 and.1.  I'm going to right mouse click and prepare a filter based on the selected value going  in both ways.  Then I'm going to go to the second line and I'm going to right mouse click, prepare a  filter and this time I'm going to say or selected going in both directions.  Mark Shark builds the filter for me in the background and I can see exactly what this  filter is based on, the IP addresses that it's based on.  I'll go ahead and I'll just apply that filter now.  So I have two conversations, the top two conversations showing in this trace file.  I'm going to go to File and I'm going to save this as a separate trace file now.  These two conversations.  I'll go to File, Export Specified Packets and I'm going to call this DTN Example.  Now I'm going to open up that trace file called DTN Example because by default Mark  Shark only saves the filtered packets.  So here we go.  Now we have some keep alive segments.  Let's take a look down in the packet details window.  Here we can see we have an Ethernet header, an IP header, a TCP header and then after the  TCP header we have the DTN TCP Convergence Layer Protocol or TCP CL.  It has its own header and for keep alive all we have is this single little field here saying  that it is a keep alive.  I want my keep alive to kind of melt into the background here.  So I'm going to set up a coloring rule to change the way these show up in the packet  list pane so they kind of melt away.  I also don't need my capture filter anymore.  So in the detail window I'm going to right mouse click on this keep alive packet and  I'm going to colorize this with a filter and create a new coloring rule.  There's the syntax put in there for this coloring rule and I'm just going to call it  TCP CL, keep alive.  On the bottom of this coloring rules window I'm going to click the background button and  I'm going to change the background color to sort of a kind of a washed out grayish color  let's say.  I'll click OK and OK.  Now those keep alive have their own background color of this gray showing up.  The next thing I want to do is I want to look for anywhere where it says bundle protocol  and I should expand the protocol column so you can see what's marked as TCP CL.  Frame number 14 shows up and in the info column it says bundle TCP CL segment, TCP segment  of a reassembled protocol data unit.  Wireshark's TCP reassembly function is on and we'll talk about how that affects the  view in just a little bit.  But if we look inside of frame 14, I'm going to move this up, what we can see is we can  see that we have the TCP header and then right after that Wireshark is telling us that three  different segments have been reassembled to create this bundle segment.  Let's stop for a moment and let me show you how bundles relate to bundle segments which  relates to TCP segments.  So the bundle protocol is essentially an application and you would have some other application that  uses it.  So let's say you wanted to do FTP across the galaxy, you could do that.  You would type in your FTP commands but that command would go through the bundle protocol  to transfer data.  So we would have a bundle here of data and bundles need to be transferred around.  It could be scientific information, it could be video, it could be pictures of the surface  of a planet or something like that.  It doesn't matter.  We have this big bundle of data and the bundle protocol is a store and forward protocol.  Again, it's covered in RFC 5050 if you want to go look up some information about this.  But when a bundle of data is going to a target system, it can be split up into bundle segments  and that is what we see in this trace file.  In this trace file, the bundle that is being transferred from the first host to the relay  has split the bundle up into four different segments.  When we look at it on the cabling system, it's really strange because we're so used  to an application sending down a certain amount of data and then the TCP segments go all the  way to the end of the data and stop.  That's not the way it's done with the bundle protocol.  A TCP segment may have some data from bundle segment A and it may have some data from bundle  segment B inside of it.  You can see that if this first bundle segment is going across the network, it's got a TCP  segment, another TCP segment, and then part of the third TCP segment is part of segment  A. Then bundle segment B goes out, but part of bundle segment B is sitting in the third  TCP segment here.  Then we have a TCP segment devoted to bundle segment B, another one, and then we only needed  part of another TCP segment.  But why stop the TCP segment and create a new one?  Nope.  We will have bundle segment C and it starts in the middle of a TCP segment.  Literally, you will see a header inside of this segment right here indicating that this  new bundle is coming up.  Same thing with the final bundle segment.  There will be a header right at the beginning of this bundle segment saying that this is  the start of a new set.  So let's go take a look at these bundle segments as they show up delivered by TCP segments.  So in the Info column we see on frame number 14 it says bundle TPCL segment.  When we click on it, we have an indication here of which packets were required to put  together this first bundle segment.  Frame number 11, frame 13, and frame 14.  And the numbers in parentheses are how much data fits into this bundle segment.  Now we can also see below this.  This is the TCP convergence header and unlike the TCP CL keep alive, there are more fields.  There are a total of four fields in this TCP convergence header.  So we have the packet type field.  So this is data.  Then we have this is indented.  So don't get stuck on this.  These are not new fields.  This is the summary line for these two below.  There is one bit that would indicate if this is the start of the entire bundle.  And there's another bit that indicates if this would be the last packet of the entire  bundle.  And then we have a line that tells us what that, how, I should say how large that TCP  bundle segment is.  That is a bundle segment length.  So let's do some customization of Wireshark based on these fields.  Number one, I want to take the packet type field and I'm going to right mouse click on  this and apply this as a column.  There we go.  It's easy now to see the difference between keep lives there and where data packets are.  And then I also want to do the same thing for segment contains start of bundle.  I'm going to right mouse click here.  And this is the start of bundle packet.  So I'm going to apply this as a column and we can see that it's true.  I'm going to center align that.  And then this next field segment contains end of bundle.  I'm going to add that as a column as well.  And I'll center align that.  Now it's pretty easy to look through the trace file and see which packets are the start  of the bundle.  And then farther on we'll be able to see which packets are the end of the bundle.  That's the end of the entire bundle.  Not the bundle set or bundle segment but the bundle itself.  To make it even easier to detect these, I'm going to set up two coloring rules.  I'm going to set up one coloring rule that turns all packets that are the start of the  bundle a green color and then the end of the bundle red.  So in frame number 14 I'm going to right mouse click on this line that says segment contains  start of bundle.  And I'm going to choose colorize with filter, new coloring rule.  And it's already set to a one because this is the start.  So I'm going to just name this start of bundle.  And then for the background I'm going to choose sort of a lime greenish.  Now by setting that coloring up it's very easy for me to detect where the start of the  bundles are in the trace file.  Three of the packets should have matched that.  Here's another thing we can do.  We can right mouse click on that field and just simply prepare a filter based on the  selected value.  That just puts that filter to detect the start of bundle packets up in my display filter  area.  And on the far right hand side of the display filter area there's a little plus there.  I'm going to click that plus and I'm going to turn this into a button.  I'm going to give the button a label which is going to be S-bundle.  That to me means start of bundle.  I'll say OK.  Now I have a button when I click on it any packets that have the start of bundle bit  set to a 1 will show up.  Let me clear out the filter that the button just applied.  I want to do the same thing with the end of bundle.  I want to give it a color.  I'm going to give it a vibrant red.  And then I'll make a button so I can easily detect the end of bundle and just show those  packets.  Now this packet has the end of bundle bit set to a 0.  I'm going to change that to a 1 when I do my coloring rule.  I'm going to change that to a 1 when I do my display filter button.  So I'm going to right mouse click on this packet, colorize with a filter, new coloring  rule, name it end of bundle.  And I'm going to give it a background color of this vibrant red.  I'll say OK.  OK.  So now it's very easy.  Oh, I forgot to change the number.  Well, it's good for you to see how to edit coloring rules.  To edit a coloring rule we go to view, coloring rules.  And I wanted to change this to a 1 at the end.  There we go.  All right.  So now we can see there's the start of a bundle.  There's the end of a bundle.  There's a start of a bundle.  And there's the end of a bundle right here.  The first start of bundle we see going from 10.0.0.1 to 10.0.0.3.  So the first thing we see in here is we see a bundle being transferred from dot 1 to dot  3 in bundle segments.  So that bundle is done right there, then down on frame 37 we see another bundle starting.  And this bundle is from dot 3 to dot 4.  This is the first bundle being forwarded on by dot 3.  So it's being relayed on.  And then we see the end of that bundle after it's been relayed.  And the very last packet that we see here from 3 going back to 1, it's a little strange.  It's its own bundle.  We can see that the start of bundle is set at true and the end of bundle is set at true.  First of all I want to pop up a button up here for end of bundle.  Well I'll use this packet since it has the end of bundle bit set on.  I'm going to go inside the TCP convergence layer here, right mouse click.  Just going to prepare it as a filter based on the selected value.  There it is.  That's what I want to build the button on.  So I'm going to click plus and give it a name.  E bundle.  That means end of bundle to me.  So now if I want to see the end of bundle packets only, I can click on the second button.  I want to see the start.  I can click on the first button.  I'm going to go ahead and clear this out.  Now you'll notice that after this bundle has been relayed from 3 to 4, there's this package,  this strange packet here, where it has the start and end of bundle bits set on.  That means it's its own little bundle.  And this is actually a reporting packet.  So let's go inside of it and take a look.  Let me bring up this.  Let's see.  I'm going to bring this sort of up so we see it up on top.  And it is frame 49 we're interested in.  And when we look inside of frame number 49, we see the TCP convergence layer indicating  it's the start of a bundle and the end of a bundle also.  So we're obviously not transferring a bunch of data here.  And then we'll see the primary bundle header.  And if we look a little bit further in here, we will see a payload header.  And beyond this, we have the administrative record.  So this is indicating right here that this is a bundle status report.  That's the purpose of this packet.  I don't want this packet to be colored red just because it hit the end of bundle coloring.  I want this packet to have its own coloring.  So I'm going to right mouse click on the line that says administrative record type bundle  status report.  And I'm going to choose to colorize this with a filter, make a new coloring rule.  There's that line, admin record type 1.  And I'm just going to say that this is the admin report.  I'm going to turn the background yellow for this one, say OK.  And now there we go.  This is the admin report.  And that admin report is being sent from dot 3 to dot 1 to say that I successfully  delivered the bundle on for you.  So now let's go up and just take a look at some of the packets in here and how this works.  In frame number 14, Wireshark says this is a bundle segment.  And sure enough, if we look inside, we can see the data packets that were required to  make up this bundle segment.  Packet 11, packet 13, packet 14.  And we can see the amount of data in each of those segments to make up in each of those  TCP segments to make up this bundle segment.  And then when we look down at frame number 18, again on the right-hand side, it says  bundle, TCP CL segment.  And if we look inside of that frame, we can see which TCP segments were required to make  up this bundle segment.  And there's the weird one right there.  So some of the data that's in packet number 14 is part of bundle segment A, whereas some  of the data in packet 14 is part of bundle segment B, the second bundle segment.  That's very interesting.  It's a bit of a different protocol.  And if we keep looking down here, and frame number 26, frame number 26 is listed here  as bundle, TCP CL segment.  And if we look inside of there, we can see, oh, let's see, 14.  I think I did that one before.  Let's clear that out, and let's go beyond that to the next bundle segment.  Oh, maybe I didn't.  I don't remember.  So I'm clicking on frame number 26, and in frame 26, oh, it just hadn't clicked.  I didn't click on frame 26 before.  It was still selecting frame number 18.  So now I'm on frame number 26 that says some of its data is in frame number 18.  Some of it is in 23, 24, and 26.  And then the last bundle segment is actually the one that finishes up the whole bundle.  So frame number 32, we can see its data.  And if we look down here, we can see exactly which frames were required, which TCP segments  were required to get this bundle segment across.  It is pretty, it can be pretty confusing to look at this because we have bundle segments  and then we have TCP segments, and they don't necessarily align.  Along the way here, we had some acts showing up.  So here we have the first bundle segment up here, and then we have an act down here on  frame number 20.  This frame number 20 act that we see, it is acknowledging receipt of this bundle segment.  This act down here on frame 27 is going to be acknowledging this bundle segment.  The act counts up.  So if I look at frame 20, I see an acknowledgement saying act length 4096.  That was how much data was in the first bundle segment.  I go to the next act and it says now I'm acting up to 8192 bytes because it's now acknowledging  the second bundle segment.  We'll see the next act coming up right here.  This act is acknowledging the third bundle segment.  So this guy is acknowledging this bundle segment, which of course includes those packets.  And we can see that it's counted up to 12,288.  And then we have the last act here, which is counting up also the very last bundle segment.  It can be sort of confusing to see what's happening when, especially when we have wire  sharks reassembly feature built into it.  But what I did is I made a little TCP spreadsheet that goes through what's happening here.  We have bundle segment A, bundle segment B, bundle segment C, bundle segment D there.  And these are the frames required and the amount of data in each of those frames.  When we add the data up in the bundle segment, we subtract 3 for the TCP convergence layer  overhead and that leaves us with the actual segment of data, the amount of data in there.  Same thing here on the second one.  It required four packets to get this across, subtract the TCP CL overhead and we're at  4096 here, another 4096 bundle segment, and then the last one isn't quite as long.  So I'll bring that back in in a moment when we talk about the bundle header itself.  So all of that was the bundle being transferred from 10.0.0.1 to 10.0.0.3 and then all of a  sudden we see 10.0.0.3 transferring this data over to 10.0.0.4.  And the same thing, we have data, data, data, data, interestingly enough, we have some acts  that show up later but for something else.  So when we look at this, let's reassemble what is being transferred across this network  as this bundle is being relayed.  We can go into any one of the Stream 1 packets and just right mouse click on the frame in  the packet list pane and select follow TCP stream.  This is the data that is being transferred by this bundle.  At the top of this bundle, you have these at signs and those are Keepalives.  So when you click on those, you can see you can click and that wire shark will take you  to the Keepalive packets in the background.  What is following that immediately, the next three bytes is actually the TCP convergence  layer for the very first bundle.  After that we have a bundle header and after that, this is all the bundle header, and then  after that we have the payload header.  So when we look at our segments going across, we have a bundle header that is applied only  on the first bundle segment.  Every single one of these bundle segments though starts with a TCP convergence layer  header.  That's how we know it's the beginning of a bundle segment.  The very first bundle will be followed by a bundle header and then it will be followed  by a payload header.  So these are the header structures that you would see in something like this.  We need to have that TCP CL header in there because that provides us with the interface  between TCP and the bundle protocol, it's kind of the shim between the two of them.  In this slide I'm showing you the amount of data that is carried in each one of these  TCP segments and when we add those up, these are the payload values.  When you look at the acts, we just count up from 4096, then we count up from there until  we get to our final value.  Let me just finish up by taking you into the bundle header for a moment.  We're going to go all the way down here to let's pull frame number 32.  This is the last frame of the bundle after it has been forwarded to, oh wait, nope, that's  not the one I want.  I want to go up to the first, hang on, I've got a filter on there, no wonder.  So let's go to, it doesn't matter which one of the red packets we go to, they'll basically  have this very similar information in them.  I'm going to go to this frame 46, let's say, that is the final packet of the bundle after  it's been forwarded to 10.0.0.4.  And let's go into the bundle header and let me bring the bundle header up in that top  window, there we go.  There are some strange things about the bundle header here.  For example, one of the big things that catches people is that this bundle header length field  does not include the whole entire bundle header, it includes only the fields that follow the  bundle header length field.  So the bundle header is actually 49 bytes.  And then the payload header is another 4 bytes.  So this packet is telling me the last packet of each of the bundle segments.  And then I can see down here, this is the amount of payload.  Now this is different than the final AC.  So if I come up here, and let me just show you what I'm talking about here, this AC right  here that we saw, this AC says that the amount of payload is 15,272 bytes.  Sure enough, that's what it is if we add up all of the payload from each of the bundle  segments.  But when we look inside of a bundle header to see how much payload it thinks has crossed  the network.  It's giving us a different value.  It's giving us 15,219.  And the way it gets there is we have to subtract out the 49 bytes of the bundle header plus  the 4 bytes of the payload header.  We got to get rid of 53 bytes from the extra payload headers and bundle header at the front.  So that's how we get to that particular number.  So I've shown you how we can add columns.  I've shown you how we can add buttons into Wireshark.  And I've shown you how we can add coloring rules into Wireshark to make analyzing the  bundle protocol and the TCP convergence layer protocol a little bit easier.
DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_0_839.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_840_4691.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_4692_4739.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_4740_5003.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_5004_5795.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_5796_6167.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_6168_7271.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_7272_7499.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_7500_8471.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_8472_8975.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_8976_12779.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_12780_12923.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_12924_13271.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_13272_14447.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_14448_15155.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_15156_16979.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_16980_18227.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_18228_18647.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_18648_19127.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_19128_20279.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_20280_20651.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_20652_21143.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_21144_24467.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_24468_24647.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_24648_24827.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_24828_26315.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_26316_26363.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_26364_27023.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_27024_27611.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_27612_29327.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_29328_29675.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_29676_32207.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_32208_32255.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_32256_32951.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_32952_33683.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_33684_35483.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_35484_35543.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_35544_35819.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_35820_43271.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_43272_43835.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_43836_44771.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_44772_45347.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_45348_45959.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_45960_47999.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_48000_48839.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_48840_49331.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_49332_50003.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_50004_50567.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_50568_50867.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_50868_51695.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_51696_52451.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_52452_52583.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_52584_52871.png DEF_CON_Safe_Mode_Aerospace_Village_-_Laura_Chappe_7QDEyQmPRjU_52872_52997.png
Hi, this is Laura Chappell and welcome to this video on Deep Space Networking Traffic Analysis. In this video I'm going to show you how I open up a trace file inside of Wireshark and begin the process of customizing Wireshark for Deep Space Networking Traffic Analysis. And we'll go through and learn about the bundle protocol and we'll learn about the TCP convergence layer. So let's go over to Wireshark and get started. In Wireshark I've opened up the trace file depicting the Deep Space Networking Traffic. Now we're talking about delay and disruption tolerant networking here or DTN we simply refer to it as. And in this scenario we have a host that is sending a bundle of data in bundle segments to another host to be relayed to a third host. So let's see what we have in this trace file. First of all we have some traffic that doesn't have anything to do with our DTN communications. It's this OSPF traffic. So I'm going to get that out of the way. Now what we're left with are some interesting packets here. First of all these top packets that you see, they're UDP packets, they're kind of sprinkled throughout the trace file. If you were to select one of those packets and look down in the packet bytes window what you would see is in the data portion it appears that we have a host that is announcing its DTN endpoint ID. So 10.0.0.1 is announcing that its endpoint ID is N1. Kind of like its name. On the second packet there we have 10.0.0.2 announcing its endpoint ID as N2 and the next packet 10.0.0.3 announcing its endpoint ID as N3. Alright that information right there is very interesting but it's not a data transfer process. That is just an announcement. What we're interested in are the TCP CL packets. So frame number 7 there is the first time we see a TCP convergence layer packet and this is just a keep alive. By looking at these keep lives we can get a general idea of which hosts can see which hosts. So in frame number 7 we have 10.0.0.3 sending a keep live to.4. The next packet we have.1 sending a keep live to 3. In packet 9 we have 3 sending a keep live to 1 and then in a little bit further on we see in packet 19 we have.2 sending a keep live to 4. Alright we can build a picture from this. This is what we know so far. It appears that we have 4 hosts and based on the keep lives we can see which hosts are talking to which hosts. So we can see based on the keep live that.1 can see.02,.2 can see 4, 4 can see 3, 3 can see 1 but we don't see any keep lives going between.1 and.4. We don't see any keep lives between.2 and.3. So perhaps we have something in the way between those two hosts. It could be something like a planet. So here I have a picture, one of the various pictures of Venus with a color filter on it. Now let's go back to the trace file. So let's take a look at when data actually begins to be sent here. We see an awful lot of those endpoint ID announcements and we see a bunch of keep lives and we see some acknowledgments for those keep lives. When we get down to frame number 57 that's the first time we see a larger length frame that probably has some data in it. So let's create a profile in Wireshark and we'll begin the customization process to help us analyze deep space networking traffic. So in the bottom right hand corner on the status bar in Wireshark it says Profile Default. I'm going to right mouse click on that column there on the bottom and say New and I'm going to name this profile DTN Example and I'll say OK. Now Wireshark takes me back to the default settings for profiles and this font is way too small. There's no way I'll be able to see that. So I'm going to zoom in here using the enlarge button on the main toolbar until I get to a font size that I like. Now with all of my profiles I always add one special column. I like to have it up with all the work that I do analyzing traffic. And that column is one that will tell me the conversation numbers in the trace file. Wireshark numbers all the UDP conversations and it numbers all the TCP conversations, it starts numbering each of them at zero and they are exclusive of each other. I'm going to go into the very first packet in here and inside the UDP header there is a field called the Stream Index field. And I want to add this as a column. To add a field as a column you simply right mouse click on that field and say Apply as column. I'm going to right mouse click on that column heading and choose to Align Center for the contents of that column. Now we've started creating this great column but we're not quite finished yet because our TCP traffic is not showing up with a Stream Index number. We've only told Wireshark to add a Stream Index column for UDP. So I'm going to right mouse click on that column header and I'm going to choose to Edit the column. And I can see right here that the field that it's based on is UDP.stream. I'm going to add on to this to say or TCP.stream. It doesn't matter if you do TCP.stream or UDP.stream or this direction, it doesn't matter either way that will work and I'm going to say OK. There we go. Now as conversations are intertwined it's easier for me to see which conversation I'm currently working in because I have the conversation number on the left hand side. So the next thing I want to do is I want to pull out the most active conversations in this trace file. I'm going to go up to Statistics and Conversations and I'm interested in the most active conversations based on the TCP layer. I'm going to sort based on the byte count from high to low and there I can see I have two conversations of interest here. These top two are what I want to look at. That's data flowing. So I'm going to right mouse click on the very first line here which is traffic between.3 and.1. I'm going to right mouse click and prepare a filter based on the selected value going in both ways. Then I'm going to go to the second line and I'm going to right mouse click, prepare a filter and this time I'm going to say or selected going in both directions. Mark Shark builds the filter for me in the background and I can see exactly what this filter is based on, the IP addresses that it's based on. I'll go ahead and I'll just apply that filter now. So I have two conversations, the top two conversations showing in this trace file. I'm going to go to File and I'm going to save this as a separate trace file now. These two conversations. I'll go to File, Export Specified Packets and I'm going to call this DTN Example. Now I'm going to open up that trace file called DTN Example because by default Mark Shark only saves the filtered packets. So here we go. Now we have some keep alive segments. Let's take a look down in the packet details window. Here we can see we have an Ethernet header, an IP header, a TCP header and then after the TCP header we have the DTN TCP Convergence Layer Protocol or TCP CL. It has its own header and for keep alive all we have is this single little field here saying that it is a keep alive. I want my keep alive to kind of melt into the background here. So I'm going to set up a coloring rule to change the way these show up in the packet list pane so they kind of melt away. I also don't need my capture filter anymore. So in the detail window I'm going to right mouse click on this keep alive packet and I'm going to colorize this with a filter and create a new coloring rule. There's the syntax put in there for this coloring rule and I'm just going to call it TCP CL, keep alive. On the bottom of this coloring rules window I'm going to click the background button and I'm going to change the background color to sort of a kind of a washed out grayish color let's say. I'll click OK and OK. Now those keep alive have their own background color of this gray showing up. The next thing I want to do is I want to look for anywhere where it says bundle protocol and I should expand the protocol column so you can see what's marked as TCP CL. Frame number 14 shows up and in the info column it says bundle TCP CL segment, TCP segment of a reassembled protocol data unit. Wireshark's TCP reassembly function is on and we'll talk about how that affects the view in just a little bit. But if we look inside of frame 14, I'm going to move this up, what we can see is we can see that we have the TCP header and then right after that Wireshark is telling us that three different segments have been reassembled to create this bundle segment. Let's stop for a moment and let me show you how bundles relate to bundle segments which relates to TCP segments. So the bundle protocol is essentially an application and you would have some other application that uses it. So let's say you wanted to do FTP across the galaxy, you could do that. You would type in your FTP commands but that command would go through the bundle protocol to transfer data. So we would have a bundle here of data and bundles need to be transferred around. It could be scientific information, it could be video, it could be pictures of the surface of a planet or something like that. It doesn't matter. We have this big bundle of data and the bundle protocol is a store and forward protocol. Again, it's covered in RFC 5050 if you want to go look up some information about this. But when a bundle of data is going to a target system, it can be split up into bundle segments and that is what we see in this trace file. In this trace file, the bundle that is being transferred from the first host to the relay has split the bundle up into four different segments. When we look at it on the cabling system, it's really strange because we're so used to an application sending down a certain amount of data and then the TCP segments go all the way to the end of the data and stop. That's not the way it's done with the bundle protocol. A TCP segment may have some data from bundle segment A and it may have some data from bundle segment B inside of it. You can see that if this first bundle segment is going across the network, it's got a TCP segment, another TCP segment, and then part of the third TCP segment is part of segment A. Then bundle segment B goes out, but part of bundle segment B is sitting in the third TCP segment here. Then we have a TCP segment devoted to bundle segment B, another one, and then we only needed part of another TCP segment. But why stop the TCP segment and create a new one? Nope. We will have bundle segment C and it starts in the middle of a TCP segment. Literally, you will see a header inside of this segment right here indicating that this new bundle is coming up. Same thing with the final bundle segment. There will be a header right at the beginning of this bundle segment saying that this is the start of a new set. So let's go take a look at these bundle segments as they show up delivered by TCP segments. So in the Info column we see on frame number 14 it says bundle TPCL segment. When we click on it, we have an indication here of which packets were required to put together this first bundle segment. Frame number 11, frame 13, and frame 14. And the numbers in parentheses are how much data fits into this bundle segment. Now we can also see below this. This is the TCP convergence header and unlike the TCP CL keep alive, there are more fields. There are a total of four fields in this TCP convergence header. So we have the packet type field. So this is data. Then we have this is indented. So don't get stuck on this. These are not new fields. This is the summary line for these two below. There is one bit that would indicate if this is the start of the entire bundle. And there's another bit that indicates if this would be the last packet of the entire bundle. And then we have a line that tells us what that, how, I should say how large that TCP bundle segment is. That is a bundle segment length. So let's do some customization of Wireshark based on these fields. Number one, I want to take the packet type field and I'm going to right mouse click on this and apply this as a column. There we go. It's easy now to see the difference between keep lives there and where data packets are. And then I also want to do the same thing for segment contains start of bundle. I'm going to right mouse click here. And this is the start of bundle packet. So I'm going to apply this as a column and we can see that it's true. I'm going to center align that. And then this next field segment contains end of bundle. I'm going to add that as a column as well. And I'll center align that. Now it's pretty easy to look through the trace file and see which packets are the start of the bundle. And then farther on we'll be able to see which packets are the end of the bundle. That's the end of the entire bundle. Not the bundle set or bundle segment but the bundle itself. To make it even easier to detect these, I'm going to set up two coloring rules. I'm going to set up one coloring rule that turns all packets that are the start of the bundle a green color and then the end of the bundle red. So in frame number 14 I'm going to right mouse click on this line that says segment contains start of bundle. And I'm going to choose colorize with filter, new coloring rule. And it's already set to a one because this is the start. So I'm going to just name this start of bundle. And then for the background I'm going to choose sort of a lime greenish. Now by setting that coloring up it's very easy for me to detect where the start of the bundles are in the trace file. Three of the packets should have matched that. Here's another thing we can do. We can right mouse click on that field and just simply prepare a filter based on the selected value. That just puts that filter to detect the start of bundle packets up in my display filter area. And on the far right hand side of the display filter area there's a little plus there. I'm going to click that plus and I'm going to turn this into a button. I'm going to give the button a label which is going to be S-bundle. That to me means start of bundle. I'll say OK. Now I have a button when I click on it any packets that have the start of bundle bit set to a 1 will show up. Let me clear out the filter that the button just applied. I want to do the same thing with the end of bundle. I want to give it a color. I'm going to give it a vibrant red. And then I'll make a button so I can easily detect the end of bundle and just show those packets. Now this packet has the end of bundle bit set to a 0. I'm going to change that to a 1 when I do my coloring rule. I'm going to change that to a 1 when I do my display filter button. So I'm going to right mouse click on this packet, colorize with a filter, new coloring rule, name it end of bundle. And I'm going to give it a background color of this vibrant red. I'll say OK. OK. So now it's very easy. Oh, I forgot to change the number. Well, it's good for you to see how to edit coloring rules. To edit a coloring rule we go to view, coloring rules. And I wanted to change this to a 1 at the end. There we go. All right. So now we can see there's the start of a bundle. There's the end of a bundle. There's a start of a bundle. And there's the end of a bundle right here. The first start of bundle we see going from 10.0.0.1 to 10.0.0.3. So the first thing we see in here is we see a bundle being transferred from dot 1 to dot 3 in bundle segments. So that bundle is done right there, then down on frame 37 we see another bundle starting. And this bundle is from dot 3 to dot 4. This is the first bundle being forwarded on by dot 3. So it's being relayed on. And then we see the end of that bundle after it's been relayed. And the very last packet that we see here from 3 going back to 1, it's a little strange. It's its own bundle. We can see that the start of bundle is set at true and the end of bundle is set at true. First of all I want to pop up a button up here for end of bundle. Well I'll use this packet since it has the end of bundle bit set on. I'm going to go inside the TCP convergence layer here, right mouse click. Just going to prepare it as a filter based on the selected value. There it is. That's what I want to build the button on. So I'm going to click plus and give it a name. E bundle. That means end of bundle to me. So now if I want to see the end of bundle packets only, I can click on the second button. I want to see the start. I can click on the first button. I'm going to go ahead and clear this out. Now you'll notice that after this bundle has been relayed from 3 to 4, there's this package, this strange packet here, where it has the start and end of bundle bits set on. That means it's its own little bundle. And this is actually a reporting packet. So let's go inside of it and take a look. Let me bring up this. Let's see. I'm going to bring this sort of up so we see it up on top. And it is frame 49 we're interested in. And when we look inside of frame number 49, we see the TCP convergence layer indicating it's the start of a bundle and the end of a bundle also. So we're obviously not transferring a bunch of data here. And then we'll see the primary bundle header. And if we look a little bit further in here, we will see a payload header. And beyond this, we have the administrative record. So this is indicating right here that this is a bundle status report. That's the purpose of this packet. I don't want this packet to be colored red just because it hit the end of bundle coloring. I want this packet to have its own coloring. So I'm going to right mouse click on the line that says administrative record type bundle status report. And I'm going to choose to colorize this with a filter, make a new coloring rule. There's that line, admin record type 1. And I'm just going to say that this is the admin report. I'm going to turn the background yellow for this one, say OK. And now there we go. This is the admin report. And that admin report is being sent from dot 3 to dot 1 to say that I successfully delivered the bundle on for you. So now let's go up and just take a look at some of the packets in here and how this works. In frame number 14, Wireshark says this is a bundle segment. And sure enough, if we look inside, we can see the data packets that were required to make up this bundle segment. Packet 11, packet 13, packet 14. And we can see the amount of data in each of those segments to make up in each of those TCP segments to make up this bundle segment. And then when we look down at frame number 18, again on the right-hand side, it says bundle, TCP CL segment. And if we look inside of that frame, we can see which TCP segments were required to make up this bundle segment. And there's the weird one right there. So some of the data that's in packet number 14 is part of bundle segment A, whereas some of the data in packet 14 is part of bundle segment B, the second bundle segment. That's very interesting. It's a bit of a different protocol. And if we keep looking down here, and frame number 26, frame number 26 is listed here as bundle, TCP CL segment. And if we look inside of there, we can see, oh, let's see, 14. I think I did that one before. Let's clear that out, and let's go beyond that to the next bundle segment. Oh, maybe I didn't. I don't remember. So I'm clicking on frame number 26, and in frame 26, oh, it just hadn't clicked. I didn't click on frame 26 before. It was still selecting frame number 18. So now I'm on frame number 26 that says some of its data is in frame number 18. Some of it is in 23, 24, and 26. And then the last bundle segment is actually the one that finishes up the whole bundle. So frame number 32, we can see its data. And if we look down here, we can see exactly which frames were required, which TCP segments were required to get this bundle segment across. It is pretty, it can be pretty confusing to look at this because we have bundle segments and then we have TCP segments, and they don't necessarily align. Along the way here, we had some acts showing up. So here we have the first bundle segment up here, and then we have an act down here on frame number 20. This frame number 20 act that we see, it is acknowledging receipt of this bundle segment. This act down here on frame 27 is going to be acknowledging this bundle segment. The act counts up. So if I look at frame 20, I see an acknowledgement saying act length 4096. That was how much data was in the first bundle segment. I go to the next act and it says now I'm acting up to 8192 bytes because it's now acknowledging the second bundle segment. We'll see the next act coming up right here. This act is acknowledging the third bundle segment. So this guy is acknowledging this bundle segment, which of course includes those packets. And we can see that it's counted up to 12,288. And then we have the last act here, which is counting up also the very last bundle segment. It can be sort of confusing to see what's happening when, especially when we have wire sharks reassembly feature built into it. But what I did is I made a little TCP spreadsheet that goes through what's happening here. We have bundle segment A, bundle segment B, bundle segment C, bundle segment D there. And these are the frames required and the amount of data in each of those frames. When we add the data up in the bundle segment, we subtract 3 for the TCP convergence layer overhead and that leaves us with the actual segment of data, the amount of data in there. Same thing here on the second one. It required four packets to get this across, subtract the TCP CL overhead and we're at 4096 here, another 4096 bundle segment, and then the last one isn't quite as long. So I'll bring that back in in a moment when we talk about the bundle header itself. So all of that was the bundle being transferred from 10.0.0.1 to 10.0.0.3 and then all of a sudden we see 10.0.0.3 transferring this data over to 10.0.0.4. And the same thing, we have data, data, data, data, interestingly enough, we have some acts that show up later but for something else. So when we look at this, let's reassemble what is being transferred across this network as this bundle is being relayed. We can go into any one of the Stream 1 packets and just right mouse click on the frame in the packet list pane and select follow TCP stream. This is the data that is being transferred by this bundle. At the top of this bundle, you have these at signs and those are Keepalives. So when you click on those, you can see you can click and that wire shark will take you to the Keepalive packets in the background. What is following that immediately, the next three bytes is actually the TCP convergence layer for the very first bundle. After that we have a bundle header and after that, this is all the bundle header, and then after that we have the payload header. So when we look at our segments going across, we have a bundle header that is applied only on the first bundle segment. Every single one of these bundle segments though starts with a TCP convergence layer header. That's how we know it's the beginning of a bundle segment. The very first bundle will be followed by a bundle header and then it will be followed by a payload header. So these are the header structures that you would see in something like this. We need to have that TCP CL header in there because that provides us with the interface between TCP and the bundle protocol, it's kind of the shim between the two of them. In this slide I'm showing you the amount of data that is carried in each one of these TCP segments and when we add those up, these are the payload values. When you look at the acts, we just count up from 4096, then we count up from there until we get to our final value. Let me just finish up by taking you into the bundle header for a moment. We're going to go all the way down here to let's pull frame number 32. This is the last frame of the bundle after it has been forwarded to, oh wait, nope, that's not the one I want. I want to go up to the first, hang on, I've got a filter on there, no wonder. So let's go to, it doesn't matter which one of the red packets we go to, they'll basically have this very similar information in them. I'm going to go to this frame 46, let's say, that is the final packet of the bundle after it's been forwarded to 10.0.0.4. And let's go into the bundle header and let me bring the bundle header up in that top window, there we go. There are some strange things about the bundle header here. For example, one of the big things that catches people is that this bundle header length field does not include the whole entire bundle header, it includes only the fields that follow the bundle header length field. So the bundle header is actually 49 bytes. And then the payload header is another 4 bytes. So this packet is telling me the last packet of each of the bundle segments. And then I can see down here, this is the amount of payload. Now this is different than the final AC. So if I come up here, and let me just show you what I'm talking about here, this AC right here that we saw, this AC says that the amount of payload is 15,272 bytes. Sure enough, that's what it is if we add up all of the payload from each of the bundle segments. But when we look inside of a bundle header to see how much payload it thinks has crossed the network. It's giving us a different value. It's giving us 15,219. And the way it gets there is we have to subtract out the 49 bytes of the bundle header plus the 4 bytes of the payload header. We got to get rid of 53 bytes from the extra payload headers and bundle header at the front. So that's how we get to that particular number. So I've shown you how we can add columns. I've shown you how we can add buttons into Wireshark. And I've shown you how we can add coloring rules into Wireshark to make analyzing the bundle protocol and the TCP convergence layer protocol a little bit easier.
Hi, this is Laura Chappell and welcome to this the Deep Space Networking Traffic. Now we're anything to do with our DTN communications. It's bundle segment. There will be a header right at add the data up in the bundle segment, we bundle will be followed by a bundle header and from the extra payload headers and bundle header