[Sis-dtn] [EXTERNAL] [BULK] Re: Proposed topics for the weekly meetings

Thu Jun 27 12:41:03 UTC 2024

Dear Vint et al,

The creation timestamp’s sequence number is qualified by the bundle creation time so that combination of source Node ID and bundle creation timestamp can uniquely identify a single transmission request. Resetting the sequence counter may be done when the ‘current time’ advances by one millisecond. If nodes ‘lack an accurate clock’ it is recommended to set the creation time to zero and never reset.
So, certainly there could  be situations where time could ‘go backwards’ (eg, during time synchronisation). These need to be carefully managed and resetting the counter every millisecond might not be the best strategy. However, my point below for the CCSDS Blue Book is just to make sure that we do not deviate from RfC 9171 wrt the sequence number and create certain expectations which may not be true. Whether this resetting should be allowed or not is a different discussion and should be brought up in IETF DTN WG if there is an intention to change this. Personally, I would prefer to have an increasing sequence count with ‘predictable’ roll-over behaviour.

Regarding replay attacks: even in nominal circumstances we could have bundle duplications and out-of-order delivery. So, applications need to be able to deal with that or they need make use of suitable bundle protocol extensions to eg guarantee in-order-delivery and de-duplication. These extension could make use of suitable mechanisms (eg by using sequence counters in extension blocks; this is actually part of the new compressed status reporting and custody transfer Orange Book we are working on).

Good point on replay attacks: I think similar to other types of attacks, we will need network security monitoring to detect attacks and take appropriate measures to ‘take the attacker off the network’ and delete suspicious bundles. This is certainly an important topic for future research (I will hint this to our security people who are already working on anomaly detection).

Regards,
Felix

From: Vint Cerf <vint at google.com>
Sent: Thursday, June 27, 2024 12:20 PM
To: Felix Flentge <Felix.Flentge at esa.int>
Cc: Tomaso.deCola at dlr.de; jonathan.w.jackson at nasa.gov; simon.singh at nasa.gov; durst at mitre.org; sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXTERNAL] [BULK] Re: Proposed topics for the weekly meetings

Folks, I wonder whether any of you are aware of the reason TCP has a 3-way handshake? In the original version of TCP, we started each new TCP connection with a sequence number of 0. The consequence of that is that old packets from earlier connections could show up and be incorrectly accepted as valid. We changed to start each connection with a timer-based sequence number and a 3-way exchange to assure that both ends had the other end's starting sequence number. Frequent resetting to 0 may induce this problem with BP.

We also ran into a "predict the next sequence number and generate an IP packet that will be falsely accepted as valid" problem.   We should also ask whether we have proof against replay attacks. I hope there has been some work to analyze BP for resistance to some of these well-known problems that arose in TCP/IP.

vint

On Thu, Jun 27, 2024 at 5:45 AM Felix Flentge via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>> wrote:
Dear All,

I have reviewed the list and I would think that all modifications are covered by RIDs.

However, I have some small issue with the resolution of RID 115 (sorry, if I have missed the discussion on that one):

The proposal is to change the wording of the section on creation time stamp to
“The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. The sequence number shall be a global counter that monotonically increases across all services registered to the bpa.”

Creation timestamp seems adequately defined in RfC 9171 and I don’t think that the clarification is necessary. On the contrary it is limited to IPN naming (or other schemes which introduce a service number) and I don’t think that formally services are registered with a bpa. Furthermore, if we want to be more explicit, we need to mention the option to reset the sequence counter to 0 every milliseconds (yes, I know that some people want to require not to do that but I don’t think we have agreed to this deviation from RfC 9171).

So, I would propose to a) either keep the current text (preferred) or b) add a Note like:

“A single creation timestamp sequence number is managed per node. The creation timestamp sequence number may be reset zero whenever the current time advances by one millisecond.”

Regards,
Felix

