1
00:00:00,880 --> 00:00:06,720
Hi, this is Laura Chappell and I am here with... Jenny Spicer.

2
00:00:07,300 --> 00:00:18,340
And today we are going to take you into the Bundle Protocol version 7 using ION, the Interplanetary Overlay Network, and Wireshark.

3
00:00:18,340 --> 00:00:23,280
The title of our presentation is... Hitchhiker's Guide to the Deep Space Network.

4
00:00:24,060 --> 00:00:26,700
So this is what we're going to be covering today.

5
00:00:27,040 --> 00:00:31,060
Our mission is to provide you with an overview of ION.

6
00:00:31,060 --> 00:00:37,760
We'll show you the test suites and the various tests and we'll show you how to run tests.

7
00:00:37,760 --> 00:00:45,220
We're going to also show you how to customize Wireshark for analyzing space communications.

8
00:00:45,220 --> 00:00:55,820
You're going to see when we run these tests that the addressing in the tests are a little bit strange because they're using the loopback address for these tests.

9
00:00:55,820 --> 00:00:58,820
And that is kind of funky and what it does with Wireshark.

10
00:00:58,820 --> 00:01:01,000
So we'll deal with that in just a moment.

11
00:01:01,160 --> 00:01:04,060
We're going to run a couple of tests on ION for you.

12
00:01:04,260 --> 00:01:07,740
Jenny, do you want to tell them a little bit about the two tests we're going to run?

13
00:01:08,320 --> 00:01:14,900
We are going to be using BPING, which is basically a ping equivalent using the Bundle Protocol.

14
00:01:15,340 --> 00:01:21,940
We're going to get an echo back and be able to analyze the communication between two nodes.

15
00:01:21,940 --> 00:01:26,400
And then there is BPCHAT, which is actually sending text and having it reflected.

16
00:01:27,620 --> 00:01:37,420
And so we're going to be showing you how to analyze their use, those two little applications use of Bundle Protocol version 7.

17
00:01:37,420 --> 00:01:52,040
And we'll take a look over at the spec because we're going to see some things in the Bundle Protocol header that we just want to point you to the spec so you can see what other numbers might be in that location and what the spec says about what it's doing there.

18
00:01:52,040 --> 00:01:56,960
We'll also be providing the trace files that we capture during this.

19
00:01:57,040 --> 00:02:01,700
So you can analyze on your own and build your own Bundle profile.

20
00:02:02,160 --> 00:02:08,500
Yeah, we're not going to hand you the Bundle profile that we make in this session.

21
00:02:08,500 --> 00:02:15,560
That's a great lab exercise for you to learn how to customize Wireshark so that it works for you.

22
00:02:15,560 --> 00:02:17,080
You don't work for Wireshark.

23
00:02:17,260 --> 00:02:20,200
Okay, so let's go ahead and get started.

24
00:02:20,640 --> 00:02:24,820
All right, so on my system, the base operating system is Windows.

25
00:02:25,180 --> 00:02:29,060
But I have installed the VMware Workstation Player 16.

26
00:02:29,360 --> 00:02:34,240
And inside of there, I have an OpenSUSE 64-bit instance running.

27
00:02:34,240 --> 00:02:37,480
This is where I've installed Ion.

28
00:02:38,380 --> 00:02:42,620
And I also, you can see, I have Wireshark running on the left-hand side.

29
00:02:42,620 --> 00:02:44,900
It's not doing a capture right now at all.

30
00:02:44,900 --> 00:02:48,440
But let's start by looking at the Ion directory structure.

31
00:02:48,440 --> 00:02:52,140
Ginny, you want to take them in for just a bit of a tour on the directory structure?

32
00:02:52,540 --> 00:02:53,940
Yeah, absolutely.

33
00:02:55,220 --> 00:03:04,800
So the minute you get into Ion, the core directory has a whole bunch of supplementary scripts and supporting scripts, as well as a very helpful readme.

34
00:03:04,800 --> 00:03:08,800
If you want to get into Ion, I highly recommend looking at that as your first step.

35
00:03:09,280 --> 00:03:17,240
Mainly, though, we're going to be looking at the tests directory, where there are a lot of pre-written tests that we can run to capture traffic.

36
00:03:21,500 --> 00:03:24,740
Alright, so there is the test directory.

37
00:03:24,960 --> 00:03:32,500
And on the left-hand side, before we run any of these tests, I'll make sure that I start Wireshark capturing on the loopback adapter.

38
00:03:32,500 --> 00:03:36,260
Do you want to talk a little bit about why I'm capturing on loopback, Gin?

39
00:03:37,020 --> 00:03:54,160
So Ion generates traffic over the loopback adapter, even though it is using interplanetary node addresses, it's still going to be using 127.0.0.1 for every single packet that's going to cross your machine.

40
00:03:54,160 --> 00:03:56,400
So that's where you're going to want to capture your traffic.

41
00:04:01,840 --> 00:04:04,080
You're going to want to type .

42
00:04:04,080 --> 00:04:09,680
slash run tests, and then the name of the test you're going to run.

