**Session Date/Time:** 20 Jul 2026 07:00

[00:00:11] **Speaker 0**: There's no mute button, is there?

[00:00:16] **Brian Sipos**: No. You don't

[00:00:17] **Edward Birrane**: have a mute button. No? No. How unfortunate. Clearly, when you whisper, is there a mute button? Then the people online say, no.

[00:00:30] **Rick Taylor**: We're time.

[00:00:30] **Edward Birrane**: Yep. Yep. 3AM. Let's go.

[00:00:32] **Rick Taylor**: Let's go. Are you in control of the slides?

[00:00:37] **Edward Birrane**: Yeah. I can go. So welcome as we open IETF 126 and the d t n working group. I would just ask if if someone near the door in the back could shut the door so we don't get a lot of noise otherwise coming in. Thank you. Okay. Well, let's get started. A couple of things in case this is anyone's first ITF, but it's good to go over cause it is the first day of the work of of IETF. Please understand that by participating in the IETF, you agree to follow all of our processes and policies. If you have not looked at these or if you're not familiar with them, do please take a moment and yourself with them. I'll leave it here just for a second. A a couple of particular things for those both in person and remote. Number one, this session is being recorded and will be made available particularly on YouTube. If you are in person, please make sure that you sign in via the data tracker or using the QR code that's outside for this session. And if you are going to come to the microphone, and, of course, we are going to encourage that because this is a working group, please both say who you are and make sure that you join the queue so that we, as chairs, understand that that you are here and have questions. Similarly, if you are participating remotely, please make sure that your audio and video are off unless you are presenting just to help save with some bandwidth. We have not really had issues with this, but we have conduct guidelines. We are going to have a lot of interesting technical discussion. We should be hard on problems and easy on ourselves. So please be respectful as we talk through any of the things we need to talk through. There are a variety of resources. If you have found this room, you know how to look up the resources as to where things are. Alright. A few things. We do have a shared notepad that's integrated. My request is that as many people as possible join that. We do have pretty good AI tools that help make summaries, but people are are still needed, and we would we would encourage it.

[00:02:44] **Rick Taylor**: And one of the critical reasons for joining is as people say their names very rapidly, Adam, is the group secretary who does a pretty good job of recording the the bulk of the notes, can just guess how to spell your name. And if you'd like it spelled correctly in the minutes, that's your chance to get it right.

[00:03:02] **Edward Birrane**: Absolutely. Okay. We have two sessions. Of course, this is the longer one at two hours, and then we have another session on Thursday. The agenda for session one has been crafted in a particular way. It administrivia is what we're going over right now, and then we have a series of presentations. Historically, and those who have been at the working group, particularly recently know that we are tend to run short on time as we get into the discussions. So we have tried to create a experience over this week between Monday and Thursday where we're not gonna be so constrained, and we should feel, the ability to have the discussion. And so what we wanna do is we wanna use roughly the first hour of this working group time to go through the presentations, bookmark where possible the significant discussion issues, and then come back in the remaining fifty minutes of open mic to make sure that we can go through and have the discussions that we want otherwise. And we're gonna try and keep to the schedule of presentations because we have remote presenters who will be joining at a particular time, so we wanna keep the first half of the schedule open. But, otherwise, that's where we are. Are there any agenda bashes, anything we want to talk about or make sure is represented otherwise before we get started? Alright. So with that, let's start with our very first presentation, which is an update on CoAP over BP. And, Carlos, would you like to present the slides yourself?

[00:04:32] **Carlos Gomez**: Azu, whichever is easier for you.

[00:04:34] **Speaker 0**: Go go ahead. What?

[00:04:37] **Rick Taylor**: I was gonna say, give give Carlos the slides. He he knows what he's doing.

[00:04:40] **Ben Roberts**: Yes, please.

[00:04:44] **Speaker 0**: Let's see.

[00:04:45] **Rick Taylor**: We don't know what we're doing.

[00:04:46] **Edward Birrane**: Test slide control.

[00:04:47] **Rick Taylor**: There we go.

[00:04:48] **Edward Birrane**: There we go. You should have control. Yeah.

[00:04:55] **Carlos Gomez**: Okay. Okay. Good morning, everyone. My name is Carlos Gomez. I'm going to present, the first of the draft entitled Constrained Application Protocol (CoAP) over a bundle protocol. My co author is Ana Cavilles, and we are both from UPC. On the status of the draft, today, I'm presenting revision zero four, which aims to address a review from Marco Davids. Many thanks, Marco, for all the comments, and we also aim to address comments from the last meeting. Also, there is one related note here, which is that the actual updates are already in version zero three. But then right after submission of zero three, we realized there was an issue with the figure with a line that was too long that rendered the the diff quite useless, so we submitted zero four with a fix for issue. And another point on the status is that the co working group chairs have explained to us that they plan to declare later in the week in the co working group session that this version I'm presenting today in zero four is stable to implement. Then about the table of contents, you may notice that there have been a few changes. Basically, it's changing the order of a few of the sections, which are the security considerations, IANA considerations, and acknowledgments. And now the order should be correct and according to RFC seventy three twenty two. Otherwise, the main structure is stable, and only there have been updates, in the content of these sections, in some part of the security considerations as I will, present later. So, some of the updates in zone four are in section five, which discusses the bundle that encapsulates a CoAP message. Previously, we had a parameter called the max maximum aggregation delay, which is the maximum amount of time during which a CoAP entity, can be aggregating single individual messages into a larger aggregate message. And here, we have clarified that the value of this parameter is independent of whether those individual messages are of con or non type. You may recall that con messages are core messages that elicit an acknowledgment from the destination endpoint, whereas nonconfirmable do not elicit acknowledgments. Then, in section 13, security considerations, we also have an update. We already explained previously that there is one risk, related with the payload length option, which every individual message in an aggregate message needs needs to carry. The payload length option is a class u for OSCORE, which means unprotected, and that means that an attacker might infer features of the communication based on the payload size of the messages. So we already described a few solutions, to this problem. One would be not using the payload length option at all, but then there would be no aggregation functionality. Another one would be adding padding, by using the new CoAP padding option before OScore protection is applied. Another one would be using lower layer securities, such as VPSEC. And, what we have added this time is that there's another approach, which is, using OScore hub by hub. So OSCORE provides object security to protect application layer messages, in this case, messages, and it's intended to be applied at the source of the message. And then, this protects the message all the way until the final end destination, even if in the middle, there are, proxies which might be entrusted. But now there is a working group document in the co working group, which, has introduced as well the concept of OSCORE capable proxies. And and this means that now, such proxies are able to apply a layer of OSCORE protection as well. So now it is possible to have a OSCORE hop by hop meeting from the actual source CoAP endpoint until the next OSCORE capable proxy or between OSCORE capable proxies or from, OSCORE capable proxy and the final CoAP destination endpoint. So, with this functionality, a class u option can be promoted to class e, which means, protection with encryption and integrity. So if this scenario is in place, this is another way in case it is possible to protect the period length information in this option. Then we have applied several minor improvements throughout the document. Some of them are technical. Some of them are clarifications aiming to use language a bit more accurately. One example is that in some instances, we have replay replaced response with reply because response has a specific meaning in the context of CoAP. Response is generated by the upper sub layer of CoAP. However, reply is more general, and it some replies might be produced by the lower sublayer of CoAP. And we've also applied several editorial improvements, trying to fix typos, language issues, and so on. We've also added forward references, to some sections in the document, and we've also made text references to sections, figures, and actual references, hyperlinks, trying to, make the experience of the reader easier. And, yeah, as we already stated, in the last meeting, we believe that the document, may be approaching a state where we may want to request a working group last call. And related with that is the comment that I made at the beginning that the chairs of the coworking group plan to declare later this week that, version zero four is stable to implement. And in the meantime, reviews and implementation feedback would be very much welcome. So, that was everything from my side. I don't know if there may be any comments or questions.

[00:11:03] **Edward Birrane**: I I I have one, which is I I think it is, all continues to be excellent work, and I'm I'm very glad to hear that we, believe that this will be tagged as stable to implement. Do you see a benefit in waiting for an initial implementation before going into working group last call, or do you think that we should entertain that in parallel?

[00:11:24] **Carlos Gomez**: Well, we have already our own implementation from UPC.

[00:11:29] **Edward Birrane**: Yeah.

[00:11:30] **Carlos Gomez**: So that is already available, and it's I should double check whether because it's based on a previous version of the draft, what would be the the updates needed to to be, like, conforming to the latest version. But, yeah, we we do have already our initial implementation, and then it would be great if there could be, like, other implementations and perhaps try to see if there's, interoperability between them.

[00:12:00] **Edward Birrane**: Sure. And and that would be my request. Is it once you've made that that, determination that the implementation is completely conformant to the latest version of the draft, putting that out on the d t n mailing list would be good information, and then we can take it to the mailing list.

[00:12:15] **Carlos Gomez**: Perfect. Yes. We'll do that.

[00:12:16] **Rick Taylor**: Okay. First off, I love this stuff. I have a very specific question about the use of .dtn.arpa as part of the URI scheme support within CoAP. I think .ipn. Seems to be reaching some kind of consensus as that's the way to go. I'm very wary about introducing dot d t n dot ARPA into this document because speaking frankly, I'm not sure this working group really knows what a dtn EID is beyond the description in r c 9171. I'm not sure anyone's actually deploying dtn EIDs in any particular way, and their interaction with DNS names as a whole is a bit of an open question. So I'm a little wary of this document introducing just as a passing comment. Oh, there will be a dot d t n dot arpa. And I'm I'm not sure anyone's spoken to the DNS gods about whether that's viable. And I know it's not resolvable, but once the name starts to exist, it seems to take a sort of de facto, oh, well, of course, it exists, and we must do something with it. So it's just a little question about that DNS aspect. I'm not sure. I don't want to slow down this document, so I wonder whether actually removing reference to dtn.arpa is a way to make progress without stalling the whole document.

[00:13:55] **Carlos Gomez**: Okay. So, yes, that may will be an approach to to follow. I'm not sure if would you consider also contacting people from the DNS area? Or

[00:14:08] **Rick Taylor**: Yes. Yeah. Okay. So there's there's part of an ongoing wider conversation about

[00:14:14] **Brian Sipos**: how

[00:14:15] **Rick Taylor**: much d t n and bundle protocol interacts with DNS, what sort of names and shapes of names and RR types, etcetera, etcetera is involved. I'll take this comment to the mailing list because I think it's a technical comment. But I think there are let me review that section and give you some proper feedback on it is the short answer.

[00:14:35] **Edward Birrane**: My my follow on question would would would simply be if if there was an ipn.arpa instead of a dtn. ARPA, does that

[00:14:42] **Rick Taylor**: No. No. This covers both. In the document at the moment, he happily talks about ipn.arpa, which is great. No. I don't think anyone's got an issue with that. It's but it also mentions ADotDTNDotARPA. And it's that second one.

[00:14:54] **Edward Birrane**: If if it restricts, is there anything technically that's different in in this protocol?

[00:15:01] **Carlos Gomez**: Oh, yeah. I understand there would be no no difference. Yeah.

[00:15:06] **Rick Taylor**: Yeah. It's it's just a naming method.

[00:15:09] **Edward Birrane**: Yeah. Okay. Thank you for that. Sorry. Any other any other questions?

[00:15:19] **Speaker 0**: Nope. Alright. Cool. Thank you so much.

[00:15:22] **Carlos Gomez**: Thank you very much.

[00:15:27] **Edward Birrane**: K. Next up on the agenda are two individual documents from Brian's CPOS related to BPSEC and a d t n manifest block. Brian, same question to you. Would you like control of the slides?

[00:15:42] **Brian Sipos**: Yes, please.

[00:15:43] **Edward Birrane**: Okay. So granted.

[00:15:49] **Brian Sipos**: I'll try to stick the time, hopefully, since there's slack in the schedule. Yeah. Exactly. Problems here. Alright. Thank you for the time, and I'm gonna be talking now about individual drafts that have had some work on them. And I'm requesting just feedback on or advice on or any anybody that wants to do trial implementations of these things. The first one is the most recent of the individual drafts, which is this concept of a block manifest block. And the idea here is that there are use cases explained in the document that I'm not gonna get into here, but the general concept is it's a way to kind of thumbprint what did parts of a bundle look like at some point of time so that later on, a verifier of the manifest can do something about it. And at least one specific use case has been identified in support of that secure VP audit mechanism, S-PAM, and this allows them to not have to invent either a new block type or any kind of security processing, which is helpful on their side. But there are a couple of other use cases that are identified in this draft so far. So if there are any tweaks or comments about the use cases, that's very helpful now. And, also, if anybody has another use case at all, that's useful to identify now. One of the use cases that is currently in as a a kind of a forward looking mechanism speculative sort of mechanism is the notion of being able to mark certain content as it needs to be preserved. And this is in the in the the realm of something like a transit network where somebody else is giving me data. I'm moving it around to from one user net to another user net, and this marking is supposed to be what has to be preserved. And if it's not in the manifest, I can either ignore it or I can throw it away because the user doesn't care. So it's it's in the realm of a kind of a quality of service type thing. And it's also for the perspective of the user, it's our dual purposes because it's where to communicate to the transit network, here are things that matter, and you should either enforce what I'm asking or you should throw this away. And the other is on the far side user, it gives them the ability to verify in a security coverage sense the things that went in are the same as the things that came out. And the point of the manifest is that it's a a two layer kind of summary that it's saying, here's what's supposed to be here. Here's the hash of that thing that was supposed to be there, And, you can verify the manifest in a separate step, then you can verify the hashes. So it allows a certain kind of chain of custody of the data. The differences between version zero and version one are really about the encoding structure. There were some feedback, sort of tangential to this that was recommending, not to hinge any internal processing on things like, the CBOR map encoding order, which is a reasonable thing to do. And the the users here didn't really care about whether the the structure of the data in particular, so it was split out so that there's a separate purpose code. There's a separate block identity from the the metadata map and the the block data map. So it's the same information, slightly different data structure, but not a change in in, the higher level behavior. And then the other thing, we've got feedback from the S-PAM folks about adding, some kind of key identifier to the security block processing. This needs some feedback. It needs some work on it, but, that addition was made. So at least we have something to talk about. Then, do we wanna cover questions now on the individual? Your choice. Your choice. Go ahead. Yeah. Go ahead.

[00:20:11] **Rick Taylor**: If we allow

[00:20:12] **Brian Sipos**: to run over.

[00:20:13] **Edward Birrane**: No. Fair enough. Thank you. And, actually, you may have addressed already that. That was gonna be my question is, are you working with the people working on S-PAM? And other than the key identifier, are you in agreement on the the fields and the behavior of this block? Yes.

[00:20:29] **Rick Taylor**: Yeah.

[00:20:30] **Brian Sipos**: Thank you. So, Brian,

[00:20:33] **Rick Taylor**: I I I may have another use case, and I'll reach out offline about a potential use case because it's it's some future work I'm trying to work my way through. My question is, as I was thinking about the manifest block, I think there's some value in putting some indicator in the primary block, and I'm thinking a flag here to say this bundle has a manifest block so that you can detect the the the man in the middle who not only strips out blocks, but also strips out the manifest block so you don't even know there was a manifest block in the first place. It it makes sense to me, given the primary block is immutable, that's the putting a flag in there to say there will be a manifest block makes sense. Is that I haven't read o one. I apologize. Have you included that? Do you how do you feel about including that?

[00:21:32] **Brian Sipos**: It's not currently. And for something like this, I I think that it to me, it makes more sense to enforce something like that through negotiated configuration of policy than, like, in band signaling only because anything that's in band is still vulnerable to somebody manipulating it. Meaning, if if you demand to it's a general it's a more general question than just for this specific lock type, but it's a question of if you if you need something to be there, then that needs to be negotiated out of band in some sense and enforced through policy versus making it discretionary on the data itself. Yeah.

[00:22:28] **Rick Taylor**: I I I do take your point. I'm just thinking about how the IETF normally kinda handles these things where we normally say, look. This is normally configured by some out of band process, but there is also an in band mechanism if you're, say, within a trusted administrative domain, meaning you don't have to have a glorified configuration manager that synchronizes everyone's config to make sure that change got through.

[00:22:54] **Brian Sipos**: I don't think it would be harmful, but we'd have to talk about what the necessarily what the value is and what happens if there's a discrepancy. What does that imply?

[00:23:04] **Edward Birrane**: And and I think that's good mailing list spotter.

[00:23:06] **Rick Taylor**: Yep. Yeah. Mailing list. I'll take it there. Okay.

[00:23:09] **Edward Birrane**: And, Brian, I'm sorry just to continue on this. One additional question to help me with my mental model for this block. Is this meant to be a manifest of the blocks that existed in a bundle at the source, or is this meant to be a listing of the blocks that are expected to be in a bundle at the destination or something else?

