[Sis-dtn] BPv7 RIDs and Updates

Fri Jun 28 11:52:38 UTC 2024

Yes,

The sequence counter is necessary to distinguish bundles created with the same DTN time and the same source node ID. It cannot be used to assert the validity of a bundle (which could be done with BPSEC BIB).

BP implementations and/or applications using BP need to be able to deal with duplicate bundles (e.g., copies of a bundle forwarded via different routes; re-transmission of bundles which appeared to be lost). So, to me the worrying aspect of replay attacks would be denial-of-service which we could try to counter with network security monitoring.

Regards,
Felix

From: Vint Cerf <vint at google.com>
Sent: Friday, June 28, 2024 1:00 PM
To: Felix Flentge <Felix.Flentge at esa.int>
Cc: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] <jonathan.w.jackson at nasa.gov>; sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] BPv7 RIDs and Updates

Felix, I just realized that I conflated sequence counter and timestamp handling. My understanding now is that what is thought to be unique about a packet's identification is the combination of time-stamp/node ID/sequence number within a time-interval which might be as short as 1 millisecond. As long as the rate at which bundles are produced does not exceed the value the sequence counter can reach over the course of a millisecond (or more?), this identification will be unique. Assuming that understanding is correct, then we still need to think through predictive attacks (generate a bundle that will appear to be valid based on identification) and replay attacks.  Does this sound like a correct understanding?

vint

On Fri, Jun 28, 2024 at 2:23 AM Felix Flentge via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>> wrote:
Hi,

I would propose the following wording (making clear that we are not deviating from RfC 9171 and aligning terminology):

NOTE: Implementations may choose to use to manage a single, global timestamp sequence counter or manage individual timestamp sequence counters for disjunct sets of source node IDs . Sequence counters may be reset to zero whenever the current time advances by one millisecond. The combination of source node ID and bundle creation time stamp can serve as a unique ID for an individual bundle.

Regards,
Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN
Sent: Thursday, June 27, 2024 6:44 PM
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [Sis-dtn] BPv7 RIDs and Updates
Importance: High

Hello All,

Attached is the updated BPv7 book and RID spreadsheet for Final Reviews.
We’ve drafted the following note for RID 115 based on our discussion during today’s telecon:

RID#
Paragraph Number
RID Short Title
From
To
Supporting Analysis
115
4.3.4
Creation Timestamp Sequence Number Clarification
The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number.
The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number.

NOTE: Implementations may choose to use the source node id and the creation timestamp sequence number. However, a global counter or a separate counter for each fully qualified source node ID is possible.
Without this wording there is enough ambiguity to allow for implementors to either associate the sequence number of the creation timestamp to a global counter which is the intent or on a per service basis potentially leading to unintended behavior.

Please let me know if you have any comments or questions.

Thanks,
Jonathan
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/20240628/efb69d5c/attachment-0001.htm>