43
00:04:09,680 --> 00:04:11,660
We're going to start with vping.

44
00:04:12,280 --> 00:04:13,680
All right.

45
00:04:14,600 --> 00:04:21,260
Now, before we run the test, though, I want to make sure that Wireshark is starting to capture the traffic.

46
00:04:21,260 --> 00:04:23,520
I don't want to miss any of this traffic here.

47
00:04:23,520 --> 00:04:29,100
So over in Wireshark, on the left-hand side, I'm running Wireshark as root here.

48
00:04:29,140 --> 00:04:34,840
And I'm going to choose the loopback adapter here to run my test.

49
00:04:34,840 --> 00:04:37,200
So I can double click on that loopback adapter.

50
00:04:37,480 --> 00:04:46,780
If for some reason you want to put in a capture filter for this, which I wouldn't recommend, you know, there shouldn't be a lot of other stuff on your loopback adapter probably.

51
00:04:46,780 --> 00:05:00,200
But if you do want to put in a filter so you're only capturing loopback traffic, you could go into your capture options area and type in host space 127.0.0.1.

52
00:05:00,320 --> 00:05:06,700
And that will capture only traffic to or from 127.0.0.1.

53
00:05:06,700 --> 00:05:09,000
And you'll see how interesting this is in a moment.

54
00:05:09,000 --> 00:05:16,680
Keep in mind that if you also wanted to capture on an external adapter, you can select more than one adapter for your capture.

55
00:05:16,920 --> 00:05:21,940
I'm on, on my system, I'm just holding down the control key to select multiple adapters.

56
00:05:21,940 --> 00:05:25,640
But for this, we'll go ahead and just start capturing on loopback.

57
00:05:25,640 --> 00:05:28,160
So I've started the capture process running.

58
00:05:28,160 --> 00:05:33,420
I'm going to come back over here and hit enter to start the test running.

59
00:05:35,830 --> 00:05:46,610
When BPING is running, you're seeing the output of the script as it is running through, including notes about what the test is currently, or what is currently being tested.

60
00:05:47,030 --> 00:05:57,430
And if you want to later, you could actually look inside of the script and see the notes from the creators of Ion of how this is running, and what each section is doing.

61
00:05:57,430 --> 00:06:01,190
Right now, you can see that it's verifying certain errors are not occurring.

62
00:06:01,530 --> 00:06:06,950
And each one of those dots is a packet that is being received.

63
00:06:07,770 --> 00:06:17,570
One of the things I think is interesting is that for every test you run in Ion, Ion is not running in the background at any point until you start a test.

64
00:06:17,570 --> 00:06:29,010
Then it launches Ion, goes and grabs all of its supplemental files for configuration, things like that, runs according to that script, and then it cleans itself up at the end.

65
00:06:29,010 --> 00:06:32,010
So you can see it's doing a kill M at the end here.

66
00:06:32,010 --> 00:06:35,750
And that's where it's terminating all of the Ion processes.

67
00:06:41,170 --> 00:06:47,790
So now let's go over to Wireshark, and let's focus on this trace file and what we can see.

68
00:06:47,790 --> 00:06:59,250
The first thing I want to do is I want to make a profile for this communication, for analyzing the bundle communication, or analyzing Ion communication.

69
00:06:59,250 --> 00:07:09,270
So in Wireshark, to do that, I'm going to right-mouse-click in the profile area down on the status bar, and I'm going to select New, and I'm going to give it a name.

70
00:07:09,270 --> 00:07:13,210
I'm just going to call it Ion, and then I'll say OK.

71
00:07:14,090 --> 00:07:19,870
You'll see that we have some the default profile, and then we have some other profiles that are already created for us in here.

72
00:07:19,870 --> 00:07:21,970
But I want to make a brand new one.

73
00:07:22,590 --> 00:07:26,870
So now, in the bottom right-hand corner, it tells me I'm in the Ion profile.

74
00:07:26,870 --> 00:07:36,450
If you want to move around to different profiles, you just simply click on that right-hand side of the status bar and select the next profile you want to move to.

75
00:07:37,110 --> 00:07:39,930
But here's what's interesting in this.

76
00:07:39,930 --> 00:07:49,130
You can see that in this test, the traffic ran from 127.0.0.1 to 127.0.0.1.

77
00:07:49,130 --> 00:07:54,230
So this source and destination columns, those are pretty useless.

78
00:07:55,170 --> 00:08:02,750
So let me bring this up so we can see a little bit more about the bundle protocol here, and I'll pop up to the top packet here.

79
00:08:02,850 --> 00:08:09,630
I'm going to right-mouse-click, and I'm going to hide the source and destination columns because they're worthless to me.

80
00:08:09,630 --> 00:08:14,510
They don't tell me who the actual source was, who the destination was.

81
00:08:14,810 --> 00:08:19,790
So let's take a look inside this bundle header in here.

82
00:08:19,790 --> 00:08:27,510
And again, we're talking about bundle protocol version 7, and that's RFC 9171.