[00:23:31] **Brian Sipos**: The the current definition is it's a selected subset of the blocks at the time that the manifest was added. So it's think of it as taking it taking a a Polaroid snapshot of Yeah. The bundle, and then later on down the line, comparing the picture that you took to the the actual. What that allows for, though, is it allows for saying things like, don't include the previous node in the manifest because it doesn't matter. It's it's gonna be useless.

[00:24:02] **Edward Birrane**: I definitely agree with that. Would you then presuppose that a bundle could have multiple manifest blocks in it?

[00:24:09] **Brian Sipos**: Yes. There's no reason why there's no technical reason why that would be a problem.

[00:24:15] **Edward Birrane**: Okay. Okay. Thank you.

[00:24:17] **Rick Taylor**: Yeah. And and that makes the that makes the primary block flag complex because

[00:24:23] **Edward Birrane**: Mhmm.

[00:24:23] **Carlos Gomez**: Yeah.

[00:24:24] **Rick Taylor**: How many doesn't indicate how many. It just indicates presence and should only be added at source, meaning a man in the middle can't add a manifest bot. Okay.

[00:24:33] **Speaker 0**: Thank you. There's a discussion around this. There's a whole discussion there.

[00:24:36] **Edward Birrane**: Thank you, Brian. Sorry for the distraction.

[00:24:37] **Brian Sipos**: Yep. That's that's fine. So that's it for the manifest. It's worth there's some things that are worth discussing. The next thing I wanna review is the content and the the the purpose of the security associations with your exchanges safe draft. And I'm not gonna dig into a lot of technical details, but I did include some slides that give summary information that I'm gonna kinda go through quickly. So within the working group charter, there are topics of OEM and key management, and I believe this does fall fall under the key management umbrella. And I do wanna call out specifically that key management as a as an umbrella topic covers a lot of different possible things. There's key distribution. There's credential management. There's key derivation and delegation behaviors. Key agreement, which is really what's gonna be discussed here. And then there's key upkeep, which is kind of a follow on concept to a lot of these things. And this document is intentionally not covering the topics of key distribution, of credential management, of delegation of authority. Those those are topics worth discussing. They're not what is covered here, and they're also things that are covered elsewhere. And right now, this is still an early individual draft. It is, I believe, technically complete. It's something that has had a trial implementation that has enough enough, definition to to work out the details and to to be able to raise questions about the encodings and and the data structures and all that stuff. So I think it's technically strong enough to to be discussed at that level. But the use cases need some discussion, and I'm sure there's technical details that are worth talking about. One notable aspect of this is that the initialization, which is the first messaging between peers, makes use of a femoral defy Hellman over a COSE, EDHOC, which is an existing RFC out of the, the Cozy working group or I'm sorry, the Lake working group. And that enables this mechanism to, later on, I'll talk about inherit some future gains that are in the pipeline. And one thing that is, I think, unique to this kind of mechanism and the reason why this was written up in the whole first place was that it allows a kind of a a unilateral rekeying, meaning the owner of one of these content keys, these symmetric content keys, is able to say, at any time they choose, I'm done with this. I've used this on enough data or it's been enough time or whatever reason I want to discontinue this key and start using a a subsequent one, they can declare that happening and everything just works. So there's no negotiation of rekeying like what happens in, other protocols like Ike v two or, I think, how some of the loss score operates. There haven't been recent updates to the documents, so I'm I'm just explaining this in summary, and soliciting feedback. But, the the few use cases that are identified here, the ones that are the easiest to understand are the end to end security, which is the top picture where at the source, you you you want to apply data plane security, and at the destination just before delivery, you want to accept it. So that's an easy mechanism to understand. The other one that's a little more complex, but still, I think, easy to understand is the one hop transport security. And the idea here is that just before forwarding, you want to source you wanna put some security in the data plane. And just, during reception, processing, you want to accept it. And so this idea is to supplement, for, unify security that's would that would be provided by an underlayer. That might mean that the underlayer is not doing anything. It might mean the underlayer is doing things for its purposes, but it doesn't know what an, VPE ID is, and so it can't do things like, authenticate your, previous hop. So that's the point of something like this is let the the terminal and the underlayer do its business, but also at the VP node, don't accept traffic that you don't authenticate from the the previous node. Then there's two other use cases that are left well defined but are still at least worth covering even if they are carved out as saying we don't support these things, and that is a multi hub security because that gets into questions of how much you control routing behavior and how much you know about routing path. And the other one is tunnel security, which is really related to something like Bundle-in-Bundle Encapsulation, which I know Rick's gonna be talking about later. But the TBD here are just the fact that, we don't have a specific mechanism or detailed configuration to be able to point to and say, here's exactly what is meant here. But these two use cases are carved out of saying, by the way, at the current state, these are worth these are worth noting because they're different than the first two. They're not the same. I'm gonna really quickly go through the fact that this document does call out information basis so that the the processing of each of these entities is understood. And the the main split is that there are primary security associations, which means how do these two safe endpoints communicate with each other, which is necessary but not really, not really beneficial to the end nodes. Safe is just a a means to get to the secondary security associations, which are what are the data flows at a block level granularity that, BP SEC is meant to cover. So that's really the whole point of this thing is to negotiate and establish and upkeep these secondary security associations, which is which is related to existing BP sec policy and configuration of saying this exact flow between this source, this destination has certain characteristics, and it needs certain security. So that's the meat of what this whole draft is meant to expose. And so that's where I think feedback I'll talk about it in a bit. The feedback is really needed not just on the safe mechanism, but also on the secondary security association configuration of what parameters are are worthwhile to have here. I'll briefly say that there's there is a a a sublayered message structure in here that is meant to separate concerns, but different aspects of the protocol are are operating kinda independently. And it's nothing new or shouldn't be anything surprising because there's a lot of similarities with existing protocols, and they're called out here. But, the idea is that all these sync messages have confidentiality guarantees. They allow pipelining of of, activities, and, the activities themselves are are well defined. They're very short. Some of them necessarily are let's skip ahead to the next slide. Some of them are sorry. Some of them are, multistep about simple negotiations, but some of them are single step just in in terms of I'm expressing a thing that's happening and the acknowledgment is, yes. I know you're doing a thing. And then on the last slide, it's just the solicitation for, getting feedback on this. And and the thing I wanted to say about the, EDHOC is that there's ongoing work, and it's gonna be discussed, later this week at the IATF about how, Pokemon crypto is gonna be integrated into EDHOC. And this is a matter of, when, not if, and and how. So this is something that we'll be able to take gains for free in some sense when that working group works things out.

[00:33:18] **Rick Taylor**: Brian, good stuff. Quick question with chair hat on. Are you working asking for adoption of this document yet or still noodling on it while, like

[00:33:28] **Brian Sipos**: If if there's interest, I I'm not opposed to it. It still is at the point where it would be good to figure out how much interest there is.

[00:33:38] **Rick Taylor**: Yep. Okay. The second question, I'm assuming this is forward compatible with the COSE context, so the key material is pretty generic. I see

[00:33:48] **Brian Sipos**: It is. Yeah. Most symptoms. So Yeah. There is there's subsections in here that explain the need for key material is specific to the context. Each context is gonna have different needs.

[00:34:00] **Rick Taylor**: Yep.

[00:34:00] **Brian Sipos**: But there is a call out right now for the two default context and the COSE context as a starting point.

[00:34:06] **Rick Taylor**: Okay. The chair hat off. I will be looking at this at some depth and see whether I can roll up an implementation. I think this is really good stuff. Eric, I see you in the queue.

[00:34:17] **Speaker 0**: Oh, yeah. Sorry. Thank you. I did have a I did have a a quick read of this, and and thanks for your clarification, Brian, on the mailing list. For for me, I think this is this feels like a kinda like an IKEv2 Yeah. For for VP sec and and and something we should have. So I would I would support adoption.

[00:34:34] **Brian Sipos**: Oh, great. Thank you. Or or yep.

[00:34:36] **Speaker 0**: Yep. Adoption call, etcetera.

[00:34:38] **Edward Birrane**: Yep. I just to chime in at the end, I completely agree, Brian. This is really good work. My request is if you could make the the the request on the list for us, and then we will kick off a working group adoption call. To take a moment, for for anyone who is familiar with this work and just while we are here together in the room, does anyone have any comment or concern where we should not yet consider this for adoption?

[00:35:07] **Speaker 0**: Alright. Thank you so much.

[00:35:11] **Edward Birrane**: K. And with that, we will have two presentations by Rick, one for the echo service and then separately for considerations on Bundle-in-Bundle Encapsulation. Rick, do you want me to drive slides?

[00:35:27] **Rick Taylor**: Yes. Unless this Flickr works.

[00:35:29] **Edward Birrane**: Oh, let's see. Let me

[00:35:30] **Rick Taylor**: get this. To try this.

[00:35:33] **Speaker 0**: Echo service.

[00:35:36] **Rick Taylor**: I'm gonna

[00:35:37] **Edward Birrane**: see what Let me pass control to the clicker.

[00:35:40] **Rick Taylor**: Oh. Oh. Oh. Alright. Did something happen? Yes.

[00:35:45] **Speaker 0**: Yes.

[00:35:45] **Rick Taylor**: Excellent. Something happened. Hello. I'm Rick. This is off because this is a a personal draft. So echo service. So I have recently updated to version one of the BP echo service. So for those of you who were unfamiliar with the previous echo service draft, the intention is to standardize how on earth you ping something over over bundle protocol. It's a fundamentally important thing to do. This came out of our work on uD3TN to make sure that we could actually interoperate at the most primitive level with all the other implementations out there. And in order to do that, step one is can I ping it? And I realized during that work, there is no standardized way to define what service to use for a ping, what are the expected behaviors at a very limited level. Version zero zero had lots of comp it was overengineered, and I will happily admit it. And I got very good constructive feedback from a number of people to say, this is a massively overengineered solution. It had a whole lot of thou shalt reflect nonstandard behaviors, etcetera. I've taken that on board, and version o one is much, much more standard. It makes a lot more sense in terms of an IETF document. And bullet three here, the headline is the echo service is now a box standard request and response wire contract. It's not some magic reflector, etcetera. And the document is now entirely structured around what a request should look like and what the echo service as a responder should respond with. It is entirely silent on how one creates these things, what your ping tool looks like. If it's a dedicated tool, is it some background task, is it whatever? It doesn't matter. That's not part of the document. The document talks entirely about the role of the service that echo that responds to your request. So first off, it interoperates. What we've got working now, I have managed to get to work quite happily between Hardy, d t n seven r s, HDTN, dtn- me, ION, u micro d three t n, the ESA BP implementation, and NASA's CFS b p node. So that's a pretty good the only people I haven't done is Unibo, and I'm really sorry. I just haven't had the bandwidth, and I'm very confident it will work with theirs as well having looked at it. So, yeah, this is either using their in house echo service, using their Python API, using whatever, and a little bit of client code, thank you, to build out really primitive services that follow this implementation, and it all just works. Having done that, o one is now a write up of of what's involved. Of course, all the hand rolled and preexisting services implemented by all these implementations, people just picked a number because there was no standard service number registered or or put forwards by the IETF. Some use most use 7 because it chimes with the ICMP UDP port seven registration. Others use 2047 because it sounds cool. You'll have to ask the DTNME guys why they chose that number. It's fine. Others use random configurable values, none of which are registerable. Why the reflector had to go? Fundamentally, it wasn't standard with ninety one seventy one. It was actually incompatible. It described a behavior that was not what a normal ninety one seventy one b p v seven service should do. It talked about the BPA doing clever stuff and hot swapping out values in the header and shoving it straight back out to CLA. And it it just sure. My implementation could do it because that's the way I wrote it, but it it just it wasn't a good plan. So I'm very happy to go into more depth. Grab me afterwards, and we can talk about that. The main terminology of the document now is a request is received, a new bundle is created as a response, and here are the rules on what you set in that bundle. And the short answer here we go. It's an independently sourced bundle. So the receiving service should create a new response bundle with rules about creation type of stamp. I it's fresh because you don't get to fiddle with the creation time stamp. That's absolutely defined in 9171. Lifetime, there are some recommendations about what you should do with Lifetime, but it's absolutely standard. Basically, go read the draft about the full details about what all these different fields do, but they are the critical fields that you need to understand as a service on how you set that up to reply. Key points. These are not admin records, so don't get turning on admin record flags. Don't get turning on the I require a request act because nobody knows what that is, and you are a response anyway, so don't turn that on. You there's some advice in there on what you should do with status reporting. The reason being that the tool that is generating these requests might be trying to do something intelligent with status reports in order to to create some kind of useful information to the user. So there's some recommendation in there that you should probably mirror the flags you saw for the status reporting because it could be useful. And the most critical piece is the payload should be preserved exactly. And this mirrors IP ping where the source tool puts something it is interested in getting back in the payload with the expectation that it comes back identically so that it can start doing its stats and checks and whatever. So the responding service should absolutely not touch touch the payload, and this is the only bit that remains from it's a reflection. So you reflect the payload, but it's a brand new bundle because that's normal b p v seven behavior. We include rules about when not to respond because it's important to realize when one shouldn't. Null source makes no sense. Don't respond. Admin records, no. Don't do that. That's that's also a stupid thing to do, but we have to explicitly say that. And only respond once. Don't start trying to do sort of helpful retries and that kind of thing. It just it just breaks stuff. These are just useful rules to have into the into the documents so that we get consistent behavior between interoperable implementations. There is no obligation to do anything with extension blocks or security. Bpsec works like bpsec does. If you wanna put bpsec on your on your request, that's fine. It should follow the normal BPSEC processing that you have configured and the policies you have in place. If you put extension blocks in, I mean, beyond the normal hop count, bundle age blocks and previous node blocks, if you're putting funky extra stuff in there, don't expect to get them back unless you've got some out of band configuration which causes that to happen. But a standard behavior should be, I don't care about that extension block. I'm gonna respond with an absolutely normal bundle. There there's a little bit of information about why some of these things have been removed. Go read the document for for more information. There's an amplification attack that we're trying to avoid here by by managing some of the b p sec information. In draft zero zero, I got overexcited and wrote a a survey of everyone's format for their payload block and tried to produce a nice seabore encoding of, well, most people like a timestamp, but most people like a bit of this, most people like a padding, all those good things that you would have. It was pointed out to me, and I realized it as well, that actually this doesn't need to be defined. The payload block information is actually private to the ping tool that created the request as long as the response includes it unaffected. So there is now some non normative text in the appendix with some suggestions for what a ping tool should do. That's the ping client guidance. I if you wanna do round trip time statistics and you wanna do status report interpretation, here is some advice based on what pretty much everyone does and sort of industry best practice. It's not normative. It's advice, and there is therefore no standard payload format. Just some you probably want a timestamp advice. The other thing I did is I simplified the ION registration request. So the draft zero zero, I went and asked for a DTN service name. I thought echo demux or dot well known echo demux or something like that would be a really useful thing to have on within the DTN EID scheme. But it occurred to me that fundamentally, we don't really know what a dtn eid actually is. There's lots of open questions. The existing well known services registry that came out in the IP and update RFC didn't include any capability for DTN EIDs. It only specified IP and EIDs. And rather than try and cram a whole bunch of, oh, here's some well known EIDs for DTN and start to touch on DTN EID formats into a document about ping echo responses. I have left all that out and said simply, I would like an IPN service number. I'd like one two eight, which is the lowest public reservable IPN IPN service number, and that's the only thing in the IANA questions. I have a working document. It's not even a draft. I haven't published it, where I have put all the text I ripped out, and I'm going to noodle on that and possibly roll it into a bit more of a discussion about GTN. I'll talk about that another day. Yeah. Can we have a look at it, please? So I think it's now in a fit state. I can't see much else that needs to change except editorial changes, typographic changes. Please have a look at it. And I would like working group adoption on this even if it is just to reserve a well known number because it seems an omission on our behalf not to have a well known PIN number. Doesn't mean you can't use seven on your own implementations, but it'd be nice to have a standard. Don't worry about the DTN scheme demote stuff. Just forget about that until next IETF when I hopefully will get it done.

[00:46:12] **Edward Birrane**: We we do have a few people in the queue already.

[00:46:15] **Rick Taylor**: Okay. I'll

[00:46:15] **Speaker 0**: show them.

[00:46:16] **Edward Birrane**: So I I just in order, it's me then Brian, and then Scott here at the at the mic. My my only comment on this was, at least in some security considerations part of the document, we should note that adding extension blocks into something like a ping request is going to allow people to probe the capabilities of the network.

[00:46:39] **Rick Taylor**: Yes.

