[Sis-dtn] BPv7 RIDs and Updates

[Vint Cerf]

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> 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> *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
> *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).
> _______________________________________________
> SIS-DTN mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240628/159335a9/attachment.htm>