83
00:08:28,150 --> 00:08:32,930
Now I know my test is done, so I'll go ahead and stop the capture process up above that.

84
00:08:33,650 --> 00:08:40,870
So there we can see the UDP header right there, destination port 4556.

85
00:08:41,270 --> 00:08:45,970
Below UDP here we have the DTN bundle protocol.

86
00:08:45,970 --> 00:08:49,730
DTN standing for delay and disruption tolerant networking.

87
00:08:50,950 --> 00:08:59,010
And there's a summary line here that tells us the payload size, the number of blocks that are in this, and we'll talk about the blocks in just a second.

88
00:08:59,010 --> 00:09:04,270
But there I can see in the summary line the destination and the source.

89
00:09:04,550 --> 00:09:18,070
So this packet is going from interplanetary networking 1.2 host to... from interplanetary networking 1.1 host.

90
00:09:18,070 --> 00:09:21,790
We'll talk about the time in just a moment and the sequence number in just a moment.

91
00:09:22,470 --> 00:09:28,390
Okay, Jen, do you want to start telling me a little bit about this indefinite array piece here?

92
00:09:29,030 --> 00:09:33,630
Yes, so this has to do with a new feature of bundle version 7.

93
00:09:33,630 --> 00:09:37,530
Bundle version 7 will use CBOR encoding.

94
00:09:39,630 --> 00:09:46,530
There are three settings available... preference settings available in Wireshark for the bundle protocol version 7.

95
00:09:46,530 --> 00:09:49,010
If you were to right mouse click on the bundle...

96
00:09:49,010 --> 00:10:02,970
anywhere in a bundle protocol header and go to protocol preferences, you'll see compute and compare CRCs, reassemble fragmented payloads, and then attempt the heuristic dissection of the BTSD payload.

97
00:10:02,970 --> 00:10:05,650
And if I choose that, there it is.

98
00:10:05,650 --> 00:10:08,990
There's that CBOR that shows up underneath.

99
00:10:08,990 --> 00:10:17,010
And Wireshark's saying, you know, I think this is the style of communication being used here, that this is being done in this format.

100
00:10:17,030 --> 00:10:20,650
So it's concise binary object representation.

101
00:10:21,410 --> 00:10:27,450
So bundle version 7 stores its blocks in an indefinite array.

102
00:10:27,450 --> 00:10:37,590
This helps it be flexible with how many blocks are included in a single packet and keep it in the fewest number of bytes we can.

103
00:10:37,950 --> 00:10:42,930
CBOR encoding starts an indefinite array with 9F.

104
00:10:42,930 --> 00:10:51,170
So that is it beginning and saying we have an indefinite array of blocks coming up and at the very end you will see FF.

105
00:10:51,770 --> 00:10:55,230
That is the termination of this indefinite array.

106
00:10:55,230 --> 00:10:59,550
That has to do with just the standard break encoding from CBOR.

107
00:11:00,170 --> 00:11:07,630
That's interesting and you know I've got the the hex window up too and you can see that that's the actual end of the packet.

108
00:11:07,630 --> 00:11:23,410
What follows this is an expert warning and we're going to talk about that in a moment because we're gonna we're gonna alter Wireshark expert notification system because that's you don't want to be warned on what's inside of here and we'll talk about that.

109
00:11:23,410 --> 00:11:29,450
I'm going to go ahead I'm going to turn off that protocol preference to use the heuristic dissection routine.

110
00:11:29,730 --> 00:11:46,410
All right so beyond the starting point where it says indefinite array, which is what's coming up, then we have the primary block and I'm going to expand the primary block and let me bring this down so we have just a little bit more room and I'll bring it up here.

111
00:11:49,120 --> 00:11:55,420
So the first thing you have is the version field that's telling us we are using bundle protocol version 7.

112
00:11:55,980 --> 00:12:02,020
And then below this you have bundle flags and you can expand these to see what's happening here.

113
00:12:02,180 --> 00:12:09,720
This is requesting status time in a report so basically it's asking our target to report back to it.

114
00:12:10,700 --> 00:12:19,340
Down below that let's just focus on some of the interesting fields here because otherwise we could go through the whole entire RFC on this.

115
00:12:19,340 --> 00:12:27,760
But the destination endpoint and the source node ID are important to us as is the report to node.

116
00:12:27,760 --> 00:12:38,960
And if you just click on this summary line and you drag it up to be a column it's just going to tell you that that exists.

117
00:12:39,080 --> 00:12:45,460
So this is not the way you make a bundle destination and source column.

118
00:12:45,500 --> 00:12:47,840
So I'm going to right mouse click and remove this column.

119
00:12:47,840 --> 00:12:58,140
What you want to do is you want to expand this section and go down to the summary line that's inside square brackets in that section.

120
00:12:58,140 --> 00:13:07,100
And we want to drag that destination URI uniform resource indicator up to be its own column.

121
00:13:07,100 --> 00:13:08,760
And now I can read that.

122
00:13:08,760 --> 00:13:10,300
That's just what I want to see.

123
00:13:10,480 --> 00:13:16,380
I'm going to do the same thing for source right here.