[00:46:39] **Edward Birrane**: And you could certainly imagine different integrity signatures with different contacts or age blocks or other things. And so my initial thought was this would have most utility if no extension blocks were allowed. That's possibly too draconian. But I I would just ask that you put some sort of security consideration that if you add extension blocks to this kind of ping request, the fact that you would get a response back tells you something about the processing ability related to those extension blocks for the BPA that is responding to you, and that may be something you don't wanna tell the world.

[00:47:12] **Rick Taylor**: So yes. Please, everybody, look at the document. I think there might be some validity in expanding the initial sections to say, this is how one might use a ping like tool within a DTM. So it's slightly beyond security considerations. It's also about administrative considerations about whether you should not allow these things to leave your administrative domain because fundamentally, it's it's doing network probing. I wonder how much read across we can from the work in the other OAM working groups who have looked at the spread of these kind of tools. But, yeah, please. I I would love further critique pointing at lines in the draft.

[00:47:59] **Edward Birrane**: Brian?

[00:48:01] **Brian Sipos**: Yep. I think this is a good good state, and, technically, it's it's all good in there. Similar to what was mentioned previously is, I think, having an operational consideration section in there is is valuable to cover those topics that you were talking about and also to maybe get some guidance about things like, what level of granularity ought a BPA have when doing things like filtering. You know, what is expected? Is it an on off switch or is it something more fine grained? So this is not a technical question. It's it's a what would you expect it how it it is meant to be used?

[00:48:40] **Rick Taylor**: I welcome contribution from the wider community to make sure we get that correct because otherwise, it's just my opinion.

[00:48:48] **Carlos Gomez**: Scott?

[00:48:50] **Scott Burleigh**: Scott Burleigh. That's b u r l e I g h. Just just just to help out. And this is just a comment, and I I would have to reread the document to I may have just missed it somewhere, but I would propose it it would be a good idea to exclude, pings that are from a null source.

[00:49:16] **Rick Taylor**: It's it's explicitly excluded.

[00:49:17] **Scott Burleigh**: It's just okay.

[00:49:18] **Rick Taylor**: Yeah. Because it make you can't respond to it.

[00:49:20] **Scott Burleigh**: Right. You can't respond to it. I it's what the nightmare scenario that I was thinking of is the ping comes from a null source and the report to is an IMC

[00:49:30] **Rick Taylor**: Yeah.

[00:49:31] **Scott Burleigh**: Endpoint, and now you've got an a DOS attack.

[00:49:34] **Rick Taylor**: Yeah. That's explicitly called out in the security section. Yeah. Hit that one. So yeah. But that's why I need better review just to make sure I got got them all.

[00:49:44] **Speaker 0**: Yeah. I would I would say it's not just administrative. It's operational. It's it's operational use. And so you might want to probe the ability of processing for certain things. Right? And so it's certainly worth a a possible mention in security considerations, but also in the operational considerations section. So chair hat on because ICMP ping is, like, a pretty standard operational tool. Right? Yep. So

[00:50:11] **Rick Taylor**: Chair hat on. It sounds like this has a rough approval in the room, so I I will ask for working group adoption formally

[00:50:21] **Speaker 0**: on the list. Separately, on the on the topic of the of the format, I think that is richer context is better left for separate protocols. IBPM has stamp and, like, one way and two way measurement protocol stuff. There's a whole bunch of things to standardize.

[00:50:37] **Rick Taylor**: And that's why I kind of put in the appendix, here are some things you might, but it's entirely non normative. So you you can later work in this group or elsewhere can define exciting payload formats that do exciting things.

[00:50:51] **Speaker 0**: Well, if you want the payload to be modified, then I think that

[00:50:59] **Rick Taylor**: You if for this

[00:51:01] **Speaker 0**: You don't want this you definitely don't want that for this.

[00:51:03] **Rick Taylor**: Right? Absolutely. It should not be modified.

[00:51:04] **Speaker 0**: But for measurement, for other measurement protocols, you want the response to be modified. You should opt it in some way. Right?

[00:51:09] **Rick Taylor**: Think that's a

[00:51:10] **Speaker 0**: different service. That's a different protocol. Yeah. That's yeah.

[00:51:12] **Rick Taylor**: Yeah. Yeah. That's not the echo service because I've tried to keep this as very, very simple. This is the

[00:51:18] **Speaker 0**: first thing you implement when you're trying to interoperate. VP iPerf three.

[00:51:22] **Rick Taylor**: Yeah. Yeah. Coming soon.

[00:51:24] **Edward Birrane**: So send them an EU. Just a a quick question again while we're in the room together or while we're online together. Is there any concern about whether we should adopt something like an echo service document? Alright. Thank you.

[00:51:42] **Speaker 0**: Okay. And next

[00:51:44] **Rick Taylor**: Is it me again? Yes.

[00:51:49] **Speaker 0**: Oh, Warren asked to share slides.

[00:51:59] **Rick Taylor**: Warren, you're asking to share slides.

[00:52:01] **Edward Birrane**: Oh. Yes.

[00:52:03] **Rick Taylor**: Put my

[00:52:04] **Susan Tan**: phone down. No.

[00:52:04] **Rick Taylor**: You put your phone down and offered to share slides.

[00:52:08] **Edward Birrane**: All the slots for the requested media have been taken. How do we stop sharing? Oh, there

[00:52:13] **Speaker 0**: we go. Okay.

[00:52:17] **Edward Birrane**: How do we stop the share?

[00:52:18] **Speaker 0**: Yeah. Oh, wait a minute. I think I I Yeah.

[00:52:21] **Rick Taylor**: No. We didn't click the button on this end. Sorry.

[00:52:25] **Edward Birrane**: I thought putting Rick one right after the other was gonna be simple. I guess I was wrong.

[00:52:31] **Rick Taylor**: Nothing involving me is simple or or straightforward.

[00:52:35] **Edward Birrane**: Speaking of sorry.

[00:52:37] **Rick Taylor**: Speaking of. Okay. So I imagine there will be much discussion around this topic, And so I will stick to the strict ten minutes. We'll then let everything else proceed, and we will come back to this because we have lots of room at the end. First off, I do not intend to be contentious here, although I know this is a contentious topic. So everybody be graceful and brief. So earlier this month, I put out a document entitled Bundle-in-Bundle Encapsulation. And the purpose of this document was to replace the existing Bundle-in-Bundle Encapsulation with custody transfer. And I'm going to talk about it in two parts. Step one is why did I do this? Because it seems an unusual thing to do. And part two is what's actually in it is the technical part. But I'm gonna do I'm gonna cover the why first. So first off, important point. I'm taking my chair hat off. This is a individual proposal. Ed is chairing this. Okay? So whatever happens with this document, this is Ed is the chair. So the question hanging in the room is why did I write a document about BIBE when there are a number of people who have actively worked on this for many years? And the simple answer is that we have to say something about the deprecation of fragmentation. So for those of you who are unaware, the ADU fragmentation mechanism described in 9171 does not work with bpsec. It will work on very specific use cases, but in general, it is not functional. So therefore, we have to be able to deprecate that. And in order to be able to deprecate it, we do in all due diligence have to be able to point to a solution for the reasons why you might want to take a big bundle and split it into small parts and to say, and here is a workable solution provided by the IETF to do that. That is the purpose. Second reason is the existing Bundle-in-Bundle Encapsulation document has expired twice. It's it's suffering from a slight lack of impetus from within the working group. There's been open questions for a long time about the custody transfer coupling that has caused it to stall a number of times. And, also, it's a working group document. So although it was worked on originally by Scott Burley and others and continued to be worked on by Scott, bandwidth has meant that he hasn't had sufficient time to work on it, but it's the working group's responsibility to do this because the working group adopted it. It's a little bit of IETF mechanics going there, but when a document is is adopted by the working group, it becomes the working groups. Traditionally, the authors who understand it keep going with it because it's it's they understand what's going on. But the the rules are it then it's up to the working group to fix. Also, good news, people are still trying to fix Bundle-in-Bundle Encapsulation and get a really good workable solution. Unfortunately, although many of the people working on it are attendees of this working group, they're doing the work in other areas which are possibly less visible to the general community. So I think it is very important that the IETF community, particularly as we need to address this ADU fragmentation, has visibility on what is happening. I'm go through this in a little bit more detail. So for those of you who are unaware about, ninety one seventy one ADU fragmentation, it's incompatible with BPSEC, and therefore, fragmentation and security are fundamentally mutually exclusive, which is not a good situation to be. We don't wanna say you can have security or fit your bundle down your limited contact window. Okay. CCSDS is currently absolutely understanding that this is a problem and is going all guns towards trying to fix this. Okay? Both us at the IETF and CCSDS understand that, therefore, we must deprecate ADU fragmentation. Okay? And I've kinda covered the the the the point about an IETF's we can't deprecate part of an IETF standard except through the release of another IETF standards track document which deprecates it. So that's the fundamental mechanism we must fix. The CCSDS can release a book and c for those of who don't know about CCSDS, their their doc their their standards are called books. They cannot release a book which deprecates a feature of 9171. They can propose a technology which solves the problem. Great. But the formal deprecation requires an ITF document, and this is just process. Currently, no live ITF document. Therefore, no deprecation on the horizon, and we need to fix that. So a bit of history of bun Bundle-in-Bundle Encapsulation. People have been working on it for a long time, different groups, different authors, mostly led by Scott. Scott's been leading the charge on this, and bless you for doing that, Scott, because it's been an uphill struggle. The custody transfer acknowledgment mechanism that crept in and then crept out and got pushed in, and people liked it, and then they didn't. We tried to split the two things apart. There's a problem with the coupling. It's caused a lot of because of the discussion around it, I can quite understand how naturally it drops down Scott's list of priorities because a contentious document is hard to continue to work on. But, hey, that's where it is. So these are the important things. Whose work is it? I am not claiming ownership personally for any of this work. This is Bundle-in-Bundle Encapsulation as it exists at the moment as a d t n working working group document. It was adopted in 2018. That gives us some idea of how long we have struggled with this. I've covered this before. Working group documents belong to the working group. Expiry, they expire after six months or even for adopted group adopted documents, they expire after six months unless they continue to up rev. This this document has expired twice now. We can rename, rescope, refinish whatever we want with the consensus of the working group. And that is all that is being proposed here is a rescoping, renaming, restaffing, and finishing it. Second point, credit. I am not taking any credit for this work. The credit for all this work exists with the original people who put the work in. If you look at the IETF boilerplate stuff, this is at the top of this tailor draft, it says my name as editor. The key contributors are all the authors of all the previous work because they actually did the work. I am not claiming to do anything apart from typing up a document, and and I wanna make that absolutely clear. It's I'm not after the I don't want a gold star to say, hey. I was the editor of a document. I don't care. You know me. I I actually don't care. And if one of the original authors wants to put their hand up and say, I will take over as editor, I would absolutely welcome that because it stops this slight chair conflict, maybe. But equally, I'm very happy to continue on that editorial part. So this is not a I'm not it's not a fame grab, and I'm not trying to claim any of this as mine. CCSDS, the the SISDtn working group is doing really good work on exactly this problem, and the document I have written up at the moment is an absolute summarization of the technical aspects. A CCSDS document, for those of you who don't know it, is a very large document with lots of required background information that they require for their documents that we in the IETF don't. So the document is that that I have edited basically strips out a lot of the CCS required craft and goes down to the absolute bare mechanics required to make Bundle-in-Bundle Encapsulation work. This draft is not in competition with that work, although it is parallel, and it absolutely adopts everything that is happening in CCSDS. Okay? So this is so that the two strands are aligned. We are talking about the same technology, the same things. There will need to be a wider conversation within CCSDS, but that's when I'm wearing my CCSDS hat and not my IETF hat. The purpose of this document is also to capture what the CCSDS is discussing and deriving at the moment and making it public so that we who are not who don't have visibility into the inner workings of CCSDS can stay abreast of what is being proposed and provide our feedback as is as is what the dtn working group at the I t f does and does well. Okay? The good news is the authors of the CCSDS documents are the same authors who worked on BIBE-CT. So it is the same group. It's the same background. It's the same history. And we'll just get it working. We'll get the mechanism in place, and then we'll argue about what is normative, what is the definitive version. But you can understand how the mechanics work at the moment. So my proposal is and that forty five seconds is perfect. I am proposing an update and a rename and not an adoption call. So the work has already been adopted by the working group. This is a continuation of the work I'm trying to kick start it. The Sipos prefix in the name is a staging artifact. I can't go push out I'm sorry. I can. I'm a chair. But I felt it was irresponsible for me to push out a dtn working group BIIBE document, which updated the existing BIIBE CT document without bringing it to the working group for discussion. The fact it has Taylor on there is because I wrote it and published it, and that's how the RFC sub submission tool works fundamentally. The document that I proposed, I proposed as the next revision in the chain of getting by correct in the in the working group. If the working group approves of this mechanism of here is an update capturing the latest iteration on by fixes, I propose that it is renamed draft-ietf-dtn-bp and added as the next update in the sequence updating BIBE-CT-05. Next version is just b b zero zero because we're losing the CT piece. And the continuity is all available in the data tracker as you would with anything else. And final slide, and then I'll pause and do the technical bit at the end if that's okay. So what I'm asking the room to confirm is two things. Are you happy with the rescope? And the rescope is in just encapsulation, no custody transfer, and the rename, I removing the CT from from the document because there's no custody transfer. It's his decision to gather consensus. I am refusing myself from this. If you want it as new work, that's fine. We can do that. We can do an adoption call. We can we can do it the other way, however you see fit. But there needs to be working group consensus, and we have to fix this. Amazingly, the technicalities aren't the problem here. It's actually a process problem and just getting this work kick started. I will pause now, and I will part two, the technical part, I'll do in the spare fifty minutes at the end where I can actually go through some of the technical details if you want to know what Scott is proposing. Go ahead, Scott.

[01:04:33] **Scott Burleigh**: Is there anybody else in the queue?

[01:04:34] **Edward Birrane**: Me, but please go ahead. That's fine.

[01:04:38] **Scott Burleigh**: Two or three points. One is I absolutely endorse this group. I think this is terrific. Thank you. Let's absolutely go ahead.

[01:04:43] **Rick Taylor**: I was really nervous about that.

[01:04:44] **Scott Burleigh**: Yeah. This is this is this is excellent. Two is the work that is being done in in the CCS JS Orange book right now is not only removing custody transfer, but also inserting segmentation and reassembly. Yes. And do you intend for this document to do that same thing?

[01:05:04] **Rick Taylor**: The document as it stands at the moment is everything that was in the orange book.

[01:05:08] **Scott Burleigh**: Okay.

[01:05:09] **Rick Taylor**: It's it's so yes. And I will get into this in sort of part two where it's not only encapsulation, it's also encapsulation with segmentation, which is our new word for fragmentation. Because when you say fragmentation, everyone thinks you mean the old thing. So we're using the word segmentation now to mean fixed fragmentation. So you can take a big bundle, slice it into chunks, put each chunk in a new bundle, and ship it through and reassemble that some decapsulation endpoint. So it's not just pure tunneling. It's tunneling with chunking as well. So, yes, completely. It's everything you wrote.

[01:05:43] **Scott Burleigh**: Okay. Great. Well, so my last point is it sounds to me like we're converging on deprecating fragmentation in 9171 as well. Do we need a separate document for that?

[01:05:58] **Brian Sipos**: Or does this document do it?

[01:05:59] **Rick Taylor**: I would suggest this document does it.

[01:06:01] **Scott Burleigh**: Oh, okay. Yeah.

[01:06:02] **Rick Taylor**: Okay. The other reason for this document.

[01:06:03] **Scott Burleigh**: That that simplifies things. Okay. Good.

[01:06:05] **Rick Taylor**: Thank you. Yep. So the purpose is this document says, this document deprecates ADU fragmentation, and here is the segmentation technique that solves all the things ADU was supposed to do, but doesn't break b p sec.

[01:06:20] **Edward Birrane**: I I I will only briefly mention the irony of taking the CCSDS work of Bundle-in-Bundle Encapsulation and encapsulating it in an RFC. The the the the point that you made earlier, which is

[01:06:35] **Rick Taylor**: We're not taking custody of it.

[01:06:38] **Edward Birrane**: The the the point the point made earlier, which is this work can happen, in in the open, so to speak, because, things are easier to access and and the technical review is through a larger community, I think, is is quite driving. I I think that it would be, a very useful thing to take the technical considerations going in CCSDS and making them available here so that we can have that technical conversation Yes. And get it out as an RFC, then perhaps that is something profilable back to CCSDS.

[01:07:09] **Rick Taylor**: I'm I don't yeah. I agree, but I don't wanna have a discussion about CCSDS processes and how

[01:07:14] **Brian Sipos**: No. No. We as No.

[01:07:16] **Rick Taylor**: Co chairs go back to the CCSDS who we have a working relationship with and discuss how the alignment between the documents exists. I'll take that offline with the CCSDS guys involved and the authors.

