Re: [dtn] BPbis - time units

["Burleigh, Scott C (US 312B)" <[e-mail]>]

I think this brings up a general point on immutability that I may have missed in the BPsec draft, beyond the representation of time values.

We all agree that the primary block must be immutable end-to-end, because otherwise its authenticity can't be protected by a BIB.  But does "immutable" mean "none of the bits in the block must ever change" or does it mean "the canonicalized representation of the block must always be the same"?  I can imagine a free-spirited implementation of BP inserting some leading zeroes into the representation of, say, the source EID's scheme code number; has immutability been violated in that event?

I suspect it has not, which suggests that maybe we need some language in the BPbis specification to say so.  If so, maybe the canonicalization language in BPsec needs to migrate to BPbis?  And if that is the case, then perhaps that general language addresses Ed's point?

That said, I am not an enthusiastic fan of making time representation in BP more complicated.  But if people feel that sub-second precision in time representation is going to be important, then I think this would be a reasonable approach.

Whatever we do, I think it is important to use the same mechanism (DTN time) for representation of all time values in BP blocks.

Scott

From: Taylor, Rick <[e-mail]>
Sent: Wednesday, July 29, 2020 8:38 AM
To: Birrane, Edward J. <[e-mail]>; [e-mail]; [e-mail]; Burleigh, Scott C (US 312B) <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] RE: [dtn] BPbis - time units

Airbus Amber
Ed,

You make a valid point re canonicalization and recoding, but given the stamps are in the immutable primary block, after the source has built the block, no matter the timeval encoding, they can't be changed, so I see this a non-issue - which normally means I've missed something... can you elaborate?

Cheers,

Rick

Rick Taylor
Product Design Authority, Mobile IP Node/PlexOS
Principal Engineer (eXpert), Mobile Communications
Airbus Defence and Space
Celtic Springs
Coedkernew
Newport
NP10 8FZ

Phone: [phone]
[e-mail]<mailto:[e-mail]>
www.airbusdefenceandspace.com<http://www.airbusdefenceandspace.com/>

From: dtn [mailto:[e-mail]] On Behalf Of Birrane, Edward J.
Sent: Wednesday, July 29, 2020 3:21 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; scott.c.burleigh=[e-mail]<mailto:scott.c.burleigh=[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [dtn] BPbis - time units

The primary block must remain immutable otherwise integrity mechanisms over the primary block will fail.

Specifically, if a source node creates a tag 1, some other waypoint node cannot recode it as a tag 1001 even if it represents the same data value (and vice versa).

If the WG allows flexibility for tag 1 vs tag 1001, text must be added which either (a) states that the representation (once encoded) never be changed or (b) defines an unambiguous canonicalization of the time value.

-Ed

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423<tel:(443)%20778-7423> / (F) 443-228-3839<tel:(443)%20228-3839>

From: dtn <[e-mail]<mailto:[e-mail]>> On Behalf Of Jeremy.Mayer@dlr..de<mailto:[e-mail]>
Sent: Wednesday, July 29, 2020 3:11 AM
To: [e-mail]<mailto:[e-mail]>; scott.c.burleigh=[e-mail]<mailto:scott.c.burleigh=[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT] Re: [dtn] BPbis - time units

APL external email warning: Verify sender [e-mail]<mailto:[e-mail]> before clicking links or attachments




Hi,

I think we need to allow some flexibility with regards to the expression of time units. For many applications, it should suffice to keep everything in milliseconds (keeping in mind that millisecond-based times also necessitate internal timekeeping capability with a similar accuracy. However, in long-delay/bandwidth-constrained applications, there may not be any real requirement to have millisecond-accuracy time fields/time-keeping.



Therefore, I propose (apologies in advance) that we use both: tag 1 can be a standard unix-based timestamp (in seconds), used for long-delay applications. Otherwise, times can be represented with tag 1001, key (-3,-18) as reference in Carstens CBOR timekeeping draft (https://www.ietf.org/id/draft-bormann-cbor-time-tag-03.txt) for additional flexibility in unit expression, with the slight overhead that may arise.



Thanks,

Jeremy

________________________________
From: dtn <[e-mail]<mailto:[e-mail]>> on behalf of Carsten Bormann <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 29, 2020 7:47:45 AM
To: Burleigh, Scott C (US 312B)
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [dtn] BPbis - time units

On 2020-07-29, at 03:09, Burleigh, Scott C (US 312B) <scott.c.burleigh=[e-mail]..org<mailto:scott.c.burleigh=[e-mail]>> wrote:
>
> Hi.  At IETF-108 there was discussion on whether BP time fields (e.g., bundle creation time, lifetime, bundle age) should be denominated in seconds, milliseconds, microseconds, or nanoseconds.  Version 26 of the BPbis I-D (now posted) revises all time field definitions to be denominated in milliseconds.

Note that CBOR has a choice of different time formats (tag 1, tag 1001), so if you want to provide a choice, you could allow the use of these in addition to assigning a default meaning to naked integers.  (These have a different epoch, but that is just a matter of subtracting a constant value; the representation needs one bit more which is making a difference between 2106 and 2030 next for whole seconds.)  Until 2106, tag 1 is shorter (6 bytes in total) than a naked integer in milliseconds (9 bytes).

(I don't have an opinion on the actual question, but here is some data for that.)

Grüße, Carsten

_______________________________________________
dtn mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dtn



THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.


This email and its attachments may contain confidential and/or privileged information.  If you have received them in error you must not use, copy or disclose their content to any person..  Please notify the sender immediately and then delete this email from your system.  This e-mail has been scanned for viruses, but it is the responsibility of the recipient to conduct their own security measures. Airbus Operations Limited is not liable for any loss or damage arising from the receipt or use of this e-mail.

Airbus Operations Limited, a company registered in England and Wales, registration number, 3468788.  Registered office:  Pegasus House, Aerospace Avenue, Filton, Bristol, BS34 7PA, UK.