124
00:13:17,640 --> 00:13:19,620
I'm going to put source on the left.

125
00:13:20,040 --> 00:13:27,800
And then the last one I'm going to do this for is the report to URI.

126
00:13:31,940 --> 00:13:32,740
There.

127
00:13:32,740 --> 00:13:33,560
Okay.

128
00:13:39,070 --> 00:13:39,790
All right.

129
00:13:39,790 --> 00:13:44,210
So below this, I don't know Jenny if you want to hop in on any points in here.

130
00:13:44,210 --> 00:13:48,330
I'm just going to keep going if that's okay and you can just hop in.

131
00:13:48,330 --> 00:13:54,530
I just wanted to point out that for URI it's identifier not indicator.

132
00:13:54,650 --> 00:13:57,010
Oh see I always say that.

133
00:13:57,010 --> 00:13:59,690
I think I learned that from you and now I'm checking myself on it.

134
00:13:59,690 --> 00:14:00,490
Oh I'm sorry.

135
00:14:00,490 --> 00:14:01,290
I'm sorry.

136
00:14:01,290 --> 00:14:02,070
Yeah.

137
00:14:02,190 --> 00:14:02,890
All right.

138
00:14:03,230 --> 00:14:10,270
So we have the creation timestamp which is where you say when you created this bundle that's being sent out.

139
00:14:10,510 --> 00:14:13,970
There is a sequence number field in here.

140
00:14:13,970 --> 00:14:15,410
The lifetime.

141
00:14:15,830 --> 00:14:20,810
So you could think of lifetime as almost a time to live value in here.

142
00:14:20,810 --> 00:14:23,030
When this will expire.

143
00:14:24,030 --> 00:14:32,210
And I'm going to collapse this section and go to the next section just at the bottom of this primary block.

144
00:14:32,510 --> 00:14:40,290
So below the primary block Wireshark has this piece in square brackets called the bundle identity.

145
00:14:40,290 --> 00:14:55,970
The identity of this bundle of information is a combination of the source address and the delay and disruption tolerant networking time value and the sequence number.

146
00:14:59,700 --> 00:15:08,020
So here's something that was interesting that Ginny and I found when we were looking at the RFC for the bundle protocol.

147
00:15:08,020 --> 00:15:11,380
DTN time, delay and disruption tolerant networking time.

148
00:15:11,380 --> 00:15:17,540
You know we're used to EPIC time but Ginny you want to tell them what DTN time is based on?

149
00:15:17,820 --> 00:15:21,640
So DTN time starts with the year 2000.

150
00:15:21,960 --> 00:15:24,940
It also ignores leap seconds which they make sure to know.

151
00:15:25,260 --> 00:15:30,220
Yeah so that's I thought that was pretty interesting.

152
00:15:30,220 --> 00:15:40,960
There's a lot of issues with time in space and we'll we're going to talk to you a little bit about where you can learn more about space comms at the end of this presentation.

153
00:15:41,060 --> 00:15:43,120
We have some recommendations for you.

154
00:15:43,260 --> 00:15:47,680
All right so I'm going to close up the primary block here and now I'm going to go to the next block.

155
00:15:47,680 --> 00:15:50,120
This canonical block here after that.

156
00:15:50,120 --> 00:15:55,920
Now here you can see that this block begins with a type code.

157
00:15:55,920 --> 00:16:04,120
Just like if we look at our our primary block it doesn't have this type code in it because you have to have the primary block in there.

158
00:16:04,120 --> 00:16:06,560
That has to be the first block you're always going to have.

159
00:16:06,560 --> 00:16:11,440
So there's no reason to really have a type field in there when we know the first block is going to be the primary block.

160
00:16:11,440 --> 00:16:19,540
But now we have a type code telling us what this block is and we can see that we have there's a canonical block there.

161
00:16:19,540 --> 00:16:24,600
One, two, three, four blocks after the primary block.

162
00:16:24,980 --> 00:16:33,280
And so now might be a good time to show you the RFC for this type code value.

163
00:16:33,300 --> 00:16:36,260
So let me pop out to the RFC.

164
00:16:40,790 --> 00:16:49,710
All right so section four in here talks about the blocks and we can see that there are all these other blocks beside the primary block.

165
00:16:49,710 --> 00:16:51,150
These are called extension blocks.

166
00:16:51,150 --> 00:16:55,770
One of them is previous node which is what we see right here.

167
00:16:55,770 --> 00:17:03,610
Block type six identifies the node that forwarded this bundle to the local node.

168
00:17:04,850 --> 00:17:07,710
You'll see there's a bundle age block.

169
00:17:08,190 --> 00:17:10,730
There's a hop count block.

170
00:17:13,500 --> 00:17:18,160
And there is a list in here of all of the blocks.

171
00:17:18,160 --> 00:17:25,120
Let's see if... so bundle block types.

172
00:17:25,120 --> 00:17:26,120
There we go.

173
00:17:26,120 --> 00:17:28,640
9.1, section 9.1.