[01:07:28] **Edward Birrane**: So it was it was excellent to hear from from Scott that endorsement. My my quick question is, is there anyone that does not agree with that approach or has a strong disagreement with that approach, either here or online? Okay. That's what I wanted.

[01:07:47] **Rick Taylor**: Can I ask a check on Warren, you're on new AD, aren't you? No. Who's where Tommy. Tommy. There you are. I Tommy, I didn't see you. I know you're getting up to speed because you're on new AD. Does this seem like a reasonable approach to you?

[01:08:01] **Edward Birrane**: Well, we also have Brian in the queue.

[01:08:04] **Rick Taylor**: Ah, sorry. That was

[01:08:07] **Speaker 0**: Tommy Jensen, new friendly AD. Yes. It does. I really appreciate all the energy you're putting into drawing the appropriate lines. I don't see anything wrong going on here.

[01:08:17] **Susan Tan**: Thank you.

[01:08:17] **Edward Birrane**: Thank you. Alright. Brian.

[01:08:20] **Brian Sipos**: Yeah. I also wanna say that this all sounds great. It sounds like a good approach. And, also, it's good to see the scope defined in a way that is completely without loose ends.

[01:08:32] **Rick Taylor**: Yeah. Yep. And that's that's thanks to Scott and Alberto mostly just actually quite a wide team, really trimming it down to what's absolutely needed, which I I think makes for a better document

[01:08:44] **Speaker 0**: always. Right.

[01:08:45] **Brian Sipos**: So It'd be good to it'd be good to also not necessarily have rationale in this thing and be able to consolidate some of the convergence layer stuff elsewhere, you know, discussing, like, commonalities and things like that. Don't don't worry about trying to do it in altogether in here.

[01:09:02] **Rick Taylor**: So I'll cover that in part two, which I'll defer to later in this meeting where I absolutely tackle that that comment because that's that slowed some of the work before.

[01:09:11] **Speaker 0**: Right. Alright.

[01:09:13] **Edward Birrane**: Alright. So we will have that technical part second, but now we will invite up Sabrina Pellegrini to talk about reliability considerations for d t n.

[01:09:26] **Speaker 0**: Oh, certainly. And here is

[01:09:29] **Edward Birrane**: okay. Shall we?

[01:09:40] **Carlos Gomez**: No. That's okay.

[01:09:40] **Sabrina Pellegrini**: Okay. Hi, everyone. My name is Sabrina Pellegrini. I'm one of the coauthors for the reliability DTN draft along with Ed Brane and Alex White. We're all at APL currently. Alright. So I'm going to give a, I think, more of a high level overview of what we did in our reliability draft, and I think the real meat of what I wanna talk about has to do within the architecture of a d t n network. So I might linger there a little bit longer. But to give a high level summary, a lot of the updates that we pushed in this dash two, we updated a lot of the terminology just to be consistent with a lot of the RFCs that are floating around. In our architecture, which we will, talk about a bit, we changed what we called originally the adaptation layer to the convergence layer. We also more formally defined the convergence layer protocol stack, which I'll talk about a little bit more. We also created a new section to make it clear that the reliability that we're discussing in the draft right now is reliability specifically at the bundle layer and not at the other layers just yet. We also just refined, what our reliability classes are, sharpened up a lot of the variables that we associated with those classes. And then we also took a first stab at security considerations because that was absent in the previous draft. Alright. So just some quick minor updates. We removed a lot of the language that was in there originally that described should and shall statements, and that was because that was a lot of normative information for an informational document. So we got rid of that stuff. We also better aligned the document, to be more consistent with the RFC. So we were rederiving, I think, some of the definitions originally, but, now we're just sort of referencing a lot of the RFC stuff. And then, additionally, I think the more notable item that we updated was we introduced the concept of a convergence layer protocol stack. And, essentially, that is the collection of protocols underneath the convergence layer adapter. And, we wanted to do that for the sake of reliability so that when we talk about reliability, we can talk about the responsibilities and properties of the actual stack and not an individual protocol. So we attempted to depict that on the right here, where you can see the convergence layer adapter and then the subsequent protocols in between the BPA and the underlay. But rather than lingering on this picture, I'm gonna go to the next slide, which has potentially a better picture. So when we reasoned about reliability, we split the network in two different layers. And we came up with the four layers, application layer, the bundle layer, the convergence layer, and then the underlay layer. This is the same as what we had in the original draft, only we changed convergence layer from adaptation layer, to be more consistent with language that's currently being used. But this architecture that we've proposed is somewhat inconsistent with the architecture that we saw in nine one seven one. So right now, this is the image in nine one seven one, and you can see that this line right there is the, bundle node boundary. And then underneath it, the convergence, layer protocols are sitting kind of outside that boundary in no man's land. And when we talk about reliability, we wanted to lump the CLs with the CLA into one layer, so that, for example, if you're reasoning about a network and you have underlays that are very reliable, you might not care about the bundle node being reliable because all of your underlays are reliable. But if you do have underlays that you're working with that are unreliable, maybe you'd go back to your bundle node and say, well, let's implement convergence layer a convergence layer that has a stack that's very reliable. Or what we talk about in our draft right now, which is we'd implement reliability at the bundle layer. But we wanted to separate these so that we could talk about it in that way. So I think right now, like, the distinguishing factor between the convergence layer and the underlay layer might be that the protocols in the convergence layer go bop to bop or bundle hop to bundle hop, and the con and the protocols at the underlay layer are just hop to hop. But that is essentially, I think, where we might have some contention right here. And so I'm going to pause because I think we have some time, and I wanted to just gain everyone's opinion and feedback on this architecture that we've proposed. So if that's okay, I'll just pause for questions.

[01:14:34] **Edward Birrane**: I I would just ask, could you go to the next slide that that yes. That so this this is, sort of where my my questions are. The the picture on the left, which is from 9171, does put the convergence layer adapter inside of the bundle node, but the convergence layer being adapted outside of the bundle node and separate from the underlay networks. And and, therefore, it doesn't seem like an even which layer and how do we reason about this? So I guess my question to the working group, and maybe to Scott particularly is, does this picture on the right of talking and reasoning about a convergence layer protocol stack, the top end of which is a CLA for bundles, and the bottom part of that stack is whatever the underlayer is providing you. Does is that a sensible definition of the convergence layer question to the working group?

[01:15:30] **Scott Burleigh**: Scott Burley. The it has always seemed to me the convergence layer protocol stack made a lot of sense that that when when you have a convergence layer adapter, the procedures of the convergence layer adapter only address the application programming interface of the top layer of that stack. But what is actually doing the work of of moving data from one physical location to another is the whole stack. So I I I would I I think that ConvergenceLayer adapter still belongs inside the node, inside the the not within the bundle protocol agent, but within the node and invoked by the bundle protocol agent. And that in turn invokes the APIs of of the the top layer of of underlying protocol stacks. I think that's that's that's the way to look at it. And and yes. Sorry.

[01:16:34] **Edward Birrane**: Sorry. To that point, and looking at this, I think the picture on the right has a typo under BP instead of CLP one. I think that should be CLA one, which is the convergence layer adapter to protocol one underneath of it.

[01:16:48] **Scott Burleigh**: I I think that's correct.

[01:16:49] **Edward Birrane**: And then that cements the CLA inside of the node between the yeah.

[01:16:53] **Scott Burleigh**: Yeah. Yeah. It's not yet clear to me because I I need to think about it some more where the value lies in in separating out underlay layer from convergence layer. Because it seems to me that that those underlay protocols are an indispensable part of the convergence layer protocol stack, but I'm, open to hearing more about that.

[01:17:18] **Edward Birrane**: I I'll I'll make one comment, and then I do see that we have a queue. Unless, Sabrina, you wanted to address that. I as as coeditor, I I can render an opinion. Yeah. Go ahead. So the the the thing that we ran into in some of our implementations was the under the underlayer network itself, which we have to deal with because that's the thing getting with the hops to the next bot, would not give us certain reliability guarantees. And so in some cases, if we deal with a reliable underlayer, the convergence layer stack is very thin because it doesn't have to do much because there's a high level of trust in the underlayer. But if there's low level of trust in the underlayer, then you may choose a thicker convergence layer stack because that's the thing that you will put your confidence in getting you to the next bot.

[01:18:05] **Rick Taylor**: Yep.

[01:18:07] **Scott Burleigh**: Okay. I think I it's it's certainly the case that there can be a range of levels of reliability in the in the bottom of of the stack. Naming it separately suggests to me that that we're gonna reason about it differently. And and maybe that is maybe that's the case. If if we're going to address the protocols at the underlayer at the underlay layer differently from the protocols at higher levels of the convergence of their protocol stack, then it makes sense to to name them separately. And I don't yet understand how we're gonna do that differently.

[01:19:00] **Edward Birrane**: Okay. Fair fair point. Rick. Chair hat off.

[01:19:06] **Rick Taylor**: Yeah. The the the typo for CLPCLA. I I'm in general, I'm in agreement with Scott on this. And my suggestion would be, actually, where it says bundle node and has that nice ASCII art giant parenthesis, I would remove that. I don't think it's helping. Ah. It all of this discussion in my mind is a logical architecture in which we can talk about bundle processing. None of this is implementation detail. None of this has value beyond an anchor point for a discussion to say, there is the bundle processing agent that sits at the top with apps and stuff. There is some kind of adapter layer where individual interfaces, as I like to call them, but they are CLAs, attach some kind of lower layer, link layer, hop by hop layer, which may itself be recursive and multilayered and eventually end up with a physical layer or perhaps not even a physical layer, just a well, a pigeon's physical layer, I suppose, you know, all the way down. And and that stack below the CLA to the actual electrons moving in some way It can be massive or tiny or recursive and has different properties, etcetera. Trying to say that is inside the node or outside of the node, I'm not sure is helpful. I think having an architecture diagram is useful because we can talk about architecture in hand wavy terms. But let's if the IP world has taught us anything, let's not get caught up on IP over I can build you a CLA, which is bundle over LTP over EPP over AOS over IP over BP over LTP over and I can recurse constantly. So which is difficult to draw. I wouldn't try and overengineer this, and I we have spent a lot of time inventing exciting terminology, which hasn't helped sometimes.

[01:21:09] **Scott Burleigh**: Scott Burrell again. I I think there actually, I've been, talking with, Juan about this quite a lot lately, about the recursive nature of of the protocol stack. I I, in that sense, I think that what you say about, defining what's inside and what's outside of a node, is is a good point. I think that we have to recognize that there are networks stacked on top of networks. There are nodes within networks that are stacked on top of nodes within other networks. When you say this is within the node, I I think it's I think it's constructive to be able to say, if I'm if I'm establishing a node within a network at one layer of the stack, these are the things that have to be in it. And and other things are are depend and it depends on things that are elsewhere. So I think constraining the concept of a of a node to certain things is is not unhelpful, but I think we absolutely do have to recognize that it is it's it is turtles all the way down.

[01:22:23] **Edward Birrane**: It it just to jump in on that with the two comments. One is I I like the idea of defining layers based on their responsibilities, possibly their endpoints, and not simply the protocols that may be in the layer. Mhmm. You know, our networks are compositionally stacked and not sort of linear OSI, you know Sure. Stacks and

[01:22:42] **Scott Burleigh**: And I and I think that things like having this is at layer five is, like, not useful.

[01:22:47] **Edward Birrane**: Right? No more. No more. Yeah. Maybe never, but but no more. The second is is the proper place to have this discussion, this this layering and the definition of layering and so on in 4838bis?

[01:23:02] **Scott Burleigh**: Oh, yes. I think I think that's a constructive idea. Sure.

[01:23:08] **Speaker 0**: Yeah. Yeah. Okay.

[01:23:09] **Edward Birrane**: Alright. Thank you. Brian.

[01:23:13] **Brian Sipos**: Hi. Yes. Thanks. One thing that might be confusing this comparison is that the picture on the left is showing logical entities and how they relate to each other. And the one on the right is mixing entities with protocol stacks and layers, and those are valuable things to explain in pictures, but they might deserve to be their own separate pictures, meaning have a an entity diagram, have a protocol stacking diagram that relates to those entities, but don't try to mix them together into one picture.

[01:23:52] **Sabrina Pellegrini**: That's

[01:23:53] **Brian Sipos**: part that's that's part of the the possible confusion, not to say that the concepts are wrong, but just the pictures representing some of the concepts.

[01:24:02] **Sabrina Pellegrini**: Yeah. I see what you're saying. Thanks, Brian.

[01:24:05] **Speaker 0**: Yeah. Okay.

[01:24:10] **Sabrina Pellegrini**: As I said, I think I think that's, like, the crux of what I specifically wanted to gain convergence on here. But to finish out, just a few more of the updates that we actually pushed into the draft. So as I said, we created a new section that made sure it was clear to call out that the reliability classes that we're referencing are specific to the bundle layer. So in that diagram, ideally, once we figure out this diagram, we can start talking about reliability at each of the layers and think of it that way. So that's what this slide was all about. Then we've also refined what those classes were, so I encourage you all to read it. And then if you have questions, feel free to push it over email. We also refined and sharpened the variables associated with those classes. And then finally, a lot of the draft talks about the faults that could happen within the network. So what we've done is attempted to map the reliability classes, that would be required in order to mitigate those different faults. So there's an updated table in there that you guys can take a look at. And I think that is the last slide. So if there are no other questions, we can

[01:25:24] **Rick Taylor**: One very quick question.

[01:25:25] **Sabrina Pellegrini**: Go ahead.

[01:25:25] **Rick Taylor**: Talking about your classes

[01:25:27] **Sabrina Pellegrini**: Yep.

[01:25:30] **Rick Taylor**: Are you intending to specify that these are the four ultimate classes of all time and therefore must be you know, we can all talk about class two, or is this a division of different types of reliability for the purposes of describing them in this document? I how does this map to QoS, or does it not?

[01:25:52] **Sabrina Pellegrini**: I think that was still, like, a debate we're having, whether the classes that we come up with are applicable everywhere, and we can say class zero means this in in every context or if there's specific to each layer that we're breaking out.

[01:26:06] **Rick Taylor**: Mhmm.

[01:26:07] **Sabrina Pellegrini**: So the bundle layer might have class zero to three reliability, but the underlay layer, the convergence layer might only have it'll might only make sense to have zero to two class reliability. And so I haven't figured out if we have, like, an absolute scale that we just can all reference, which would be great. It's just difficult to equate that in words.

[01:26:29] **Rick Taylor**: Yeah. I I understand. My concern is that you will bump up against people's local administrative policy quite quickly Yeah. Where someone says, yeah. But I don't wanna call your class two class two. I wanna call it 23 in my scheme, and then we have this whole argument about toss bits again. And that's yeah.

[01:26:48] **Sabrina Pellegrini**: And if it was able to be quantifiable, that'd be easier, but I feel like right now, we're just trying to describe the classes in words.

[01:26:54] **Rick Taylor**: That's great. And that's admirable to be able to say there are the following general classes of reliability, and then we can all base the discussion around those.

[01:27:02] **Edward Birrane**: Yeah. Just a a brief follow-up. If you could go back two slides to where the the classes are yes. So there was a an idea here that if if we talk solely at the bundle layer and not an under and and not a convergence layer, otherwise, the thing that the bundle layer gives you is store and forward.

[01:27:22] **Speaker 0**: Like like, one of the things.

[01:27:23] **Edward Birrane**: That's sort of a sort of a biggie for for bundle protocol. And then the way we've talked about store and forward with reliability has been custodial behaviors and custody transfer. And there has not always been a crisp definition of custodial behaviors or or of of how you react to custody transfer. And if you look at the things that are that are laid here, best effort or store until forward, is different than any kind of custodial behaviors, and then you may have actually types of custodial behaviors. So that may not be a complete list, but it was an attempt of of at least enumerating how you deal with storage, and there might be more and and different.

[01:28:01] **Rick Taylor**: Great. Alright.

[01:28:06] **Sabrina Pellegrini**: Cool.

[01:28:07] **Edward Birrane**: Thank you very much.

[01:28:07] **Sabrina Pellegrini**: Thank you. Next

[01:28:11] **Edward Birrane**: is DTN access gateway for IP edge networks.

[01:28:17] **Speaker 0**: And this

[01:28:22] **Brian Sipos**: Give me

[01:28:22] **Speaker 0**: just a moment to get this done. Okay. And Yeah.

[01:28:28] **Edward Birrane**: Yeah. Yeah.

[01:28:28] **Speaker 0**: Oh, let me give it there you go.

[01:28:35] **Sheng Jiang**: Let's restart.

[01:28:36] **Rick Taylor**: That's fine. Go.

[01:28:38] **Speaker 0**: Oh, that's thank you.

