Subject: [dtn] BPbis - time units

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 29 Jul 2020 01:09:05 +0000

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.  Is this the best way forward?  It would be helpful to discover the WG consensus on this matter.

Please use this thread for your comments.

Scott

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jul 2020 07:47:45 +0200

On 2020-07-29, at 03:09, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> 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

---

From: <[email-masked]>
Date: Wed, 29 Jul 2020 07:11:18 +0000

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 <[email-masked]> on behalf of Carsten Bormann <[email-masked]>
Sent: Wednesday, July 29, 2020 7:47:45 AM
To: Burleigh, Scott C (US 312B)
Cc: [email-masked]
Subject: Re: [dtn] BPbis - time units

Grüße, Carsten

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 29 Jul 2020 14:20:55 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, July 29, 2020 3:11 AM
To: [email-masked]; scott.c.burleigh=[email-masked]
Cc: [email-masked]
Subject: [EXT] Re: [dtn] BPbis - time units

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

Hi,

Thanks,

Jeremy

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

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

Grüße, Carsten

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

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 29 Jul 2020 15:38:28 +0000

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: +44 (0) 1633 71 5637
[email-masked]<mailto:[email-masked]>
www.airbusdefenceandspace.com<http://www.airbusdefenceandspace.com/>

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

-Ed

From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, July 29, 2020 3:11 AM
To: [email-masked]<mailto:[email-masked]>; scott.c.burleigh=[email-masked]<mailto:scott.c.burleigh=[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXT] Re: [dtn] BPbis - time units

Hi,

Thanks,

Jeremy

Grüße, Carsten

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.

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 29 Jul 2020 16:13:24 +0000

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 <[email-masked]>
Sent: Wednesday, July 29, 2020 8:38 AM
To: Birrane, Edward J. <[email-masked]>; [email-masked]; [email-masked]; Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] RE: [dtn] BPbis - time units

Airbus Amber
Ed,

Cheers,

Rick

Rick Taylor

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; scott.c.burleigh=[email-masked]<mailto:scott.c.burleigh=[email-masked]>

-Ed

From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeremy.Mayer@dlr..de<mailto:[email-masked]>

Hi,

Thanks,

Jeremy

Grüße, Carsten

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.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 29 Jul 2020 16:14:24 +0000

Rick,

  BPbis states that the primary block shall be immutable, and then provides a definition of immutability (from section 4.2.2):

The primary block of each bundle SHALL be immutable.  The values of
   all fields in the primary block must remain unchanged from the time
   the block is created to the time it is delivered.

If we allow flexible time representation, an implementation could say "I, and all downstream from me, prefer milliseconds" and then recode time values in primary blocks from seconds to milliseconds in a well-intentioned attempt to speedup some processing thinking they met the standard of immutability presented in section 4.2.2 because the semantic time value was unchanged.

The text should probably say "the encoded values of all fields in the primary block must remain unchanged...". Hopefully that is a small and not controversial clarification.

To your point - that may be obvious. But we have seen a similar issue with BPAs recoding fixed-width representations to compact representations in the past...

-Ed

From: Taylor, Rick <[email-masked]>
Sent: Wednesday, July 29, 2020 11:38 AM
To: Birrane, Edward J. <[email-masked]>; [email-masked]; [email-masked]; scott.c.burleigh=[email-masked]
Cc: [email-masked]
Subject: [EXT] RE: [dtn] BPbis - time units

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

Airbus Amber
Ed,

Cheers,

Rick

Rick Taylor

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; scott.c.burleigh=[email-masked]<mailto:scott.c.burleigh=[email-masked]>

-Ed

Hi,

Thanks,

Jeremy

Grüße, Carsten

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 29 Jul 2020 16:25:08 +0000

Comments inline.

[EJB] Agree that BPAs may want to "harmlessly recode" values especially to reduce processing downstream for higher rate applications. Which seems like a use case to consider while talking about millisecond and microsecond timing precision.

[EJB] I think this is the issue - semantic immutability versus syntactic immutability.  Specifying a canonical form for the primary block and extension block headers would be one way to solve this. Prohibiting recoding would be another.

---

From: "R. Atkinson" <[email-masked]>
Date: Wed, 29 Jul 2020 14:29:30 -0400

Apologies for the top post, but my general take would be:

1. BPsec needs to be _crystal_ clear on precisely how integrity/authentication is calculated.  Any vagueness or ambiguity will lead to non-interoperability problems.

2. If that calculation is done on a “canonicalized representation”, then the BPsec document also needs to be crystal clear on precisely how to take an arbitrary block and put it into “canonical form”.

3. I strongly agree with this sentence from below and would further say that the BP-related specifications also need to be crystal clear on both calculation of time values and also on the on-the-wire format of time values.

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

Ran

> On Jul 29, 2020, at 12:13, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> wrote:
> 
> 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?
> 
> 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
> 
> [email-masked]
> www.airbusdefenceandspace.com
> 
>  
> 
> To: [email-masked]; [email-masked]; scott.c.burleigh=[email-masked]
> Cc: [email-masked]
> (W) 443-778-7423 / (F) 443-228-3839
> 
>  
> 
> From: dtn <[email-masked]> On Behalf Of Jeremy.Mayer@dlr...de
> APL external email warning: Verify sender [email-masked] before clicking links or attachments
> 
>  
> 
> Hi,
> 
> On 2020-07-29, at 03:09, Burleigh, Scott C (US 312B)scott.c.burleigh=[email-masked]..org> wrote:
> >

---

From: "R. Atkinson" <[email-masked]>
Date: Wed, 29 Jul 2020 14:34:15 -0400

> On Jul 29, 2020, at 12:14, Birrane, Edward J. <[email-masked]> wrote:
> 
> Rick,
>  
> If we allow flexible time representation, an implementation could say “I, and all downstream from me, prefer milliseconds” and then recode time values in primary blocks from seconds to milliseconds in a well-intentioned attempt to speedup some processing thinking they met the standard of immutability presented in section 4.2.2 because the semantic time value was unchanged.
>  
> The text should probably say “the encoded values of all fields in the primary block must remain unchanged…”. Hopefully that is a small and not controversial clarification.

All,

If “encoded values” above means in the on-the-wire bit stream, I am fine with that.  

I really think that both semantics of the bits and the on-the-wire format of that time need to be (a) clearly defined and (b) the same end-to-end.  

Put another way:

If the source  is using seconds and it is converted during transit to the destination into milliseconds, then I would expect an integrity/authentication failure at the recipient.

Yours,

Ran