174
00:17:28,940 --> 00:17:42,300
So in here you can see it tells you which bundle protocol version supports that block type which of course version 6 and version 7 support, you know, the primary bundle block.

175
00:17:42,300 --> 00:17:51,700
And then you've got down here when you get to previous node you get to the bundle age and you get to the hop count.

176
00:17:51,700 --> 00:17:55,100
Those are those are only supported in version 7.

177
00:17:55,860 --> 00:18:03,740
And then you'll see that we've got some unassigned blocks and some reserved blocks which we'll talk about in just a moment in the trace file.

178
00:18:05,780 --> 00:18:16,700
All right so if we look inside of here there are fields inside of fields inside of fields inside of each of these blocks.

179
00:18:16,700 --> 00:18:25,440
So with Wireshark what you might want to do is when you get to a block type you can right mouse click and you can say that you want to expand the subtrees.

180
00:18:25,440 --> 00:18:30,140
And that will expand all of the fields of that block only.

181
00:18:32,040 --> 00:18:35,120
So now I can see there's a specific information

182
00:18:38,620 --> 00:18:40,980
previous URI this came from.

183
00:18:40,980 --> 00:18:44,580
I'm going to collapse that block and we'll take a look at the next block.

184
00:18:44,780 --> 00:18:47,580
Now this block is interesting.

185
00:18:47,920 --> 00:18:51,180
This block is throwing an error in Wireshark.

186
00:18:54,150 --> 00:18:58,630
So Jan you want to tell them why this is throwing that error in Wireshark?

187
00:18:59,130 --> 00:19:10,050
So this canonical block mentions that it is type 193 which in that table in the RFC we can see is reserved for private or experimental use.

188
00:19:10,050 --> 00:19:16,210
Yeah so I guess when I guess when they were writing ION they decided to put in something like that.

189
00:19:16,210 --> 00:19:26,010
And I don't know why we could probably could reach out to Scott Burley and Jenny and ask him but it might be as an identifier that this is an ION test that they're running.

190
00:19:26,010 --> 00:19:33,010
Or it could be they want to see does this break ION or does it break BPING.

191
00:19:33,170 --> 00:19:37,330
You know that you have something that's unexpected inside of there.

192
00:19:37,330 --> 00:19:42,670
Or did the target system just turn around and echo it back anyway.

193
00:19:45,110 --> 00:19:48,130
So let's see so that's this one.

194
00:19:48,130 --> 00:20:00,650
Now might be a good time if this irritates you this expert notification that oh warning this is a real problem because it's really not.

195
00:20:01,450 --> 00:20:10,230
Let me show you how you can change Wireshark's expert severity level for something.

196
00:20:10,430 --> 00:20:16,430
So this one right here is what is generating Wireshark's experts information.

197
00:20:16,430 --> 00:20:24,570
We can see that it says unknown type code and it says it's undecoded doesn't know what it is.

198
00:20:24,570 --> 00:20:32,330
There's the protocol for it and maybe I don't want these to be warnings because I don't think that they're that big of a deal.

199
00:20:32,690 --> 00:20:48,850
So as I am clicking on this unknown type code I can see down below that the syntax for a display filter for this would be BPV7.sub underscore type underscore unknown.

200
00:20:48,850 --> 00:20:52,130
All right I'm going to go up to edit preferences.

201
00:20:52,870 --> 00:20:55,330
I'm going to go to expert.

202
00:20:55,450 --> 00:21:07,170
I'm going to add an entry in here and in the field name I'm going to put in BPV7.sub underscore type underscore unknown.

203
00:21:07,330 --> 00:21:23,550
So anytime that happens I want Wireshark to say oh it's just a note and I'll say okay and now we can see that that has changed the color of that issue.

204
00:21:23,550 --> 00:21:32,490
It's changed it to this blue and now my expert will bring it up as just a note and it will do that anytime it sees an unknown type code.

205
00:21:32,490 --> 00:21:37,710
Interestingly enough it just fully expanded out my DTN section when I did that too.

206
00:21:37,750 --> 00:21:40,570
I don't really want that fully expanded out.

207
00:21:41,490 --> 00:21:47,110
Okay so there's that canonical block that is using an illegal number.

208
00:21:47,110 --> 00:21:50,230
Okay then we have the bundle age below that.

209
00:21:51,670 --> 00:21:55,270
So there's the bundle age two milliseconds in here.

210
00:21:57,310 --> 00:21:59,890
And then below that we have the payload.

211
00:22:00,390 --> 00:22:03,670
So this is what's being sent across the network.

212
00:22:03,670 --> 00:22:20,610
You can see when I click on the that block for payload and I click there we go and I click on that then it's just highlighting in the hex dump all of the payload section there not including that indefinite break at the end the FF at the end.

213
00:22:20,610 --> 00:22:23,030
So that is the payload in here.

214
00:22:23,650 --> 00:22:25,670
It's being sent across.

215
00:22:26,490 --> 00:22:38,130
If you wanted to you could keep adding columns up above for the different block types that are in use.

216
00:22:39,450 --> 00:22:45,190
You could add a column for the different length values.