[01:28:39] **Sheng Jiang**: Good morning, everyone. My name is from University. Today, I will present our work on access gateway for IPH networks. Let me begin with the background. Future Lunar communication systems such as LunaNet will provide an improperable foundation for networking. DTM is important for deep space back backbones. However, even when the backbones use DTL, many local IP networks may still exist as the edge of the DTL domain. Those edge system may not deploy the bundle protocol or understand DTL semantics, but they may still need to communication across the deep space links. We divided this communication environment into an IP domain and a VPN domain. The IP side has short RTT and can inject continue beats at high rates, and the DTS side use discrete bundles, stop carry forward, operational, and the limited contact storage and the link capacity. This created a mass mismatch at the boundary continue high rate IP traffic on one side and the discrete capacity limited bundle transfer on the other. The core question is, how can continue IP side traffic be simply admitted into DTM domain as bounded bundle payloads? To address this problem, we introduced the access gateway. It is a boundary boundary function between I p between IPH network and a domain. On the IP side, the gateway act as a proxy as a authorized proxy for TCP or quick connections. On the side, it act as a bundle potential agent to submit or deliver bundles. The key principle is that the gateway use the exceeding stacks. It does not change BP semantics, and it does not introduce a new BP potential element. Once the boundary function is introduced, the four main challenges need to be addressed. First, continue IPPs must be converted into discrete and bounded bundle payloads. Second, many independent IP flow may share the one constraint DTM pass. Third, the IP access appear continuous available, while the DTM forward depends on the contact storage and the link capacity. Force, those constraints are normally hidden from the IP center, why which may lead to uncontrolled over injection. In I will I will now explain those mechanism in the main h to h operation model. In the main operation model, a pair of access gateway connected to IPH network cross our backbone. This figure shows us more example. One gateway is deployed on the Earth side and the the other on the Luna side. Each gateway connected to the local IP networks while communication between gateway cross the Deep Space backbones. The gateway inter terminates the local IP connection, receives the bit stream, and then converts it to bundle payloads. The lunar side gateways receives the bundles, recovers, and the the ordered bits, and delivers them to target server. Therefore, the original end to end IP connection is split into two local IP connections with transfer between them. The IP connection itself does not cross the Deep Space link. For the perspective of the two IP system, the deep space transfer is hidden by the gateway. The fact the first mechanism is the denying is the dynamic bundle payload construction. Each admitted IP side connection is represented as a logic flow. Data from each logic flow enters a shared operation buffer. The buffer is the bondage and the shared, so the idle flow may does not reserve unused space. When admission is alone, the gateway extracts the date currently available in the buffer and construct one bundle payload. That payload may constrain date from one or several logic flows. The gateway does not wait for the before. As long as the date is available, the admission induction is satisfied. It construct and submit a bundle. It says avoid non necessary waiting delay. Because one bundle may carry it from several logic flows, the Egress gateway must know which bits belong to which flow and how those bits should be ordered. For purse for this purpose, the parallel gateway use payloads subprime subfines. A super high may contain a flow identifier as offset last failed and the payload dates. This information is carried inside the bundle payload and is interpretable only by the payload gateway. The next mechanism is contact aware gateway admission. This main purpose is to prevent the gateway from the inject bundles into DTN without control. Bundle construction and admission are therefore performance as one admission action. The gateways submit a bundle only when four conditions are satisfied. A service connection is available. The local passing interval has expressed, and there's a share the buffer content date under the DTN side interface can accept a new payload. If this condition are not means, the gateway will keep the date in the bounded aggression buffer. The last the last mechanism is the passive back pressure. So gateway admission rate is limited by DTM site service capacity. However, the original IP connection is terminate as a gateway. The IP sender does not count directly observe the condition of the Deep Space link. Its injection rate may therefore remain higher than the detail admission rate. When this happens, the shared operation buffer gradually fails. Once the buffer is filled, the gateway pauses read from IP connections. The available TCP or quick flow control credit is then consumed, and the orange center is forced to slow. In this way, change in DTM service capacity are reflect to IP sender through the existing flow control. After deploying after deploying access gateway, a natural extension question appear. Can a IP side client directly access DTN native service endpoint rather than only another IP edge networks? For example, an IP application on Lunar Rover may need to request a command service inside the domain. This request is a gateway to provide application level service mapping. This is, therefore, motivate an optional add to d t service access extension. In this extension, the gateway maps maps authorized the IP request to a d t n site service transaction according to local configurals. The gateway passes the request to select the target object and the service endpoint, apply detail admission control, and then constraints and submit bundles. The slide gives two non normative examples. The first is transport adaption. The same application potential is used on the both side and the transport bounding changes. For example, HTTP call over PCP or QUIC may be adapted to HTTP over BP. The second is the negative service mapping. Here, application semantics may be different. For example, HTTP guide request may be mapped to a CFDP file delivery operation. This require addition mapping mapping rules. Finally, I would like to discuss a possible working group work. The ingress and ingress gateway must also understand each other's. If the gateway are deployed independently, a comma interoperable contract may be needed. We say four main questions. First, how does an Ingress gateway select the correct Egress gateway? And how is the IP's destination or service map to the Ingress gateway EID? Second, how does independent gateway integrate the same bundle, including logic flow identifier bound data boundary and the disorder? Third, how does the two gateway maintain consistent view of the life cycle and outcome of each logic flow? Fourth, how does a gateway identifier is peer and discover the capabilities that peer supports? Addressing those question may require a common gateway application potential carried over BP. I would like feedback from the working group on whether it is useful standardization problems. Thank you.

[01:37:59] **Rick Taylor**: Yeah. Thank you very much. First off, good presentation. Mhmm. Second, good work. Thank you. Thank you. I think this is something which is valuable for interoperability and therefore standardization. Mhmm. I think the the mechanisms for bridging IP to BP, I can see a deployment where one vendor's device is on one side and a different vendor's device that is at the other side.

[01:38:33] **Sheng Jiang**: Yes.

[01:38:33] **Rick Taylor**: And therefore, an interoperable standard is worth doing. Looking at the slide here where you talk about gateway and target resolution. So I am working with my colleagues to look at how we can integrate bundled protocol information into DNS Yes. Specifically for this case Yes. Yes. The IP gateway can say, oh, I need to find out the the BP addressing so that for the other end, for the IP, and and DNS is a good example. So we will probably push some information out in the next couple of months, and we would like your feedback if that's okay. So, yes, I personally support. That's chair hat off and also chair hat on. I think this is very good work. Please please submit some some drafts.

[01:39:22] **Speaker 0**: Thank you. Thank you. Thank you very much.

[01:39:24] **Edward Birrane**: Yeah. Brian?

[01:39:27] **Brian Sipos**: Yes. Thank you. I think this is a good work, and it's a great presentation also. And you hint at it a couple of times in the presentation, in your discussion, but, if you do have applications that are known to use HTTP or as the presentation at the beginning of the meeting discussed CoAP, that you can take advantage of the fact that HTTP and CoAP both natively have the concept in their architectures of a proxy application. Mhmm. And that can be maybe a useful carve out to say, if you are operating HTTP or CoAP, do something, a little more tailored. And if you don't have HTTP or CoAP, then you fall back to this kind of IP, encapsulation, which is they're both valuable things, and I think they both are needed. And drawing a dividing line is useful to be able to explain in operations.

[01:40:31] **Speaker 0**: Yeah. Thank

[01:40:33] **Edward Birrane**: you. I'm I'm just gonna echo what Rick had said already. Good ideas and well presented. I would ask to see a a draft write up of this, a personal draft, perhaps something we could discuss at the next IETF.

[01:40:49] **Sheng Jiang**: Yes.

[01:40:50] **Edward Birrane**: It it is good to see the reasoning that goes into how to best create a bundle from this kind of traffic and not to simply flow it through because there are many things that could go wrong. So I I'm very glad to see that, and I think we're gonna wanna see the technical details going forward. But but chair hat off. Very excited for the work and well done.

[01:41:09] **Speaker 0**: Thank you. Thank you.

[01:41:11] **Edward Birrane**: Ben?

[01:41:14] **Rick Taylor**: Yeah. Ben, can you step to the mic so I can record? Yeah.

[01:41:24] **Ben Roberts**: Thank you. My name is Ben Roberts. Very good presentation. Really enjoyed it. I'm just thinking, really, in this, you've got gateway on Earth, gateway on Moon, and DTN backbone. But do you see maybe if this becomes more normal mainstream, do you see a layer of satellites around Earth that might be as part of a relay? Do you see LEO as part of a relay station and then GEO? I really am very interested in overall interoperability of LEOs because they're becoming so many and different becoming now it's becoming more than one type of LEO. So do you see that as being part of the GTN backbone, having layers of satellites in different orbits?

[01:42:15] **Rick Taylor**: I might answer that one, if that's okay. Yeah. I there are a number of people, number of space agencies, number of private organizations, number of governments looking at all sorts of combinations for infrastructure, including LEOMIO GEO, lunar relays, lunar orbital satellites. This technology is built on top of that. So once we have that sort of infrastructure in space, how do we actually use it? So a slight I don't wanna stop that conversation. Very happy to have a corridor conversation, and I'm sure there are people here who who have opinions on that, but I'm gonna park that slightly. This is a great architecture separate from how do we actually deploy it.

[01:43:00] **Speaker 0**: Thank you. Thank you.

[01:43:01] **Rick Taylor**: I I have one more point, which is doubling up on Brian's point. I think this is a really useful piece of technology for when there are not specific application layer proxies as you had in one of your slides to say, oh, there could be a dedicated HTTP proxy or SMTP proxy or, you know, specific protocol proxy for when users say, oh, I have a special IP protocol. And you go, okay. This will just do IP for you now. So I think it is a a really useful tool to go with all the other useful tools that we need to build. So thank you.

[01:43:40] **Speaker 0**: Thank you.

[01:43:41] **Rick Taylor**: Thank you.

[01:43:41] **Edward Birrane**: Thank you so much. Thank you.

[01:43:46] **Speaker 0**: Okay. Okay.

[01:43:49] **Edward Birrane**: So we now have seventeen minutes remaining in our fifty minutes of open mic time as we've have gone through a good discussion. Before we invite Rick back for bundle and bundle technical discussions, are there any other walk on topics or open mic topics? Oh, please. Oh, no. No. Please come up to the mic.

[01:44:15] **Brian Sipos**: It's here.

[01:44:16] **Edward Birrane**: No. It well, wherever you we wherever you'd like.

[01:44:18] **Rick Taylor**: Just the the same.

[01:44:19] **Edward Birrane**: It it's

[01:44:20] **Susan Tan**: closer. Alright. Do you mind if I bring up some slides? Or is this is Can

[01:44:27] **Rick Taylor**: we If if you wanna present something, can we fit you in on Thursday? Sure. I think we got a bit more time. So Okay. To to ping it ping the DTM chairs Yeah. And we'll we'll arrange that if you wanna do some slides. If you wanna just make a quick point, go for it.

[01:44:39] **Edward Birrane**: Well well, why don't we do both? Why don't why don't you just introduce yourself, what the topic is, and then, otherwise, if there's a presentation, we can put it in on Thursday as well.

[01:44:47] **Susan Tan**: Sure. Okay. Alright. Morning, everyone, everyone online. My name is Susan Tan. I'm with the Naval Research Lab. I wanted to bring it to to the attention of the working group, some work that's being done on key establishment for space communications. There's gonna be a a follow-up presentation on Thursday about this, but there are several efforts at the IATf currently and within this working group as well talking about different methods for key establishments. That is to say, you know, there's existing secure channel protocols within this working group that's already been in works. That's, you know, the BPSEC line of work that's already been done. But a lot of that, actually presupposes some sort of, key is already in place. And so, you know, as we develop more and more, interoperability and try to have, more connection with IP environments such as last presentation gave, and then also with some of the constrained, IP environments that Brian alluded to earlier with the EDHOC and COSE context and security associations like that, you really do wanna think about the manner in which keys are going to be agreed upon by parties Mhmm. In both the end to end case, hop by hop case. And you wanna really think through about how how delays and asynchronicity is going to affect that. And so, you know, for some use cases, especially in LEO constellations, near earth communications, the delay might might not matter enough where you can get away with using Diffie Hellman based key key agreement protocols, such as TLS or EDHOC. And in other cases where you have much longer delays, that's gonna be probably an issue. You don't wanna keep on having to, try to re you don't wanna have to get stuck at the key negotiation portion, that three way handshake, that the Diffie Hellman hand, protocol is relying on. And, you you may wanna consider some other means of, perhaps key agreement in which you can, in one shot, send the, or agree upon the key and have encrypted data being sent at the same time. And so there's work currently in the IATf, in a new working group to adopt a new protocol called the messaging layer security protocol. A lot of the same folks who worked on TLS, are in that working group and worked on that protocol. MLS brings that asynchronicity to the key establishment process. It has a lot of other, security features, are nice, such as post compromised security, which means that, you know, if your keys are compromised, you you can actually recover security rather than having to tear down and reestablish new connections, which may be expensive in light of the d t n environment. So if you're interested in this line of work, there's a lot of it. There's a lot of other interest being generated at this IETF. There's gonna be a birds of the feather meeting, on Tuesday, at sixteen thirty local time. That's the current working group spelled c u r r e n t. It's a much longer acronym. I don't remember the name of it. But they we're gonna meet at sixteen thirty on Tuesday. I invite anyone who's interested in security for DTN to attend this working group, and I'll give up my open mic. Thanks.

[01:48:29] **Rick Taylor**: Could you put that date on the DTN mailing list?

[01:48:32] **Susan Tan**: Yes. Will do. Thank you.

[01:48:34] **Edward Birrane**: And happy to have the discussion on Thursday. Please, if you do have slides, propose them so that we can get them

[01:48:41] **Carlos Gomez**: in the system.

[01:48:41] **Susan Tan**: Will do. Thank you.

[01:48:43] **Edward Birrane**: Are these the same as Birrane's?

[01:48:46] **Susan Tan**: Sorry. Say again?

[01:48:47] **Speaker 0**: Are these the same slides that Birrane presented before?

[01:48:49] **Susan Tan**: Yes. Birrane, Ben, myself. Yeah. Yeah. We've hopped around to several working groups, Tip Top, here, Quick, and a few others to solicit this this idea. And so there's finally kind of a enough people to do a buff out of this. And so I really do encourage anyone from here interested in, you know, security and everything to attend that and voice your support for the for the working group. I think a lot of the agenda applies to the work that's going on here in terms of security.

[01:49:21] **Scott Burleigh**: Alright. Thanks. Okay.

[01:49:23] **Edward Birrane**: So we we have eleven minutes. Let's let's get back to bundle and bundle technical.

