[Sis-dtn] BPv7 RIDs and Updates

[Vint Cerf]

Ack and thanks!

V

On Fri, Jun 28, 2024, 07:52 Felix Flentge <Felix.Flentge at esa.int> wrote:

> 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> 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
>
>
>
>
>
>
> 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/1290392c/attachment.htm>