217
00:22:45,190 --> 00:22:49,730
Let's say we take this type code payload here and I click and drag it up.

218
00:22:51,410 --> 00:22:53,530
This is what you'll see in Wireshark.

219
00:22:53,530 --> 00:23:03,990
You'll see that Wireshark will tell you every single block type that's inside of each one of these packets.

220
00:23:04,110 --> 00:23:16,050
So you just need to add one column for type code and then you'll be able to see all of the different blocks that are inside of there.

221
00:23:18,130 --> 00:23:29,730
What's interesting in here, Jenny, we've got there's our bundle going out, another bundle going out here, there's some echoes coming back.

222
00:23:34,420 --> 00:23:43,640
So you may notice when you run this that if you look in your UDP header you'll see a length value of 150 and then all of a sudden it switches to 151.

223
00:23:43,640 --> 00:23:48,680
And we were spending some time looking at this and Jenny figured out what it was.

224
00:23:48,760 --> 00:23:51,120
Do you want to tell them what it is?

225
00:23:51,120 --> 00:23:54,680
This has to do with that CBOR encoding again.

226
00:23:54,720 --> 00:23:58,200
Specifically how it is encoding the sequence number.

227
00:23:58,300 --> 00:24:03,660
When you reach sequence number 24 you now need two bytes to say that number.

228
00:24:03,660 --> 00:24:10,680
So if you see a sudden uptick of a single byte it could be an encoding and it could be the encoding causing.

229
00:24:11,500 --> 00:24:27,280
Yeah so for here you can see we're at sequence number 30 right here and this one did start at sequence 27 so we were above that sequence number 24 that suddenly gave us an extra byte.

230
00:24:28,640 --> 00:24:32,160
It's very interesting this encoding mechanism.

231
00:24:32,740 --> 00:24:39,400
Okay so as you look at this you're looking at these these bundles being sent across and echoed back.

232
00:24:39,400 --> 00:24:44,240
The same data should sit in the bundles that are being echoed back.

233
00:24:44,240 --> 00:24:57,420
Now we do know that at the end of most of the tests that we've run in ION you're gonna see this one little extra packet showing up or two little extra packets.

234
00:24:57,420 --> 00:25:03,080
And we did talk with Scott Burley who wrote ION and is one of the authors and bundle protocol.

235
00:25:03,100 --> 00:25:16,520
And it's the it's something with the closing process of a thread that he said kind of kicks that out at the end but you can disregard that last little it's it's the toilet paper hanging on the shoe of the test.

236
00:25:16,900 --> 00:25:19,220
I guess something like that.

237
00:25:19,960 --> 00:25:34,240
If you have other loopback traffic in your trace file and you don't want that other traffic to be saved you would put in a filter for IP dot ADDR equal sign equal sign 127.0.0.1.

238
00:25:34,340 --> 00:25:38,260
You know you do 127 dot anything.

239
00:25:38,380 --> 00:25:43,360
And when you apply that you would have this loopback traffic from your test.

240
00:25:43,500 --> 00:25:47,220
And that's when you would say export specified packets.

241
00:25:47,220 --> 00:25:52,280
Here I've got a directory oops wait cancel now I don't want to replace that one.

242
00:25:52,320 --> 00:25:58,100
I'm gonna go ahead and call this ION411 vping.

243
00:26:04,100 --> 00:26:07,660
And now we're ready to start the next test.

244
00:26:14,670 --> 00:26:20,610
All right so now I'm gonna go ahead and just start Wireshark running.

245
00:26:20,610 --> 00:26:23,370
I don't want to save the previous stuff.

246
00:26:25,830 --> 00:26:32,630
You'll see it's starting in the loopback interface here so I want to make sure I'm capturing a loopback.

247
00:26:33,050 --> 00:26:35,350
And what I'm gonna run this time Jenny?

248
00:26:35,990 --> 00:26:38,210
This time we're gonna do BP chat.

249
00:26:40,880 --> 00:26:46,040
This is going to spit out a text file from one node that will be reflected back.

250
00:26:51,790 --> 00:26:55,970
So it goes through making sure ION's been shut down from before.

251
00:27:00,980 --> 00:27:04,840
And you can see how those dots go across with the traffic.

252
00:27:12,060 --> 00:27:18,320
And tells you ION will now stop and clean the node for you.

253
00:27:18,320 --> 00:27:20,080
Goes through the cleanup process.

254
00:27:20,080 --> 00:27:28,180
We can see that the that ION is shutting down because of the those spare little weird packets that show up in the trace file.

255
00:27:30,060 --> 00:27:41,780
And again we have that experimental block number showing up that 193.

256
00:27:44,200 --> 00:27:48,320
So here's something I thought was interesting in this one.

257
00:27:48,320 --> 00:27:52,360
If we look at the first frame when this runs.

258
00:27:57,520 --> 00:28:03,700
Okay at the beginning you have a BPing that goes across.

259
00:28:04,080 --> 00:28:07,580
And there's our BPing payload down there.