[01:49:32] **Rick Taylor**: Okay. Oh. The mic has dropped. I'm really glad Scott's in the room because Scott can cover some of the discussion on this one. So I'm gonna rely on you to answer some of these questions because I am talking about Scott's work. So I'm gonna go fast to slide 13 or 14, I think it was. So quick summary. Bundle in bundle encapsulation as it stands today is encapsulation only. There is no custody transfer. There is no hacking. There is no reliability in there. No retransmission. There is literally put a bundle inside another bundle. Best effort. Okay? The tunnel okay. So the reason being is reliability belongs to some other orthogonal reliability mechanism, either some sort of reliable link layer or some sort of custody transfer signaling, be it compressed, be it whatever, that may be developed or handled bespoke or through the IATf. It is unrelated to whether you put a bundle inside another bundle. Also, the tunnel is deliberately transparent to anything layered above it. So you can put bundles inside bundles inside bundles inside bundles inside bundles until your MTU explodes. And there's nothing to stop you doing that. There is a security consideration that says careful. Also, it's not an administrative record. We don't need to go reach out to Ayanna here and ask for special numbers or whatever. You are just like you do with IP and IP or GRE. You can select a particular destination for the outermost bundle and send it there. It just goes to an endpoint that receives it and understands to unwrap it. Point number three, segmentation included. That means if your bundle is too big to pick fit down the pipe that you must shove it down I'm using very loose terms here because there's a number of reasons why that might happen. BIBE segmentation gives you the option to cut it into a number of smaller pieces, put each of those inside another bundle, and send them individually to the decapsulation point, which will know to assemble them and put them back together. And this fourth bullet applies to this document less than the CCSDS document. I know that the sorry. I attend CCSDS as well as IETF. So the CCSDS document has taken a number of iterations because there has been a sticking point about whether to strictly prescribe all this behavior as a CLA or as a service or how does it fit within that ASCII art diagram we were discussing in Sabrina's discussion? Where where does where does BIBE fit? So in the BIBE document as it stands now, I have avoided all of that by saying its behavior, its functions. I have described what must happen and haven't tried to fit the square peg into any of the round holes that are available. So that's a that's an intentional sidestepping of where does this fit in the architecture. And it's saying, you can put bundles inside other bundles, and here are the responsibility of the person who of the actor that puts the bundle inside another bundle and the actor that unpacks a bundle outside of it. And you work out how that fits within your implementation. And that has actually made the whole document easier to write. So, hopefully, that sticks. I'm not gonna go too deep into the use cases. These should be well known. Yeah. You might wanna add security over a short sub sub path within your end to end path so you can put it inside another bundle, hide the content, put p p sec on it, on you go. You might want to tunnel across different person's administrative domain because you have less trust in them. You might wanna put b p v six or something else. B p v six is a better example inside a b p v seven bundle and tunnel it across. Sorry. It doesn't require bespoke protocol for that. Segmentation, I've covered that already. And you might also wanna do it for traffic flow control. And these are all pretty analogous to everything that IP does. So this is a read across to say, oh, well, IPs, we've learned many things over the last thirty odd years of IP tunneling. Why can't we have these facilities? Well, BIBE gives you all those facilities. So anything you can do with IP tunneling, you should be able to do with BIBE. And that's a really good litmus test when reviewing that document. If you know of a preferred or a popular IP tunneling technology that is not natively supported by BIIB, that is an option to flag up on the list and say, hey. You missed this. From my survey, I think we have covered it. So you can do IPsec ESP mode stuff. You can do IPsec tunnel mode stuff. You can do standard sort of IP over IP GRE kind of tunneling. We've kinda got it all. We've got the DCAP multiple endpoints concept so you can have the equivalent to GRE keying, so you can have multiple flows going to different places, so you can do all that kind of stuff. And it's kind of heading in the direction of segment routing, but we we will not say any more about that today. And the key point from the IP tunneling analogy is also we can read across all the security considerations. So we can look at all the operational experience and everything everyone learned with IP tunneling and say, okay. How many of these also apply to to BIIB? So the security consideration section of the BIIB document stands at the moment, I think is in pretty good shape because I've been able to lift it from elsewhere and correct it and remove things which no longer apply because we're using BP. But otherwise, it's all the stuff we learned doing IP tunneling. But again, have a good review. And those classic examples being recursive encapsulation loops, and there's a fantastic RFC sixty one sixty nine, which just catalogs all of these things, and I've I've referred through to it rather than cutting and pasting. So the segmentation mechanics, it follows exactly the same pattern as you see anywhere else where you take a big thing, cut it into chunks, and try and reassemble it. It looks a lot like TCP CLV four segmentation for those of you who are familiar with it. It also looks a lot like BTPU because guess what? We all followed the same pattern. Basically, take a big thing, break it apart, mark the transfer ID. So this is part you know, these let's say I have a big bundle I split into six blocks. You say, all six of these blocks are part of the same transfer. For each of those sub chunks, you record the total length of the reassembled thing and the offset within that total. You have two choices when you're chunking stuff up. You can either do part one and individual length, or you can do total length and segment offset. They it's horses for courses, as the English say. It depends entirely on your environment. It depends on how many bits you care about on the wire. In this case, the authors chose to go with total length and segment offset because it actually makes the reassembly a little bit easier, but it's conceivably two or three octets more expensive on the wire. I leave it to the working group to discuss the pros and cons on that. I see no problem personally on this one. There's in because the wire format will support, there is an entire bundle inside this bundle and there is a segment inside this bundle. The payload format has, thanks to CBOR, a single CBOR array. If there's one item in the array, it's the whole bundle. If there's four items in the array, then it's a bit of a bundle, and those four items describe what those bits are. Yeah. The transfer ID, unlike things like BTPU, has transfer ID windows, which manage how many individual transfers are in flight or TCPCL where those transfers are acknowledged as part of a completion because TCP obviously gives you reliability. The transfer ID is just a unique number, and the windowing machinery is excluded because we can use bundle lifetimes. You know the lifetime of the bundle you're encapsulating, so set the lifetime of the outermost bundle to be the same. And equally, you're doing segmentation, that controls how long that transfer should complete, how many are in flight or whatever. We have to we can remove that whole windowing mechanism, which actually simplifies. It's great. Reassembly is optional. You could throw it away. If you get stuff you don't understand, you go, yeah. I don't do that. You could just bin it. Because by be fundamentally unreliable as bundle protocol is fundamentally unreliable unless you go away and apply custody transfer or know that your underlying convergence layers are all reliable, and this is where Sabrina and Ed are working on that reliability piece, we can copy exactly the same semantics to say, if you receive something you don't understand, just like any other bundle, you just bin it. So that means if you have a particular deployment and you don't care about segmentation, you don't even need to implement it. It's fine. Nonfeatures. I kinda covered this quite a lot. There is no acknowledgment. There is no custody transfer. We fail silently just like, hey. You don't like the bundle, you've been it. That's fine. There's no extra diagnostics machinery. There's no new exciting status codes. All the existing status reports work. We can point to various places within the mechanics of of BIBE and say, you know, this is where a status report gets emitted optionally. It doesn't need new exciting status ports. And the decapsulation notice, the policy enforcement point, and it fits within the standard ninety one seventy one and ninety one seventy two b p sec enforcement model. There's no new mechanics required, which is, I think, a really good sign. And it's running almost in many places. A lot of people because the original r the original drafts came out in, like, 2018, various implementations have been fiddling with this repeatedly over time. And as a rough survey of who does something BIIB ish, ION has the full BIIBCT implementation because Scott kind of oversees ION and was writing the documents, so unsurprising there. Micro d three tn from from d three n the d three tn does it, but it does encapsulation only. It doesn't do the custody part. D t n m e, the CCSDS, does the segmentation prototype stuff, but, again, only does the encapsulation. Again, didn't do the custody transfer. And I think it's really telling that of those running implementations, two out of three of them went, yeah. I don't care about the custody bit. Let's just do the tunneling bit, which I think is a really strong marker that that's that's actually where the consensus of the community is going. We just need that tunneling that segmentation ability. We don't need those acts. So I I think we're heading in the right direction.

[02:00:50] **Edward Birrane**: Yep. We are a little past eleven.

[02:00:53] **Rick Taylor**: Oh, damn it.

[02:00:54] **Edward Birrane**: Okay. So what I I wanna say is just because I know we may lose the Yeah. Yeah. The meet echo. We do have our second session on Thursday. We can discuss this then. We can we can pick it up then. I know that, Brian, you were in the queue. Do you wanna make a last comment and read us out? But otherwise, we have about a minute left.

[02:01:11] **Brian Sipos**: Sure. Yeah. Thank you. One little comment, and it's great that the technical detail is here to be able to discuss this level of detail that I'm gonna mention. Yep. But on the previous slide about the transfer ID scope, it might be good to narrow this to only observable behavior and say it's encapsulating endpoint to decapsulating endpoint, not encapsulating node, only because it forces the receiver to try to guess what is the node versus what is the endpoint that I see in the message.

[02:01:45] **Rick Taylor**: Okay. It's a very rapid answer. First off, the word node should probably be in quotes there because this is part of the trying not to say it's a particular part of the architecture that does it. Something in the node has decided that it's going to do BIBE. That's all I mean by encapsulating node. Okay. Check the terminology in the doc. And and Okay. Encapsulating function.

[02:02:08] **Edward Birrane**: And and let's please have that discussion on the mailing list. Thank you all for being here, and hopefully, we will see you all on Thursday.

[02:02:20] **Rick Taylor**: Got one slide left.

[02:02:22] **Edward Birrane**: But we'll get we we'll we'll switch in. Oh, even with fifty minutes, we we went

[02:02:27] **Rick Taylor**: through it's

[02:02:28] **Edward Birrane**: a good discussion. It's a lot going on.

[02:02:30] **Rick Taylor**: We did the right thing. We left twenty five minutes in the end. Yeah. It was nice. It's two sessions.

[02:02:38] **Edward Birrane**: I I think that's working quite well. Oh, excellent job. Then I'm it's TDR.


---

**Session Date/Time:** 23 Jul 2026 09:30

[00:00:04] **Rick Taylor**: Temporary doubts, so we'll just be done with it. No. No. Only in the end, hopefully.

[00:00:15] **Ed Birrane**: If it helps, we could all home. Genius. Alright. Good good morning. It is, 11:30, so, why don't we get, the working group started? I would ask if someone in the back would shut the door. That would be appreciated. Thank you so much. Okay. Welcome to session two of the d t n working group. We are gonna sort of go through these introductory slides pretty quickly because they are not different, from the session one working group slides. Please understand that we have policies, and we expect those policies to be followed. Please use the online tools, including myself, fast forwarding through the slides. Please understand that we do have guidelines for conduct. We should be hard on ideas, but not on each other. The resources are here, and our mailing list is here. And we are now in the agenda for session two, which is, updates to our Yang modules for ADM, a variety of updates for materials being worked on by Brian Sipos, and then we also have a addition to the agenda, which is discussions of security. So before we start, Rick, anything you would like to add?

[00:01:33] **Rick Taylor**: Nope. I think we covered it.

[00:01:34] **Ed Birrane**: Alright. Well, we only have an hour, we do have some things to get through. So why don't we get started? Our first presentation is gonna be on the DTN, network management architecture, Yang modeling with Per. Let's see.

[00:01:49] **Per Majon**: K. Confirm. So my name is, Per Majon. Presenting, the work you've done for the EDM Yang. Next slide, please. It was a joke, keeping it light. So how many here know what Yang is? Okay. How many definitely don't know what Yang is? Okay. Well, there's no consensus on that. But YANG is a data modeling language that has its roots in network management. It was developed as a need for data modeling for NetConf, and it's defined in RFC sixty-twenty and 70 nine-fifty, widely adopted in the telecom industry, provides an interface for programmatic network management. The overview of this work that has changed is that we're now trying to use as many yang native statements and types as possible. So reducing the number of extensions that was in the dtn-dtn-dtn-dtn-dtn-dtn-dtn-dtn-mm, introducing this extension a m m colon a m m to signal to tooling that this is now on a d m yang module as which then tunes the tooling to being able to understand that, oh, these extensions, I need to understand them, and the tooling that doesn't understand it just ignores it. Okay. And this helps reducing the amount of explicit declarations, which we'll see compared side by side during this session. So there are a few simple types defined in the ARI, and a common pattern is to then define a yang module for your types, calling these ARI types, using yang native types, and then doing derived types for them. That is, type defs. This is not possible for the Real 32 and Real 64 because there are no IEEE floats defined in in Yang, which was discussed in NetMod in this room just in the previous session that for Yang next, this is a thing that is actually wanted. Okay, so this is a list of on your left hand side, you have the ARI column, then in the middle, the ADM YANG type and where it's derived from in the yang native type. So as you can see, it's not possible to derive types for Real32 and Real64, so these are then defined in normative text as yang extensions. So how would a simple type look? We want to define the ARI null. We're using the yang empty type, which is what it boils down to in the CBOR encoding underneath. So this would declaratively tell the tooling that this is what's going on. Sorry. Using these types, you import the ARyTypes module, define a leaf as a variable, and then setting the type to a derived type. Another type that is defined is label. So we have the ABNF, and this is the corresponding yang definition for that. So, a union of int and the text string with the pattern. So this is declarative and the tooling would take care of this instead of you having to support it in in code. Another type, nonce, which is a union of null, uint, and byte string. In the reference implementation, it's defined differently, so this needs to be aligned in the reference implementation, so it follows the document. Bit larger slide here, more complicated definition. So the collection, that you can see the ABNF. So, just to be clear, I'm running through this and if you have questions, we can go back and then discuss. But this then has creates a typedef AI that is not defined yet, but needs to be defined so how that would look. We create an extension collection with identifiers and arguments, and then define how, in the description, that would work. So that is not handled by tooling. That has to be hand rolled in your implementation. But then using this collection in the my collection, the yang at the at the rightmost bottom, you would have the collection identifier, what the types are for it, and then values going into it. So, values, you could say. This is not native yang, so this would be a special construct. An alternative would be to not have the type information in the yang, allow arbitrary data, and defer validation to implementations. Or using AnyData, you would also do the same thing. AnyData is a yang construct and you would it's in the schema, but the schema for the data is unknown at validation time. So just if you go back to one slide, what we would miss with the alternative implementation or definition is that there would be no type. We would just be able to take everything like a set. Okay. And a map. So this would translate to a list in Yang world. Looks like this, easy enough definition, where you have the leaf, so it's an associative map. You have a leaf, which is a key, and then you have a value. And in this case, our key is uint. Or an alternative definition is if we do an extension as a map do an extension instead, and then just have the arguments, and then in text, normative text, we define how it should work. So what we're losing here, again, is validation from tooling. So with with YANG native construct, you would get declarative validation from the tooling. Can skip this one, I think we saw it before. Another derived type is CBOR. This would be a binary, but carry a normative text to what its contents is. So, let's look do you want to go already now?

[00:09:44] **Ed Birrane**: Do you wanna take questions in line or towards the end?

[00:09:47] **Per Majon**: We can go now.

[00:09:49] **Ed Birrane**: So in a couple of the examples for for Map and and the other, you you had said there are a couple of different ways you can do this. Here would be the sort of the native type implementation. Separately, here's how you could do it if you wanted sort of a more arbitrary bit of data, and then your custom tooling would have to do the verification. Intuitively, it seems that having something with native type checking is preferable because we want to inherit and use as much gang checking as we can. So I guess my question is what is the purpose of offering the alternative?

[00:10:22] **Per Majon**: To form discussion in the in the working group. But just to show

[00:10:27] **Ed Birrane**: since To solicit questions.

[00:10:28] **Per Majon**: Yes. Exactly. So I want to present it because I think that you might not know Yang by heart, everyone. So that is why these are the alternatives.

[00:10:40] **Ed Birrane**: Do you yourself have a preference?

[00:10:42] **Per Majon**: Yes. I very much have a preference, the Yang native one

[00:10:45] **Ed Birrane**: Okay.

[00:10:46] **Per Majon**: As much as possible.

[00:10:47] **Ed Birrane**: Yeah. Agreed.

[00:10:48] **Rick Taylor**: So quickly jumping in the queue. As I understand the purpose of the ARI encoding, it is to ensure that there is type safety and that the validation can occur. So leaving these things as any type seems to be an anti pattern.

[00:11:08] **Ed Birrane**: Yeah.

[00:11:09] **Per Majon**: Or you would have to carry it in the implementation in that case.

[00:11:12] **Rick Taylor**: Yeah. Yeah. Yeah.

[00:11:13] **Ed Birrane**: Brian, I see you're in the queue.

[00:11:15] **Brian Sipos**: Yes. One other thing that can help inform and compare alternatives is that we do currently have a catalog of existing produced agent implementation. And so that can be used as a baseline of saying whatever is chosen as a possible alternative needs to have enough information to reproduce that implementation through the tools. So that's, I think, a good touchstone of does it have enough in the yang definition to be able to get me back to where I wanna be?

[00:11:53] **Ed Birrane**: Yeah. Fair point.

[00:11:54] **Per Majon**: Yeah. Absolutely. So so it it's not a I don't want to create a theoretical concept here, but the it very much needs to work. It's, I guess, engineering work, not science.

[00:12:09] **Rick Taylor**: Yep.

[00:12:09] **Ed Birrane**: Thank you.

[00:12:11] **Per Majon**: So I'm very mindful about that. There is some implementation in the reference implementation for the we've done for the simple types, just to make sure that it works with type, typedefs, and so on, and derived types from the types as much as possible. The more complex types don't have implementation support yet. So that is why also why there's the preferred solution and an offering of an alternative. But let's go to yes. So an example of the old definition, you could say, and the new Native and Jang native definition side by side using ietf-dtn-amm-agent. So, basically, the old implementation will be on your left, and the new implementation will be on your right. And the old one uses a lot of extensions and so on. From the current published document, on the right hand side, you will see a more YANG native suggestion on how that will look. So we start here. Easy enough. Extensions for EDD, enum type, typedefs. So type and typedef is now a YANG native construct on your right hand side. EDD, I don't know if we should keep it or just use, as we'll see later, config false instead to signal. In my view, config false is something that I understand, that that's operational data, it's handled by something else, don't configure it. For people knowledgeable about dtn-dtn- a and ADM, EDD might be the native construct instead. Yes.

[00:13:55] **Rick Taylor**: So directly for your EDD comment, and I'm expecting someone from from the DTNMA experts to correct me, I'm not sure config false is correct for EDD simply because I an EDD may be configurable. It's just external. It's not a generated value. Am I right in that?

[00:14:19] **Ed Birrane**: That is correct for EDD, externally derived data. And I was misunderstanding or myself originally the meaning of config false. Config false, as explained to me, means simply that it is operational data, not not that it's, a constant. So it's operationally sampled.

[00:14:38] **Per Majon**: So just stored in some other place data store, but you can still configure it?

[00:14:45] **Rick Taylor**: Okay. Okay.

[00:14:45] **Per Majon**: Is that is that what EDD means?