From: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Sent: Thursday, June 6, 2024 5:14 PM
To: jonathan.w.jackson at nasa.gov<mailto:jonathan.w.jackson at nasa.gov>; simon.singh at nasa.gov<mailto:simon.singh at nasa.gov>; durst at mitre.org<mailto:durst at mitre.org>; Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: AW: [Sis-dtn] [EXTERNAL] [BULK] Re: Proposed topics for the weekly meetings

Personally I’d say that the need for an additional agency review arises in the case the modifications introduced in the spec go beyond what requested in RIDs, e.g., if you add new text in the specification through new clauses or alike that are not the result of any RIDs then I see necessary to go for agency review. If on the contrary all modifications entered are in response to specific RIDs, probably no agency review is necessary.

My 0.02 cents,
Tomaso

Von: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> Im Auftrag von Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN
Gesendet: Donnerstag, 6. Juni 2024 16:16
An: Singh, Somendra {Simon} (GSFC-5820) <simon.singh at nasa.gov<mailto:simon.singh at nasa.gov>>; Robert C Durst <durst at mitre.org<mailto:durst at mitre.org>>; Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Betreff: Re: [Sis-dtn] [EXTERNAL] [BULK] Re: Proposed topics for the weekly meetings

Hello All,

I have a conflict and will not be able to attend the WG tag today.
We discussed potentially reviewing the RIDs to determine if another agency review is warranted or not.

I’ve attached the latest RID spreadsheet I used to track changes for reference…if this topic makes the cut.

Thanks,
Jonathan

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Singh, Somendra {Simon} (GSFC-5820) via SIS-DTN
Sent: Wednesday, May 29, 2024 9:14 AM
To: Robert C Durst <durst at mitre.org<mailto:durst at mitre.org>>; Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: Re: [Sis-dtn] [EXTERNAL] [BULK] Re: Proposed topics for the weekly meetings

Hi Bob,

I would prefer to keep the meeting for tomorrow. We have some issues that we would like to discuss, assuming that at least folks from APL, MSFC and others may join the meeting.

I am also looking for the latest draft for HPRP, so if anybody can point me to it. Thanks

Best regards
Simon Singh
Simon.Singh at nasa.gov<mailto:Simon.Singh at nasa.gov>
443 538 7176<tel:(443)%20538-7176> c

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Robert C Durst via SIS-DTN
Sent: Wednesday, May 29, 2024 9:30 AM
To: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: [EXTERNAL] [BULK] Re: [Sis-dtn] Proposed topics for the weekly meetings

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

Felix, Keith

From my perspective, these look very good.

I’m still waiting for a contract from NASA, so I’m unable to participate until that happens, although I’m hoping that will be resolved soon-ish (hope springs eternal).  (And I’ll be on personal holiday tomorrow through next Tuesday.)

Given that ESA/DLR is on holiday tomorrow and I believe that there’s a momentary hiccup in JPL funding, do you (each) think it makes sense to scrub tomorrow’s call?

Best,
Bob

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Felix Flentge via SIS-DTN
Sent: Wednesday, May 29, 2024 9:08 AM
To: Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Cc: Jeremy Pierce Mayer <jpmayer at gmv.com<mailto:jpmayer at gmv.com>>
Subject: [EXT] [Sis-dtn] Proposed topics for the weekly meetings

Dear All, I would like to propose the following dedicated topics for the upcoming weekly meetings. 6 June: DTN Reference Scenarios for Earth Observation, Lunar and Mars 20 June: HPRP (Jeremy, I hope). On 30th May is another holiday in Germany;

Dear All,

I would like to propose the following dedicated topics for the upcoming weekly meetings.

6 June: DTN Reference Scenarios for Earth Observation, Lunar and Mars
20 June: HPRP (Jeremy, I hope).

On 30th May is another holiday in Germany; on 13th June we have the European Mission Operations Data System Architecture Workshop at ESOC, so there will also not be too much ESA participation.

Regards,
Felix

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn

--
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346

until further notice

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240627/93309cb9/attachment-0001.htm>