260
00:28:07,980 --> 00:28:12,680
There's another BPing that goes across right here.

261
00:28:14,220 --> 00:28:19,960
And then all of a sudden it says this is some test input to BP chat.

262
00:28:24,800 --> 00:28:28,400
So you can read what's actually being sent across.

263
00:28:28,400 --> 00:28:37,620
And what's interesting in here is if you've followed streams before you can right mouse click and say that you want to follow the UDP stream.

264
00:28:37,620 --> 00:28:41,040
But it doesn't make a lot of sense.

265
00:28:41,780 --> 00:28:53,620
Wireshark marks all of this the same color because it came from 127.0.0.1 going to 127.0.0.1.

266
00:28:53,620 --> 00:29:08,600
Wireshark is not differentiating the communications based on source and destination port number that could possibly be different or you know and it doesn't understand that these are different IPN node numbers on each side of the communication.

267
00:29:09,080 --> 00:29:16,780
So you'll see this is some test input to BP chat.

268
00:29:16,780 --> 00:29:19,620
This is it now it's being echoed back here.

269
00:29:20,700 --> 00:29:29,240
This is going out and this is being reflected back from this one up here.

270
00:29:32,180 --> 00:29:35,860
Here's another thing we noticed we were analyzing it.

271
00:29:35,860 --> 00:29:47,320
When we looked at the conversations here, check out what Wireshark says the conversations are in this echoing process.

272
00:29:47,600 --> 00:29:56,340
It says there are zero bytes coming from 127.0.0.1 from port 4556.

273
00:29:56,940 --> 00:30:02,960
All the bytes are coming from port number 54468.

274
00:30:02,960 --> 00:30:07,920
So Ginny and I were looking at this and it was interesting.

275
00:30:08,380 --> 00:30:14,400
Yeah it's true they both receive at the same port and send at the same port.

276
00:30:14,700 --> 00:30:26,120
So because of this we decided in our profile we wanted to put the source port and the destination port information up in our columns here.

277
00:30:26,200 --> 00:30:27,980
And sure enough look at this.

278
00:30:27,980 --> 00:30:43,440
This is stuff going back and forth between hosts but they both use the same port number for the source when they're sending or echoing back something which is really really strange.

279
00:30:44,340 --> 00:31:00,500
But taking time to look at this and spend time with Wireshark, changing Wireshark's settings makes it easier for us to understand some of these strange behaviors that are going on using this new protocol.

280
00:31:01,820 --> 00:31:05,220
So I'm going to stop the capture at this point.

281
00:31:06,120 --> 00:31:19,960
I don't have any other background traffic in here so I'm just going to say I want to save this trace file and I'm going to save this one as VPChat.

282
00:31:22,430 --> 00:31:28,330
And we'll make those two trace files available to you to work with.

283
00:31:29,530 --> 00:31:34,950
Is there anything you can think of that we should share with folks before we go to our closing slide?

284
00:31:36,150 --> 00:31:45,170
I would say when you get the trace files and definitely do take a look at them, go through the steps to create your own profile.

285
00:31:45,170 --> 00:31:52,330
It is the best way to come to grips with the protocol and see its little nitty-gritty details because there's a lot of that.

286
00:31:52,330 --> 00:31:56,050
Plus there are so many more tests that we haven't touched on in this.

287
00:31:56,890 --> 00:32:02,290
Yeah, spend some time with the other tests and read the README in the ION directory.

288
00:32:02,810 --> 00:32:03,770
Wow.

289
00:32:04,510 --> 00:32:05,990
Read the README.

290
00:32:05,990 --> 00:32:07,890
I'm just telling you right now.

291
00:32:08,670 --> 00:32:16,290
If you're like us and you just jump in, you know, oh let me just try this and play this, you know, play around with this.

292
00:32:16,290 --> 00:32:19,870
Yeah, you can spend a little time going down some rabbit holes.

293
00:32:19,870 --> 00:32:23,050
So just a warning on that one.

294
00:32:23,150 --> 00:32:25,710
The README will be your friend with this application.

295
00:32:26,090 --> 00:32:27,410
So true.

296
00:32:28,310 --> 00:32:31,530
Okay, so let me get back to our closing slide here.

297
00:32:32,610 --> 00:32:37,350
So Ginny, why don't you go ahead and wrap it up for us with this.

298
00:32:37,350 --> 00:32:46,650
And I can, if you'd like Ginny, I can toggle some of these to show them, these items on the right hand side of my screen while you mention what's going on.

299
00:32:46,730 --> 00:32:47,850
Okay.

300
00:32:49,370 --> 00:32:50,690
All right.

301
00:32:50,750 --> 00:32:55,870
If you want to get ION, you should go to the official page on SourceForge.

302
00:32:56,150 --> 00:33:00,890
This is the official release from the folks at the JPL.

303
00:33:01,730 --> 00:33:06,450
It's pretty easy to set up once you get the first couple of steps in.

304
00:33:09,130 --> 00:33:13,450
Beyond that, I would say take a look at the RFC itself.