[00:14:49] **Ed Birrane**: Yeah. It its value is is determined in runtime as as part

[00:14:55] **Rick Taylor**: of Yeah.

[00:14:55] **Ed Birrane**: The sampled operation.

[00:14:56] **Rick Taylor**: It's a sampling of an instrument sensor or or Yeah. Yeah. I still think that's configurable, but that's fine. I'm I'm not gonna dial.

[00:15:04] **Per Majon**: But can you can you write can you write to it?

[00:15:05] **Rick Taylor**: Yeah. It could be a poke as well as a peak, but it's on

[00:15:09] **Per Majon**: a Oh, but, yeah, I mean, can you can you set the temperature for your sensor?

[00:15:12] **Ed Birrane**: It is externally derived. So you in in the model, that an EDD is meant It's like it's basically not with that. Not ready. But sorry. No. No. Please. But it is extern its value is set externally.

[00:15:26] **Rick Taylor**: So the case so it's not writable?

[00:15:28] **Ed Birrane**: Correct.

[00:15:29] **Rick Taylor**: Okay. The reason I asked this, will come back to you later. Please, Karen.

[00:15:32] **Per Majon**: Yeah. Okay. So it seems we have to circle back on this one. Defining counter 64 type, you see on your right hand side the old one, everything is with extensions. On the right hand side, we used the yang native types instead. You can see the derived type being used there. And you also see now the this extension, right, from the very from some of the very first slides, the AMM AMM. This tells the tooling that, oh, I'm now in AMM world. Need to handle this this way. Carrying on, now creating an EDD for received messages on the left hand side, you have this using this counter64 type that we did. Why I wanted to use native types here is because if you see this type, the IETf slash amm-base, etcetera, etcetera, needs some parsing. Right? It's not tooling. We'll not we'll have to do something with this. But on the right hand side, we just use a derived type and the tooling understands it. You can see that config false statement there. I have to take that discussion. Object types. So, more complex, can have parameterized values. This is what an identity ident would look like in native Yang using the parameters for AMM parameters, extensions for a value going into the the ident. Again, we saw this, but an EDD using config false, you heard the discussion. Parameters as attributes because they can be parameterized, so you need a construct where you can express this. An upper statement. We do an extension called upper, reusing the input and output statements from Yang. This is our numeric now, derived type, the union of all numbers. This is our add operation, where we have input, value a and value b, using this numeric type, and the output is numeric type as well, the sum, basically. We can constrain the input as well. So, for instance, if we sum, we have a collection of operands and want to sum how many they are, or run a sum over the list, we can say that r has to be from one to max count to negative numbers. Var, simple leaf, using a leaf ref when you reference it. For control, state based rules and time based rules. They could be done in native YANG as RPCs, but I'm thinking that they might need to be extensions instead because you pass them around as data, not only as interfaces. Yeah. And the next steps are to continue the work, to add more tune and add more using the concepts and developing the reference implementation lockstep with the standardization work. Rick?

[00:19:19] **Rick Taylor**: So chair hat off. First off, thank you for doing this. I think it's I think it's a a really useful to have someone who is a net complex bird come and look at the the the slight tangle we had got ourselves in. One of the things I would really like to see personally is for the working group to be able to define a pretty standard young model for some of the basic concepts we have within DTN, And then to be able to augment it with the a m m special source in order to then do the clever stuff that you can do with dtn- a. But for those, you know, on a terrestrial environment or as part of a specification or in an ICD to be able to say, this is the young model for my light bulb that goes on and off. And then the automation of it can be done as an augments, possibly being done by two separate parties. So the light bulb manufacturer can say, this is the young model for the light bulb, and they don't have to rethink that work for AMM. Someone who understands DTMMA can go, oh, cool. I can do it. It extends and augments or whatever to add that AMM. Does that fit the model?

[00:20:39] **Per Majon**: I think so. Yes.

[00:20:40] **Rick Taylor**: You think so. No.

[00:20:42] **Per Majon**: But so light bulbs, are that usually what you send to off the planet?

[00:20:48] **Rick Taylor**: I was trying to think. Let's do a temperature sensor.

[00:20:51] **Per Majon**: Yes. I think it makes it's possible to augment, extend, deviate the Yang model. So if you have a base Yang model and then tune that, it it that is Okay. Normal work. Yeah.

[00:21:04] **Rick Taylor**: Okay. It makes sense. Yeah. So I'm I'm not forced to define an AMM enhanced model variant of a what I would do as a normal young model. I can do it take a a traditional young model and augment it with the AMM program programmability.

[00:21:24] **Per Majon**: Yeah. Okay. Okay. Okay. Yes and no. I would say since there are some concepts are very different, I would say that you need to probably define them from the start. So taking a temperature sensor, if you want to run use it in a collection, that is fine. Mhmm. But using using a control on that sensor might be trick a trickier thing.

[00:21:56] **Rick Taylor**: So this goes back to my conflict question, and I will yield the line in a second. I had, in my own private world, without actually telling anyone else about this, had worked around the concept of taking a stock Yang model and exposing it purely as EDDs and consts so that you could then drive it from an AMM, but that imported Yang model was considered external to whatever you were developing in ADM. And I'm not sure if that holds.

[00:22:24] **Per Majon**: I'll look into if

[00:22:26] **Rick Taylor**: it's a longer conversation to have.

[00:22:28] **Brian Sipos**: Go ahead. Hi. Don Fettig. The the use like, when you flash by some of the union stuff, that has a different meaning in Yang than than what like, for something like that. Like, when you're passing data into a schema with that, the first one that matches is the one that that goes. But so I'm I'm I'm questioning the use of the term union there because it's got a different meaning. Should should you be doing that, or, you know, is it really a set or, like, one of should be defining something new?

[00:23:05] **Per Majon**: That's a good point. I wanted to reuse it for the tooling, so having it validate was the first thing. But you're right. So the type coercion might be might be off using this. Right.

[00:23:22] **Brian Sipos**: Go ahead.

[00:23:23] **Ed Birrane**: Brian? What? Oh, so Brian is in the queue. Sorry.

[00:23:29] **Rick Taylor**: Can you can you join the queue? Yeah.

[00:23:31] **Brian Sipos**: Just on the topic of do you care about how your model's being used, I think the answer is you always do have to care. You can't you can't be ignorant of how the implementation is gonna occur because you'll run into situations of my expectation is that most existing Yang models are gonna be pretty deeply nested, and the the AMM is kind of, by definition, flat. It's a collection of EDDs, and and they're all pretty they're all atomic things versus most existing Yang models are gonna be pretty deep and pretty complex.

[00:24:09] **Per Majon**: Okay. And on that point, having your temperature sensor, having a Yang module that is purely config, that is not difficult. But if you want to have some interaction with it, I mean, it is an API. Right? Yep. Then you have to carry that in implementation anyway. So you can't just take your I mean, it depends on the implementation of the the YANG module as well.

[00:24:30] **Rick Taylor**: Mhmm. Okay. It was my original point was about reuse.

[00:24:34] **Ed Birrane**: Mhmm. Alright. One more. Please.

[00:24:38] **Javier**: Yes. Thank you. So I'm Javier from I'm the Atlantic in France. It's the first time I'm attending, like, kind of seriously out of curiosity. So I'm definitely lacking some context, and I'm don't want to take much time. But raise we've been recently playing with satellite communications. I it caught my eye that you were doing stuff with Yang, and so we are recently implementing this in Pycor in CoreConf. So I noticed in the draft, you mentioned NetConf, RestConf, etcetera, and CoreConf is not mentioned. Although, I would kind of think this is would be, like, the really default management protocol for this, for satellite. And we also recently developed a CoreConf m two m, so sort of an alternative to lightweight m two m, etcetera. So using CoreConf. So I was wondering if you have looked into this and if you would be interested in, like, maybe I could email you and send you some more information on this.

[00:25:38] **Per Majon**: I have not looked into it. I'm coming from a NetConfresconf background, not the IoT background. I know what CoreConf is. Yes. Send a mail, please.

[00:25:46] **Javier**: Okay. Will do.

[00:25:48] **Rick Taylor**: Yeah. To the dtn mailing list as well would be great.

[00:25:51] **Javier**: Dtn. Perfect. Okay. We'll do we'll do that. Thank you.

[00:25:54] **Ed Birrane**: Alright. Ed, thank you so much. And then just in the interest of time, we'll we'll wrap up and and get on to Brian's. Yeah.

[00:26:01] **Per Majon**: Thank you.

[00:26:01] **Ed Birrane**: Thank you so much. Brian, would you like to run your own slides?

[00:26:10] **Brian Sipos**: Please. Yes.

[00:26:15] **Ed Birrane**: K. You should have control.

[00:26:20] **Brian Sipos**: I just need to find them. Sorry.

[00:26:25] **Ed Birrane**: Also, if you have joined the queue, please unjoin the queue.

[00:26:31] **Brian Sipos**: So I'm gonna spend some time now to talk about, kind of brief summaries of existing adopted drafts and and where they sit, and what needs to be done remaining on them. So the the four adopted drafts are, the Cozy security context, EID pattern definitions, the updated non experimental UDPCL, and then the secure advertisement, mechanism. And these slides are even slightly out of date from, when they were created to currently. The changes here are accurate, to the the version 16. There were bunch of editorial updates, adding some term definitions, clarifying things. The new section two five two about KDF context was a good catch that genuinely was just missing, and it needed to be specified, because there are some bindings into the into the b p sec context that need to exist, and those are now well defined. And the examples now include the data that corresponds with this. So this was caught during, some trial implementation, and this closes out these loose ends. Other thing that was asked for, from review was that at the time of the editing, the COSE algorithm for ML-DSA had been approved. It was published as RFC, and so it's available as, use. And so this document now explains how to use that code point. It doesn't mandate it as all of the code points that are defined in this document. It explains that when you want to use ECDSA keys, when you want to use ML-DSA keys, here's how you would do it, and it comes with an example. But I think that's a valuable thing. So this is starting to, enable those kind of post quantum algorithms in a concrete way, and I think that's really valuable to have as a starting point. And this is not the end of the profile. The concept is that some later updates will expand the profile as needed. And then there were, some typos that were, corrected here, And there were existing considerations that are that are now consolidated into single section five, to explain why would you make any of these choices that are available in the context. So give some examples and and explanations. And this work has completed some level of interoperability testing specifically about the symmetric key use. So it's it's stable and mature enough. The thing that's missing from this slide is that, we now have a document shepherd, and we got some initial review. And there are tool IDNits, issues that were caught and need to be corrected. These are these are editorial things, but they're valuable to to work out. So that's the status of, Cozy context right now. Oh, the other thing is that there is now an additional implementation of the symmetric key part of this context that is gonna be released, this year as part of the, NASA funded, BPSec security library, and that has actually been pretty straightforward. It's another exercising in the mechanism, and we would welcome interoperability testing once we get to our testing phase, which is coming up this month or next month, I should say. And, the only other thing that was caught was that right now, there's no in document examples of using some more complex configurations, and it's just an open question of how deep and complex do the examples in the document need to be versus pointing somebody to something else. And this isn't unique to bpsec. It's not unique to COSE. It's just how how difficult and how complex do we want the document examples to be. Only because it's currently a 30 page appendix of of the simple examples. So I'll

[00:31:12] **Ed Birrane**: leave that to discussion. And

[00:31:20] **Brian Sipos**: then are there any questions on that cozy stuff? Okay. So it's in a good state. It's ready, I think, to progress to to more reviews. On the EID patterns, topic, this also is in a point where, it should be stable and complete, and there are some implementations, a few different variety of them. The last changes here were about adding concrete interoperability minimums to say, if if I'm conforming processor, I have to support at least, I forget the exact number, but ten ten number of something so that as a user, I should be able to give you six of these things and expect that your implementation is gonna work with it. There's some editorial, rework in section two one. And and then this document also has, specific operational considerations to explain existing, existing aspects just consolidated in a way that hopefully makes it easier to understand why would I wanna do x versus y. So at this point, I believe this document is is ready for a last call. It should be complete and consistent. And, if there are extra implementations of this thing, adding links would be helpful to know just to be able to judge. Does anybody wanna compare them and and try and throw the same data at them and get the same result?

[00:32:55] **Rick Taylor**: So, Brian, very quickly, yes. We have an implementation. It works. It's great. I totally agree. Hat off that this is ready for last call. It's it's been around for a number of iterations. I think it's ready.

[00:33:12] **Ed Birrane**: I I agree. I I would just take a moment while we are in in the meeting and say, does anyone have any concerns with the document as is or any concerns with putting it into last call? Alright. Well, we will take it to the mailing list then. Yep.

[00:33:31] **Brian Sipos**: Okay. Alright. Thank you about that. The next draft is the updated UDP CL. This is, at this point, pretty stabilized, and the last changes were were editorial, but they were useful in the sense of making sure that terminology has been updated and and consistent. There was a grouping to to be able to better explain what is in here. There's now a section grouping a couple of different internal mechanisms and calling the whole thing as UDPCL advertisement as a way of saying there are ways of getting things out of your node that will tell your neighbor how to communicate with you. This is explicitly meant to say, within the context of this CL protocol, not general purpose use, but it's very it's the thing that you need to the things that you would need to know to be able to do what you expect to do in modern networks, which is be able to operate two nodes together without having deep configuration on both sides, that all has to align up. There's also a recommendation, to reuse, local transport parameters where possible. And what this was lacking in the earlier experimental spec was these kind of concerns of being compatible with middle boxes, with firewalls, with NATs. These are things that a real implementation should be concerned with that they're nuances, but they are there are things that will stop kind of naive implementations from working properly. And that's the point of documenting some of this stuff. So it's not really a change of mechanism, but it's just making sure that, a user and operator is gonna do the right thing. And then this document also has a an explicit now section for operational considerations to explain why would I wanna use x versus y, why would I wanna turn something on or turn something off. And, this relocated appendix b has a choice of congestion control or a choice to not use congestion control. So that's all consolidated into this section four. There are remaining TBAs still in this document, for multicast assignments. That is something that, we'd requested early, allocation for. That request is still open, and I'm I'll reiterate it now. There are ways to request multicast assignments outside of the, early allocation, but it's a lot of extra paperwork that since we have a draft, we should be able to shortcut.

[00:36:26] **Rick Taylor**: Chair, interrupting. As our previous AD and our current AD is in the room, are we following the process correctly to get an early assignment for an IPv6 multicast address? Or were you asking for v four or v six?

[00:36:41] **Brian Sipos**: Both. Okay. One one of each.

[00:36:46] **Tommy Jensen**: If you'll give me a minute, I'll answer on chat. Oh, Tommy Jensen and JD. I'll answer on chat asymmetrically because I wanna go triple check what the bar is. If not, rest assured, I will help you out.

[00:36:59] **Rick Taylor**: Thank you. Okay. Thank you.

[00:37:03] **Brian Sipos**: And this is one of questions.

[00:37:05] **Rick Taylor**: From the chairs, does it? Yes. Thank you. That

[00:37:10] **Ed Birrane**: may have been the email I was talking to you about.

[00:37:14] **Brian Sipos**: Carry on, Brian. Yeah. So this is it's not preventing anything from happening, but having these assigned will help with inter operation, help with, you know, demonstrations just working out of the box more easily, which is the point of the early allocation. So this let me see. I don't have explicitly, next steps here, but this, I think, is is in the point where it's ready for, ready for a last call. Whether or not that should wait until after these TBAs are filled in, I don't have strong opinion on.

[00:37:51] **Rick Taylor**: I chair hat on. I know there are people actively implementing this right now. I know there is a lot of complexity within the operational side of this, hence the update from v one. I would like those implementations to complete and do a bit of shaking down just in case we find more operational problems. I don't wanna do a UDP CLV three. No. Just try and get this right. It seems to be mature enough that people are are building it. So

[00:38:23] **Brian Sipos**: Great. That's good to hear. And if there's any feedback, any links that we wanna put in, I'm happy to take that information.

[00:38:32] **Rick Taylor**: And, of course, the the the early IP multicast assignment would be useful as part of that. So yeah.