305
00:33:13,450 --> 00:33:26,350
You are going to hit little, little details that will throw you off because Bundle has to work differently from other protocols to tolerate the incredible environment of space.

306
00:33:27,350 --> 00:33:35,090
And of course, Wireshark, the Wireshark project, there are tons of resources to help any trouble shooting there.

307
00:33:35,110 --> 00:33:38,870
If you're hitting technical issues with Wireshark.

308
00:33:39,050 --> 00:33:45,270
We also have the Interplanetary Networking Special Interest Group.

309
00:33:45,270 --> 00:33:47,870
We are both a member of this group.

310
00:33:47,870 --> 00:33:49,310
It's fantastic.

311
00:33:49,310 --> 00:33:56,730
It has so many experts who care so deeply about this project from space agencies across the globe.

312
00:33:56,730 --> 00:33:57,830
Including?

313
00:33:58,350 --> 00:34:06,590
Including NASA, including the ESA, the European Space Agency, JAXA.

314
00:34:07,070 --> 00:34:11,650
And we also have private groups that have entered.

315
00:34:11,650 --> 00:34:12,270
Yeah.

316
00:34:12,270 --> 00:34:23,230
And there's also one really interesting person that's in the group that designed and thought up delay and disruption tolerant networking.

317
00:34:23,290 --> 00:34:24,110
Yes.

318
00:34:24,110 --> 00:34:25,690
Designing the next internet.

319
00:34:25,690 --> 00:34:32,910
After he designed the first one, Vint Cerf is part of the Interplanetary Networking SIG.

320
00:34:32,910 --> 00:34:43,350
He's very active and helping to, he is guiding the formation of the next internet and its governance and its technical aspects as well.

321
00:34:43,390 --> 00:34:46,410
So head out to ipnsig.org.

322
00:34:46,410 --> 00:34:51,070
I just want to mention that we have some IPN SIG Academy events coming up.

323
00:34:51,850 --> 00:35:00,170
And that's a whole series of events running over a one-year timeframe to educate people on interplanetary communications.

324
00:35:00,170 --> 00:35:02,970
And then you want to explain to them about our library?

325
00:35:03,350 --> 00:35:04,290
Yes.

326
00:35:04,290 --> 00:35:10,810
The Interplanetary Networking SIG library was put together by the Technical Documentation Working Group.

327
00:35:10,810 --> 00:35:15,850
It is there to make all this information as readily available to you as possible.

328
00:35:16,390 --> 00:35:22,870
And in this library, we have information about the progress of the Solar System Internet Initiative.

329
00:35:22,870 --> 00:35:29,830
We have details of specific implementations and some of the crazy cool stuff that these protocols are being used for.

330
00:35:31,190 --> 00:35:37,370
It's really easy to go down a rabbit hole here because it's, it's absolutely wild.

331
00:35:37,770 --> 00:35:38,410
Yep.

332
00:35:38,410 --> 00:35:51,590
But we did try to tag the library to help people that are newer in this area or people that really just want to focus on implementation of delay and disruption-tolerant networking.

333
00:35:51,810 --> 00:35:55,810
So on the left-hand side, you'll see that there's a little tag area at the bottom.

334
00:35:55,810 --> 00:35:57,510
And if you don't see it, drag it up.

335
00:35:57,510 --> 00:35:59,390
It's just out of your view.

336
00:35:59,690 --> 00:36:06,730
And you'll see the history of DTN, then submission to bring DTN for beginners.

337
00:36:06,730 --> 00:36:10,350
There are some really great resources here.

338
00:36:10,350 --> 00:36:21,090
We also, since some people are more familiar and comfortable with a directory structure, with folders, we have folders and these items are in a folder display.

339
00:36:21,630 --> 00:36:24,470
So this is a great resource.

340
00:36:24,470 --> 00:36:33,130
And one of the cool things about it is that in this group, you're going to see, let me get back here to our main page.

341
00:36:33,130 --> 00:36:34,350
That's Scott Burley.

342
00:36:34,350 --> 00:36:37,590
He's the head of our Technical Documentation Working Group.

343
00:36:37,590 --> 00:36:41,250
So we've been very fortunate to work with Scott on this.

344
00:36:41,250 --> 00:36:43,050
You'll also see Henry Danielson.

345
00:36:43,050 --> 00:36:50,430
He's the one that got us involved in DEF CON to bring in Wireshark analysis of bundle protocol.

346
00:36:50,690 --> 00:36:51,030
So...

347
00:36:51,030 --> 00:36:51,730
Thanks, Henry.

348
00:36:51,730 --> 00:36:53,110
Thanks, Henry.

349
00:36:54,350 --> 00:36:55,370
All right.

350
00:36:55,370 --> 00:36:59,410
Well, thanks much.

351
00:36:59,750 --> 00:37:00,310
And...

352
00:37:00,310 --> 00:37:00,670
All right.

353
00:37:00,670 --> 00:37:01,270
Thank you.

354
00:37:01,270 --> 00:37:02,850
See you in space.

355
00:37:03,230 --> 00:37:04,230
Ad Astra.