[00:38:37] **Brian Sipos**: Yeah. And and I think some of these mechanisms too are are really operational necessities that if you're if you're running on an uncontrolled network, you don't get to pick your your MTU. You have to figure out what it is. Even if somebody tells you what it is, it might not always be accurate. Okay. So I think the document's in a good state, and then we'll wait for feedback. And expecting not really to have edits until we get feedback. Now on the the secure advertisement and neighborhood discovery draft, I think the existing draft is in a good place to to get feedback. We do have some, recent information about, folks who are doing implementation, who are who are trying to figure out what is being explained here, and getting editorial information about that. That's really good to to have. What I expect will probably shake out of that feedback is, some of the existing capabilities will be reinforced and some might be deferred. The good news is for the structure of the the messages here, they're pretty open ended, extensible through registries. And if something like resource advertisement is deferred because we don't have a near term use case for it, That doesn't mean that the capability goes away. It just means it leaves this core document, and that follows the pattern of existing, mechanisms from other working groups and other protocols. So I don't think that's a problem in any way. It's just shaving down this core document to to be consistent and complete and what it needs to be. This does rely on, I'm gonna skip to the next slide. Oh, sorry. It does rely on the the UDPCL non experimental as being available. There's multicast as being possible for for blind advertisement. It does rely on EID patterns for for exposing registered endpoints and routing advertisements. This is where we could say, do we care enough about routing advertisements in the core spec that this needs to be kept in here or deferred? Those are, I think, open topics. And, Rick, I see you're in the queue.

[00:41:06] **Rick Taylor**: Yeah. Chair hat on to start with. Routing advertisements, we need to be a little bit careful about because we're not in the routing area, and that's that's a discussion we can we can have about taking it to the right place and managing that correctly. I I don't see a conflict. We just need to be careful. Off. I too am looking at routing advertisements in TPP, and that has to slightly restrict the EID patterns. So there has to be a subset of EID patterns that makes sense so that you get some semblance of prefix aggregation. So I'm happy to have a longer conversation offline with you about perhaps having a common EID pattern subset for for aggregatable prefix patterns and and referring it in both documents. I see this document as being dependent on UDPCL anyway, so it's a it's a slow burn. Let people shake out the bits, and maybe we'll we we can do a joint document about prefixes as part of that. Sure.

[00:42:10] **Brian Sipos**: And I think that whole the whole capability in here of the existing what's defined right now is this routing willingness thing. It could go away, and it doesn't Indeed. Affect any of the other capabilities. So this is the carving out that is that is necessarily gonna happen.

[00:42:28] **Rick Taylor**: Okay. We'll we'll take that to the list, and we'll we'll work our way forward.

[00:42:33] **Brian Sipos**: Sure. And the good thing is even taking a piece out of the document doesn't take a piece out of an implementation. It just means it gets deferred to somewhere else. Yep. So, the, the good thing is, on this, I heard, pretty recently, and I forwarded some information in the mailing list that the d three t n implementation, is including, starting trialing of of using this. And they have their own purposes, their own needs, their own constraints, and so that's gonna be useful feedback to reflect in the document. But the the most recent updates were really about, not capabilities, but about kind of, encoded structure. We got feedback good feedback that, the existing mechanism was a little oversimple and relied on some assumptions about how a, a conforming CBOR encoder would work. And while it's not harmful, technically, it doesn't really help. So the new encoding is to explicitly put things at the top of a message so that you know they're guaranteed to be at the top. And the the message structure, if you've looked at it or tried the implementation, the concept is that each message is its own byte string wrapped thing, so you can skip the ones that you don't care about. And the way that you know you don't care about them or care about them is now at the very top. It's guaranteed that the first less than four bytes of the message are gonna be the things that allow you to say, I care about it, decode it, or I don't care about it, ignore it. And some of the other structure was also just flattened to simplify. After the earlier structure, it was realized that there there was complexity that didn't need to be there, that was taken out. But that's that's a kind of useful iteration, of getting some experience doing it and then feeding it back into the definition. So this document still has, some TBAs. One of them is a a well known IPN service number. I am not against getting an early allocation on this. I don't this advertisement thing that that are gonna be infrequent and possibly large messages. So having a large service number doesn't really affect usability in this case. So I don't care if this is a one byte encoding or a three byte encoding or whatever. And, the other one that's TBA is this, multi multi point messaging IMC endpoint, which I was hoping would, shake out, more quickly than it has. I don't I don't know how much it's worth hinging this base spec on the availability of IMC.

[00:45:30] **Rick Taylor**: So the chairs will take an action to reach out to the authors. So that's Cameo. We know we know the team who are who are putting that together and and give them a poke. The good the good news is

[00:45:42] **Brian Sipos**: that we don't really care about the mechanism. We just care about the semantics of there isn't EID form that is gonna be usable. Yeah. As long as it's known that there is one, that's all that matters here.

[00:45:54] **Rick Taylor**: Yeah. Sorry. I may That's all. Used IMC and IAC. I can't remember which one Camille and his team were looking at and which one was was just eaten in that lot. We'll get it right. We'll get it.

[00:46:08] **Ed Birrane**: We can't move.

[00:46:11] **Brian Sipos**: So that's my time, and that's all I have.

[00:46:15] **Ed Birrane**: Alright. I I know we have, fourteen minutes left. So in the interest of time, why don't we move on to our last set of presentations, which are key management followed by SPAM. Is that right? Yeah.

[00:46:32] **Susan Tan**: Maybe we can do SPAM first since it's falls on the heels of Brian's

[00:46:36] **Rick Taylor**: Sure. Your choice.

[00:46:38] **Ed Birrane**: Yeah. Yep. Alright. We're here, and the clicker is yours. Wraps off.

[00:46:46] **Susan Tan**: Alright. Hi, everyone. I'm Susan Tan. This is joint work with The mic isn't the best. You need to be a little bit

[00:46:52] **Brian Sipos**: Oh, okay.

[00:46:53] **Susan Tan**: Hey. Hey, everyone. I'm Susan Tan. This is joint work with Ben, Bhagya, and Britta. So just to recap, what is SPAM? So currently, the way that bpsec works is that it allows you to have source added security operations and they go with the bundle until they reach the intended security destination. And what can happen here is that intermediates can intercept it and potentially modify security the security operations undetected. And so SPAM is trying to provide end to end cryptographic integrity for source added security operations so that you can at least detect that modification at the intended recipient. And so we do this in in using two mechanisms. One is the I'll go into details on the next slide. But these mechanisms that we use to enforce SPAM are going to be compatible with the manifest block work that Brian has been doing. And so we add two additional layers of integrity. One by reporting of intermediaries who are processing the security blocks, whether that's dropping them or adding new things. And then the other is to have an audit of the parameters and key information created by the source to be verified at the destination. And so the destination should be rejecting the the bundle if there's a failure in either of these components. So we we sent some feedback calls to the working group, and we incorporated a lot of the feedback. Thanks, Ed, for those suggestions. So we separated the discussion of the manifest block from the security mechanisms and the processing associated with it. We clarified that the audit and report blocks become critical blocks once they have been added to the bundle that aligns with the spirit of the intent of bpsec. And then condensed the design decisions to avoid unnecessary repetition of the existing b p sec content. And then we added an IANA consideration sections for key identifier, which actually was missing. So you you do need this key identifier to be able to have SPAM work because we have more than just one set of keys. And and then we aligned it with the manifest block architecture. So here, we're just we're just looking for working group adoption of this draft at this point. We think it's a good security addition to b p sec. And, yeah, that's it for SPAM.

[00:49:55] **Rick Taylor**: Very quick question with my chair hat on. What are the actual differences between the manifest block and the SPAM? And could we just combine them to have one block which does this purpose, or are they conceptually different in a way I don't understand? Obviously, you don't know what I don't understand. But

[00:50:13] **Susan Tan**: Yeah. So they're they're the the intent of the SPAM mechanism or or of the SPAM idea, I guess, fits into the manifest block. Yeah. So, like, I I guess you could combine it. Our our philosophy was to keep it separate so that it's an additional option that you can add and to be a little bit more modular in that in that way.

[00:50:52] **Rick Taylor**: Okay. I'm I'm just trying to think in terms of the poor implementers who are having to validate that all the blocks they expect are there through a manifest block and then validate that all the security operate okay. Yes. So the difference is the SPAM records the security it's an audit trail of the security operations that have occurred, which is different from an asset register of the extension blocks

[00:51:18] **Per Majon**: Yes.

[00:51:18] **Brian Sipos**: That are

[00:51:18] **Rick Taylor**: in it. Hence, the manifest. Thank you. That's what I don't understand.

[00:51:22] **Ed Birrane**: The binding to the manifest block is

[00:51:24] **Rick Taylor**: The manifest block is critical in order to understand that an SPAM is even there. Got it. Thank you.

[00:51:31] **Ed Birrane**: Since it's, with chair head on, a question, if anyone has read, the draft to date, and have any questions or concerns Or would want to mention any questions or concerns before we take anything to the mailing list? Okay? Let's get a list of that.

[00:51:51] **Rick Taylor**: I think

[00:51:51] **Ed Birrane**: it's useful. Alright. Thank you. And then we'll switch to Keith.

[00:51:54] **Susan Tan**: Sure. Yeah. Thank you.

[00:52:08] **Ed Birrane**: Getting there.

[00:52:12] **Rick Taylor**: The UI.

[00:52:13] **Susan Tan**: Alright. So this next body of work is with pretty much the same people, except also an additional master's student from Enable Postgraduate School, Paul Westland. Alright. Next slide. Oh, yeah. Have the clicker. Alright. So there are several existing and proposed security protocols that are used for space communications. So we have one, BPSEC, which is a non interactive integrated secure channel. And then we have quick, which is a interactive integrated integrated key establishment secure channel and transport protocol. And so these are some of the so a lot of I I wanted to avoid repetitious presentation of previous work. So a lot of you may have seen this, but for for those who haven't, here are some of the features that bpsec and QUIC have. So bpsec broadly, you know, has this confidentiality and integrity protected channel. We've analyzed it actually formally for its flexible notion of security, and you can find out more in that paper. And then, you know, it it although it doesn't require the use of pre shared symmetric keys, it it in practice, it's mostly deployed with that. And then in the default security context, that is kind of the the default. Right? So there are some problems with using pre shared keys if you're worried about potential compromises of said keys. And but, you know, it's widely used throughout NASA, ESA, and and some industry as well. K. Quick, you know, uses the TLS handshake. And that can also be a little bit problematic if you have long delays and and intermittent connectivity. And then there's a tendency to, you know, highlight, oh, hey. It has this really nice zero RTT transmission of encrypted data. But there's a there's some caveats to that, and it's highlighted in the TLS draft under the security considerations. So it's it's not as Just for time.

[00:54:18] **Rick Taylor**: Let's not go over quick in TLS.

[00:54:20] **Susan Tan**: Let's not go over it. Okay. Yeah. Yeah. So let's let's move on. So so, you know, here here are the the problems that I kind of already alluded to with both of these protocols. So we're suggesting to use MLS as a key exchange mechanism for space based communications. And this is because, one, MLS is a continuous key agreement protocol, meaning that it can it's a long lasting session. You can consider it like a long lasting session that continuously evolves the key state over time rather than having to, you know, tear down and and re re reestablish fresh keys. And then it allows for asynchronous key updates, which can be unidirectional and unilateral. And then it has the nice concepts of forward and post compromised security, which means that if your keys are compromised, your past previous communications are are unaffected and you can actually recover from this compromise in terms of the security of your channel via the the injection of fresh entropy. So in and it's also one of the few mechanisms that or few protocols that can be efficiently post quantum compatible. And what I mean by this is that you can amortize the cost of post quantum operations using MLS, and that can't be done through a protocol like TLS. So at a high level, this is what the integration looks like. So MLS for quick, we just essentially take the TLS handshake and insert MLS for the handshake. Now both of these both TLS and MLS have like its own record layer style components. We don't we don't touch those. We basically just swap out the handshake components. And then on the other side for b p sec, we basically create like an MLS daemon that can there's a a little bit of typo on here. That's my mistake. It has MLS messages being put into extensions. But in our implementation, we actually just inserted it into the payload. But essentially, you do all the MLS control messages through a bundle and you can get both end to end security in that respect or you can have your intermediaries be part of your group and you can essentially add all the intermediaries and have the full functionality of the current b p set construct allowing intermediaries to interact with with the the security operations as they traverse a network. Alright. So here's the here's some preliminary results from our implementation. So we we implemented Let's

[00:57:19] **Rick Taylor**: skip over quick. We we don't need to cover the quick MNS piece. Let's let's concentrate on the b p sec piece because there's there's other working groups looking at the quick MNS stuff.

[00:57:29] **Javier**: Okay.

[00:57:29] **Rick Taylor**: Sure.

[00:57:30] **Javier**: Yep.

[00:57:30] **Rick Taylor**: Sorry. I'm watching the clock. You've got three minutes.

[00:57:32] **Susan Tan**: Okay. Yeah. Yeah. Yeah. So I yeah. So okay. So in the b p so this this set of policy decisions actually matter both in QUIC and the QUIC implementation and the VP second implementation. And it's it's dealing with how you are doing group operations with MLS. So MLS has this ratchet tree concept. This is the cryptographic logical tree that is your essentially, your cryptographic state that every group member can compute. So, again, this is not like a network tree or anything like that. Don't think of it that way. This is something that is logically computed. So these connections in the tree are not physical connections to one another or anything like that. The intermediate nodes don't exist physically. These are state this is a state tree. And so when you start an MLS group, you can do it either having a concept of single additions to the group or you can do batch additions. If you do a single addition to the group, it kind of behaves like what I'm showing here through the through the steps here where b joins a tree joins a group, d joins a group, joins a group, and then h joins a group. And the tree actually gets more populated in this in this manner. But this means that you have to allow for the commits from each individual that joins the tree. And so that might not work for all sorts of scenarios operationally. So we kinda looked at the operational scenarios of a leader only commit, meaning you have, like, one controller, master controller of the group and you they're the only ones that can add or remove members from the group, control the frequency of key updates, etcetera. And so this offloads a lot of the overhead from subordinates to keep like to do bookkeeping essentially of like like who committed, when, and what order if the messages came out of order to process commits. But it prevents the subordinates from having PCS, that post compromised security ability, because they never ended up refreshing their own own nodes. And it also leads actually to the worst tree configuration as we'll see in in the results. And then there's a subordinate proposed leader commit. This is when you allow subordinates to propose changes to the to the tree, but the final say is in the leaders. And so this is, you know, some additional group sync overhead. It does give PCS and forward security for for all. But, again, it it it still leaves the tree in a in a pretty poor configuration. And then the final option is to actually allow all subordinates and any subordinates to make commits. This is certainly how MLS, you know, is intended to be used terrestrially in that if you have a large chat group, everyone should be updating frequently. But this is not necessarily the case in space missions where you have potentially ground stations doing a lot of the the the computing and and networking loads. So, you know, we we ended up actually looking at the the more, I guess, realistic case of option one, option two where you have more of a master controller situation going on. And so these are some of the results that we got. So on the top in the red, that's measuring the processing time, peak memory usage, you know, RAM essentially, and message size and bytes of members being or or groups being formed. So this is like a batch edition of the group. And so you would potentially probably do this on the ground before you launch. You join everyone in a group and then you send them up. Mhmm. And that's very realistic. And then in terms of the bottom three graphs here, it's showing the update costs, similarly measuring processing time, peak peak memory usage, and message size. So looking at option one there, the leader only kind of update that we see generally linear, stepwise linear kind of trend. And then for option three, this is where it gets a little bit interesting.

[01:02:01] **Rick Taylor**: I'm really sorry.

[01:02:03] **Per Majon**: We're gonna

[01:02:03] **Rick Taylor**: have to cut it because we're actually out of working.

[01:02:05] **Susan Tan**: Okay. I'm now. I'm sorry.

[01:02:06] **Ed Birrane**: Okay. I Do you wanna just get to

[01:02:08] **Susan Tan**: your last Yeah. Yeah. If you're interested in more of this, there's there's analysis on this. There's these are all the benefits essentially to doing MLS in b p sec and in in QUIC as well. There is some contention over this. So we we've have a a birds of a feather group current. Highly in encourage you guys to join that boff and provide your opinions on this if you are looking to do, you know, better security for DTN. And there's more information on all the papers supporting this work.

[01:02:48] **Ed Birrane**: Very very much, Susan. Thank you so much for that. The only reason we're cutting it off now is just we have a cutoff risk as we go too far beyond.

[01:02:55] **Rick Taylor**: Okay. Yeah.

[01:02:55] **Ed Birrane**: Thank you so much for presenting this work. Yep. Thank you. Brian, I see that you're in the queue, but perhaps we can take additional questions to the mailing list. Sure. Alright. We are at time. Thank you for second session, DTN working group, and we will see you in San Francisco.

[01:03:15] **Rick Taylor**: Well, we're thinking of going for two two hour slots simply because we have such a packed agenda, and we didn't get a chance to argue about quick CL and and many other topics. So please take your opinion to the mailing list. If you want more DTN or less, let us know. Who wouldn't want more? Otherwise, thanks very much, guys.

[01:03:37] **Ed Birrane**: Thank you all.

[01:03:45] **Rick Taylor**: Sorry? What? Yeah. Yeah. Yeah. Yeah. We've only just gone to two sessions, and we're running out of time. For real? Yeah. It's just insane. Season of Britain don't go. I wanna have a quick chat.