Subject: Re: [dtn] Internet Draft for Bundle Security

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Jan 2015 20:31:55 +0000

Hi Ed,

Aside from the new document name and date, I see only a single sentence
in the abstract as having changed from the previous version. Any plans to
submit further changes in the near future?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Birrane, Edward J.
> Sent: Tuesday, December 30, 2014 10:18 AM
> To: [email-masked]
> Subject: [dtn] Internet Draft for Bundle Security
> 
> DTNWG,
> 
>   The internet-draft for the Streamlined Bundle Security Protocol just expired from the DTNRG.  I have resubmitted the draft for
> consideration by the DTN WG as "draft-birrane-dtn-sbsp-00.txt" (please see the e-mail below).
> 
>   I am hoping this document can inform the WG on discussions around security services for bundle blocks.
> 
> -Ed
> 
> ---
> Edward J. Birrane, III, Ph.D.
> Supervisor, Embedded Applications Group
> Principal Professional Staff, Space Exploration Sector
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 / (F) 443-228-3839
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, December 30, 2014 1:12 PM
> > To: Birrane, Edward J.; Birrane, Edward J.
> > Subject: New Version Notification for draft-birrane-dtn-sbsp-00.txt
> >
> >
> > A new version of I-D, draft-birrane-dtn-sbsp-00.txt has been successfully
> > submitted by Edward J. Birrane and posted to the IETF repository.
> >
> > Name:		draft-birrane-dtn-sbsp
> > Revision:	00
> > Title:		Streamlined Bundle Security Protocol Specification
> > Document date:	2014-12-30
> > Group:		Individual Submission
> > Pages:		34
> > URL:            http://www.ietf.org/internet-drafts/draft-birrane-dtn-sbsp-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-birrane-dtn-sbsp/
> > Htmlized:       http://tools.ietf.org/html/draft-birrane-dtn-sbsp-00
> >
> >
> > Abstract:
> >    This document defines a streamlined bundle security protocol, which
> >    provides data authentication, integrity, and confidentiality services
> >    for the Bundle Protocol.  Capabilities are provided to protect blocks
> >    in a bundle along a single path through a network.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: "Birrane, Edward J." <[email-masked]>
Date: Mon, 5 Jan 2015 21:54:52 +0000

Fred,

  Since the DTN IRTF internet draft had expired, and the DTN WG was considering security, I thought it useful to move the document over. 

  Regarding potential areas of change:

  - There was some discussion on whether we could be more inclusive of proactive fragmentation, but there was no satisfactory conclusion there. 

  - There was some discussion on support for block-in-block encapsulation schemes, key dictionaries, and support for parallel authenticators but these items were all generally considered too much complexity for too little gain.

  - One change that should be made is to replace the custom block-identification mechanism in SBSP (used to identify the security target) with whatever block identification mechanism is adopted in any follow-on to RFC5050.  However, we can't make that change to SBSP until we know how we will be uniquely identifying extension blocks in BP.

  - There is an open question regarding whether a security specification should exist separate from a BP specification. My opinion is that we should treat these items separately, but that's probably a list discussion.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> From: dtn [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Monday, January 05, 2015 3:32 PM
> To: Birrane, Edward J.; [email-masked]
> Subject: Re: [dtn] Internet Draft for Bundle Security
> 
> Hi Ed,
> 
> Aside from the new document name and date, I see only a single sentence in
> the abstract as having changed from the previous version. Any plans to
> >   The internet-draft for the Streamlined Bundle Security Protocol just
> > expired from the DTNRG.  I have resubmitted the draft for consideration by
> the DTN WG as "draft-birrane-dtn-sbsp-00.txt" (please see the e-mail
> below).
> >
> > Supervisor, Embedded Applications Group Principal Professional Staff,
> > Space Exploration Sector Johns Hopkins Applied Physics Laboratory
> > > A new version of I-D, draft-birrane-dtn-sbsp-00.txt has been
> > > successfully submitted by Edward J. Birrane and posted to the IETF
> repository.
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> tools.ietf.org.
> > >
> > > The IETF Secretariat
> >

---

From: "Will Ivancic" <[email-masked]>
Date: Mon, 5 Jan 2015 21:20:31 -0500

IMHO, if we are going to allow for large bundles, the security MUST work
with reactive fragmentation, at least on the header.

Will

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Birrane, Edward J.
Sent: Monday, January 5, 2015 4:55 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Internet Draft for Bundle Security

Fred,

  Since the DTN IRTF internet draft had expired, and the DTN WG was
considering security, I thought it useful to move the document over. 

  - There was some discussion on whether we could be more inclusive of
proactive fragmentation, but there was no satisfactory conclusion there. 

  - There was some discussion on support for block-in-block encapsulation
schemes, key dictionaries, and support for parallel authenticators but these
items were all generally considered too much complexity for too little gain.

  - One change that should be made is to replace the custom
block-identification mechanism in SBSP (used to identify the security
target) with whatever block identification mechanism is adopted in any
follow-on to RFC5050.  However, we can't make that change to SBSP until we
know how we will be uniquely identifying extension blocks in BP.

  - There is an open question regarding whether a security specification
should exist separate from a BP specification. My opinion is that we should
treat these items separately, but that's probably a list discussion.

-Ed

---

---

From: Eric Travis <[email-masked]>
Date: Mon, 5 Jan 2015 23:15:13 -0500

> with reactive fragmentation, at least on the header.
"large" is subjective (in this context, related to the expected contact
period durations for a particular deployment).

While I can think of at least several reasons why I may WANT fragmentation
as part of the bundle abstraction,
I'd be interested to hear arguments for NEED.   If fragmentation is taken
out of bundling, bundling gets simpler.

Eric

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 6 Jan 2015 05:48:12 +0000

I disagree, Will.  I do think there are important use cases that require fragmentation (for example, large application data units that need to be transmitted in pieces over multiple contacts of limited capacity).  But I think we can satisfy each such case by doing proactive fragmentation at the moment of transmission rather than reactive fragmentation at the moment of connectivity loss.  This is much simpler, requiring much less convergence-layer protocol support and enabling us to write comprehensible rules for how to handle extension blocks in fragments, and it has the added advantage of making it possible to authenticate all bundles rather than only those that were not truncated during transmission.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Will Ivancic
Sent: Monday, January 05, 2015 6:21 PM
To: 'Birrane, Edward J.'; 'Templin, Fred L'; [email-masked]
Subject: Re: [dtn] Internet Draft for Bundle Security

IMHO, if we are going to allow for large bundles, the security MUST work with reactive fragmentation, at least on the header.

Will

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Birrane, Edward J.
Sent: Monday, January 5, 2015 4:55 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Internet Draft for Bundle Security

Fred,

  - One change that should be made is to replace the custom block-identification mechanism in SBSP (used to identify the security
target) with whatever block identification mechanism is adopted in any follow-on to RFC5050.  However, we can't make that change to SBSP until we know how we will be uniquely identifying extension blocks in BP.

-Ed

---

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Tue, 6 Jan 2015 13:39:20 +0000

Eric, I don't disagree.  In fact, I asked the question a while back (a month or two ago) whether bundles should be limited in size thus resulting in no fragmentation. There was discussion  (I think during the last virtual meeting).  Various Information Centric Networking concepts limit the size of information chunks and have sequencing numbers to put the large information sets back together.  If I understood correctly, the consensus was to not limit bundle sizes.  Thus, bundles can be terabytes or larger.  There is no limit.  I believe the comment was that the original Bundling concept held that a bundle is considered one data unit.

Scott proposes the following:  "I disagree, Will.  I do think there are important use cases that require fragmentation (for example, large application data units that need to be transmitted in pieces over multiple contacts of limited capacity).  But I think we can satisfy each such case by doing proactive fragmentation at the moment of transmission rather than reactive fragmentation at the moment of connectivity loss."

However, how one does this in an opportunistic setting where one does not know the contact time, who may be the next contact  or transmission rate is something I don't understand. Do we need a seer protocol to go with proactive fragmentation?

Will

From: Eric Travis <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 5, 2015 11:15 PM
To: Will Ivancic <[email-masked]<mailto:[email-masked]>>
Cc: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Birrane, Edward J." <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Internet Draft for Bundle Security

On Mon, Jan 5, 2015 at 9:20 PM, Will Ivancic <[email-masked]<mailto:[email-masked]>> wrote:
IMHO, if we are going to allow for large bundles, the security MUST work
with reactive fragmentation, at least on the header.

Will

"large" is subjective (in this context, related to the expected contact period durations for a particular deployment).

While I can think of at least several reasons why I may WANT fragmentation as part of the bundle abstraction,
I'd be interested to hear arguments for NEED.   If fragmentation is taken out of bundling, bundling gets simpler.

Eric

---

From: "Juan A. Fraire" <[email-masked]>
Date: Tue, 6 Jan 2015 12:45:45 -0300

Hi all,

It is computationally more efficient to manage a single bundle than many of
them, therefore, fragmentation has an impact in performance. Non-DTN
protocol implementations evolved through years to optimize fragment
processing, and DTN will perform on top of them (upper bound) by means of
CLAs. The question I make myself is if we want or need to duplicate the
fragmentation feature.

I disagree that simple choosing a fragment size according to the length of
contacts will make proactive fragmentation the best candidate. This is not
a straightforward matter as a set of contacts in a given path do not
necessarily are of the same size. Even worst, the effective contact time
not only depends on the real contact time-frame but also on the traffic
flowing from other nodes. IMHO, I feel that determining a fixed fragment
size will always be imperfect and will impose an overhead both in
processing and network level performance. On the other hand, I'm aware that
implementing reactive fragmentation can be challenging and, at some point,
hacks the stack simplicity and elegance.

In my opinion, this long-lived discussion can be settled by selecting *stack
simplicity* or *optimization opportunity* as a high-level criteria for DTN.

Regards,

J.Fraire

On Tue, Jan 6, 2015 at 10:39 AM, Ivancic, William D. (GRC-LCA0) <
[email-masked]> wrote:

>  Eric, I don't disagree.  In fact, I asked the question a while back (a
> month or two ago) whether bundles should be limited in size thus resulting
> in no fragmentation. There was discussion  (I think during the last virtual
> meeting).  Various Information Centric Networking concepts limit the size
> of information chunks and have sequencing numbers to put the large
> information sets back together.  If I understood correctly, the consensus
> was to not limit bundle sizes.  Thus, bundles can be terabytes or larger.
> There is no limit.  I believe the comment was that the original Bundling
> concept held that a bundle is considered one data unit.
>
>  Scott proposes the following:  "I disagree, Will.  I do think there are
> important use cases that require fragmentation (for example, large
> application data units that need to be transmitted in pieces over multiple
> contacts of limited capacity).  But I think we can satisfy each such case
> by doing proactive fragmentation at the moment of transmission rather than
> reactive fragmentation at the moment of connectivity loss."
>
>  However, how one does this in an opportunistic setting where one does
> not know the contact time, who may be the next contact  or transmission
> rate is something I don't understand. Do we need a seer protocol to go with
> proactive fragmentation?
>
>  Will
>
>   From: Eric Travis <[email-masked]>
> To: Will Ivancic <[email-masked]>
> Cc: "Templin, Fred L" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "Birrane, Edward J." <[email-masked]>
> On Mon, Jan 5, 2015 at 9:20 PM, Will Ivancic <
> [email-masked]> wrote:
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 6 Jan 2015 15:51:09 +0000

Good question, but I don't think it's that difficult.  During any period of contact there's plenty we don't know, but we do know the local node's own transmission rate in bits per second.  A simple approach is to fragment the outgoing bundle into chunks such that each fragment's payload represents one second's worth of transmission at the current transmission rate.  In that case, no matter when the connection is lost you have wasted at most one second of transmission - one second's worth of data that needs to be transmitted at the next contact opportunity.

This is of course an extreme; depending on your expectations of the link's volatility and how much you are willing to risk having to retransmit, you might increase your chunk size to five second's worth of transmission, or sixty.  The main point is that you avoid all of the ever-burgeoning complexity of reactive fragmentation, greatly simplifying DTN.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Tuesday, January 6, 2015 5:39 AM
To: Eric Travis; Will Ivancic
Cc: Templin, Fred L; [email-masked]; Birrane, Edward J.
Subject: Re: [dtn] Internet Draft for Bundle Security

Will

Will

Eric

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 6 Jan 2015 16:46:30 +0000

Fragmentation can be applied in one of three levels:
- Above the BPA (applications)
- The BPA
- Below the BPA (convergence layers)

My intuition is that:

- Applications should not be required to do their own anti-fragmentation payload sizing as they have no insight into the dynamics or MTUs of the federated networks comprising the overlay.

- The BPA should handle proactive fragmentation as there are times when it is more efficient to fit a smaller bundle into remaining transmission time, or when crossing network/MTU boundaries, or according to some measurements (as Scott proposed). Since the application can't provide basic fragmentation, the BPA should.

- Specific CLs should be deployed in those extremely chaotic environments where most of the messages are lost and you rarely get a full anything and you need to build up messages bit-by-excruciatingly-received-bit. The overlay should not have to support reactive fragmentation because many overlays never need it.

Per-deployment policies for timeouts, maximum bundle sizes, etc... can be tuned for performance but I would not know where to begin to set some sensible upper or lower limit on them in a BP spec. Perhaps the BPA could support configurable settings for maximum and minimum bundle sizes (pass no bundle outside of these sizes). The main issue with arbitrarily large bundles is when I attack my embedded device with a petabyte bundle of death that promises a small signature at the end.

It would also be nice to more firmly assert in a BP spec what the BPA assumes/requires from a supporting CLA.

-Ed
---

From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: Tuesday, January 06, 2015 10:51 AM
To: [email-masked]
Subject: Re: [dtn] Internet Draft for Bundle Security

Scott

Cc: Templin, Fred L; [email-masked]<mailto:[email-masked]>; Birrane, Edward J.

Will

Will

Eric

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 6 Jan 2015 17:07:48 +0000

I agree with all this, except that I have a somewhat sunnier view of the fragmentation/reassembly/timeout/retransmission that goes on at the convergence layer: both TCP and LTP at the convergence layer provide quite good environment-specific per-deployment policies, under both stable and chaotic conditions, largely freeing BP from having to sweat these details.  I think even the petabyte bundle of death holds no terrors for us if we proactively fragment; little nibbles of the PBOD will make their way through the network, all in good time.

Scott

From: Birrane, Edward J. [mailto:[email-masked]]
Sent: Tuesday, January 6, 2015 8:47 AM
To: Burleigh, Scott C (312B); [email-masked]
Subject: RE: [dtn] Internet Draft for Bundle Security

My intuition is that:

-Ed

---

From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: Tuesday, January 06, 2015 10:51 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Internet Draft for Bundle Security

Scott

Will

Will

Eric

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Jan 2015 21:49:47 +0000

I think I am with Scott on proactive vs. reactive fragmentation. Throwing away good data
at the destination seems wasteful on the surface, but in practical applications how short
of a contact time should we reasonably expect? Even for opportunistic contacts, I am not
aware of use cases where communication opportunities are sub-second. Or, if there are
such cases, can proactive fragmentation intervals be tuned for the specific environment?
For example, that is why protocols like IPv6 Neighbor Discovery recommend conservative
default protocol constant values but allow network engineers to set different values
according to the performance characteristics of the specific link technology.

AFAICT, the only thing reactive fragmentation would gain is potentially saving a small
amount of retransmission of good data in environments where proactive fragmentation
protocol constants are poorly tuned.

Thanks - Fred

From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: Tuesday, January 06, 2015 9:08 AM
To: [email-masked]
Subject: Re: [dtn] Internet Draft for Bundle Security

Scott

From: Birrane, Edward J. [mailto:[email-masked]]
Sent: Tuesday, January 6, 2015 8:47 AM
To: Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] Internet Draft for Bundle Security

My intuition is that:

-Ed

---

Scott

Will

Will

Eric

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Jan 2015 21:56:51 +0000

Just occurred to me that the "Crimson Tide" scenario is an example we might want to
consider. In that case, partial good data arrived but was it due to proactive or reactive
fragmentation? If reactive, then proactive protocol constants must have been poorly
tuned.

Thanks - Fred

From: dtn [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Tuesday, January 06, 2015 1:50 PM
To: Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] Internet Draft for Bundle Security

Thanks - Fred
[email-masked]<mailto:[email-masked]>

Scott

My intuition is that:

-Ed

---

Scott

Will

Will

Eric

---

From: Eric Travis <[email-masked]>
Date: Wed, 7 Jan 2015 03:15:31 -0500

Will,

> rate is something I don't understand. Do we need a seer protocol to go with

Just to be clear, I don't think there should be a legislated maximum bundle
size (an MBU), but it
would be a far better solution than relying on intermediate fragmentation.
Fragmentation of very
large bundles to be smeared across intermediate nodes is likely going to
lead to less data being
delivered - *when* one fragment is discarded, all the remaining fragments
will be discarded at
the ultimate destination.  If a bundle is too big to traverse an average
contact session from the
initial BPA without proactive fragmentation, then it is too darned big.

We should be engineering with the pessimistic case (stuff happens) rather
the optimistic case
(nothing [bad] happens) in mind.  Relying on widespread us of fragmentation
is overly optimistic.

Instead of encouraging overly sized bundles, applications should be advised
to build smaller
bundles that contain framing and sequencing "hints" - and ideally FEC - so
that the larger data
set can be reconstructed at the destination.  If not all the bundles
survive, the missing data is
identifiable, if not recoverable. It's proactive fragmentation at the
source, but smarter.

Even with mindful bundle sizing/construction, there *will* be incidents
where bundles can
not be completely transmitted within a remaining contact period - this
leads to the motivation
behind my comment about fragmentation being a WANT:

    The desire to fragmentation at the bundle layer is due to deficiencies
at the convergence layer
    (connectivity is episodic), so the best place to deal with the
"problem" is at the convergence
    layer;  A bundle is an atomic data unit (essentially a file) and the
transfer of a bundle between
    two nodes via a convergence layer entity *is* a file transfer.  We know
how to effect reliable file
    transfers that are split across two or more time disjoint connectivity
episodes - especially when
    the contacts aren't terminated gracefully.

    [Note, such an approach is completely compatible (functionally
identical) to Scott's text quoted
     above, but is far simpler and more efficient.]

Bundle fragmentation is a WANT, not a NEED.  There is a large body of
networking experience
that tells us that fragmentation is something to avoid - the DTN
environment has nothing to
suggest that it is special in this regard.

Regardless - it is evident that supporting bundle fragmentation requires a
more expressive CL
service interface than is defined in RFC 5050.  Proactive fragmentation
needs hints (guesses)
about the current connectivity. Reactive fragmentation should be dropped in
a deep pit and
never mentioned again.

Eric

---

From: Eric Travis <[email-masked]>
Date: Wed, 7 Jan 2015 03:56:08 -0500

Scott,

On Tue, Jan 6, 2015 at 10:51 AM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>
> Good question, but I don’t think it’s that difficult.  During any period
> of contact there’s plenty we don’t know, but we do know the local node’s
> own transmission rate in bits per second.  A simple approach is to fragment
> the outgoing bundle into chunks such that each fragment’s payload
> represents one second’s worth of transmission at the current transmission
> rate.  In that case, no matter when the connection is lost you have wasted
> at most one second of transmission – one second’s worth of data that needs
> to be transmitted at the next contact opportunity.
>
>
>
> This is of course an extreme; depending on your expectations of the link’s
> volatility and how much you are willing to risk having to retransmit, you
> might increase your chunk size to five second’s worth of transmission, or
> sixty.  The main point is that you avoid all of the ever-burgeoning
> complexity of reactive fragmentation, greatly simplifying DTN.
>
>
>
> Scott
>
>
>
I'm not sure I'm understanding this properly and want to avoid making poor
assumptions on intent:

Let's say we have a TCP-based CLA, it really isn't trivial to provide the
instantaneous effective data
rate - especially before any data has been sent - but let's assume that I
could quickly provide you an
accurate, steady-state value.

Is the first (and each successive) bundle scheduled to be transferred over
this connection going to
be proactively fragmented into (N second * current data rate) payload
chunks for transmission, rather
than atomic bundle itself?

If the above is correct, is the intent to reassemble these fragments before
forwarding to the next hop,
and when there are untransferred fragments, will the next pairwise (same
peer) connection resume
with the first untransferred fragment?

Eric

---

From: Eric Travis <[email-masked]>
Date: Wed, 7 Jan 2015 04:18:55 -0500

Fred,

If I remember the movie correctly, the "partial good data" was a result of
the transmission being
unexpectedly cut off by an attack.  In which case, you'd have received an
incomplete bundle (is
this considered reactive fragment)?  There would be no way to validate the
fractional payload,
hence you have no way of knowing that it is indeed "good" data.

Of what value is a reactive fragment?  In your scenario - if you are going
to interpret data
in a reactive fragment, couldn't I use forged (via replay of bundle
headers) reactive fragments
as an attack vector, or am I (likely) misunderstanding the how/what of
reactive fragmentation?

On Tue, Jan 6, 2015 at 4:56 PM, Templin, Fred L <[email-masked]>
wrote:

>  Just occurred to me that the “Crimson Tide” scenario is an example we
> might want to
>
> Thanks – Fred
> *Eric*

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 7 Jan 2015 09:34:34 +0000

Hello:

The plot of the entire movie (Crimson Time) was that there was a partially received message that could not be authenticated. Therefore the high drama in deep seas, where both warring parties were informed, at the end of the movie, that the conduct was unbecoming of US Naval officers (or something like that).

Technically, in cryptography, messages are either authenticated or not authenticated. If a single bit in the message were altered or portions of messages were erased, then authentication fails.

From a confidentiality perspective, the decryption algorithm MAY recover, if the last few blocks were to be erased. Again this statement assumes that standard modes of block encryption is being used. It is not possible to encrypt the first few blocks and the last few blocks successfully, if the middle few blocks are either altered or erased, when the mode used is CBC, for example.
http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

Additionally, the following reading of already published Bundle protocol suite specifications implies proactive fragmentation.

https://tools.ietf.org/html/rfc5050#section-5.8

   It may at times be necessary for bundle protocol agents to reduce the

   sizes of bundles in order to forward them.  This might be the case,

   for example, if the endpoint to which a bundle is to be forwarded is

   accessible only via intermittent contacts and no upcoming contact is

   long enough to enable the forwarding of the entire bundle.

https://tools.ietf.org/html/rfc6257#section-3.8

If it is necessary for a node to fragment a bundle and security

   services have been applied to that bundle, the fragmentation rules

   described in [DTNBP] MUST be followed.  As defined there and repeated

   here for completeness, only the payload MAY be fragmented; security

   blocks, like all extension blocks, can never be fragmented.  In

   addition, the following security-specific processing is REQUIRED: ….
Similar text is available at in the Streamlined Bundle Security Protocol as well: https://tools.ietf.org/html/draft-irtf-dtnrg-sbsp-00#section-3.4

Best regards
Kapali

From: Eric Travis [mailto:[email-masked]]
Sent: Wednesday, January 07, 2015 2:49 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn] Internet Draft for Bundle Security

Fred,
If I remember the movie correctly, the "partial good data" was a result of the transmission being
unexpectedly cut off by an attack.  In which case, you'd have received an incomplete bundle (is
this considered reactive fragment)?  There would be no way to validate the fractional payload,
hence you have no way of knowing that it is indeed "good" data.
Of what value is a reactive fragment?  In your scenario - if you are going to interpret data
in a reactive fragment, couldn't I use forged (via replay of bundle headers) reactive fragments
as an attack vector, or am I (likely) misunderstanding the how/what of reactive fragmentation?

On Tue, Jan 6, 2015 at 4:56 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Just occurred to me that the “Crimson Tide” scenario is an example we might want to
consider. In that case, partial good data arrived but was it due to proactive or reactive
fragmentation? If reactive, then proactive protocol constants must have been poorly
tuned.

Thanks – Fred

Eric

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Wed, 7 Jan 2015 14:12:33 +0000

**  Eric, Thanks for taking time to provide constructive  comments.

 Fragmentation of very
large bundles to be smeared across intermediate nodes is likely going to lead to less data being
delivered - *when* one fragment is discarded, all the remaining fragments will be discarded at
the ultimate destination.

** Agree

If a bundle is too big to traverse an average contact session from the
initial BPA without proactive fragmentation, then it is too darned big.

** Agree, but requires the seer protocol.  :-)

We should be engineering with the pessimistic case (stuff happens) rather the optimistic case
(nothing [bad] happens) in mind.  Relying on widespread us of fragmentation is overly optimistic.

**  Yes, avoids the need for a seer protocol

Instead of encouraging overly sized bundles, applications should be advised to build smaller
bundles that contain framing and sequencing "hints" - and ideally FEC - so that the larger data
set can be reconstructed at the destination.  If not all the bundles survive, the missing data is
identifiable, if not recoverable. It's proactive fragmentation at the source, but smarter.

** Yes, so there should be a Concept of Operations document or section.  Advice for users.  What to expect and not expect from the bundle protocol.

** If one provides this advice, one might also consider letting the application protect the confidentiality of the payload rather than having that done in the bundle overlay.

** As an aside, if bundling were ever to become widespread over complex meshed network, large bundles and/or  first-in-first-out queuing would likely result in head -of–line blocking.

** Conversely, Smaller bundles will likely complicate queue management as this is a store, carry and forward system.  But, if bundling remains an edge-centric deployment in limited size networks, this may not be a problem.  IMHO, ICN will win out in connected networks and the queue management will be figured out there (ICN).  Thus, we might want to just consider the edge-centric case for bundling.

Even with mindful bundle sizing/construction, there *will* be incidents where bundles can
not be completely transmitted within a remaining contact period - this leads to the motivation
behind my comment about fragmentation being a WANT:

Regardless - it is evident that supporting bundle fragmentation requires a more expressive CL
service interface than is defined in RFC 5050.  Proactive fragmentation needs hints (guesses)
about the current connectivity. Reactive fragmentation should be dropped in a deep pit and
never mentioned again.

** Initially, I was not a fan of reactive fragmentation.  But, in the limited experiments performed about 5 years ago now – reactive fragmentation proved useful. And this was over the terrestrial link from Hawaii to Cleveland, Ohio, not the space link.  Note, the Proactive bundles were 80 and 70 Mbytes and then got reactively fragmented.
http://www.ietf.org/mail-archive/web/dtn-interest/current/msg00804.html
http://syzygyengineering.com/2010/GlobeCom1569303096.pdf

Eric

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 7 Jan 2015 19:54:30 +0000

Hi, Eric.  First, I agree that knowing an accurate value for the instantaneous effective data rate is non-trivial, but I would not suggest that anything like that level of accuracy is necessary; this figure is only being used to reduce wasted transmission when a nominally improbable event occurs, so it can be as rough as circumstances dictate.

Then, on your question: no, I'm not proposing any additional complexity.  What I'm proposing is that, whenever the size P of the payload of the next bundle to transmit exceeds Q, where Q = (N seconds * current data rate) for some managed value of N, we proactively split the bundle into two fragments: one with payload size Q, the other with payload size P - Q.  At that point we forward the bundle with payload size Q in the usual way.  At the final destination, all fragments of the original payload are reassembled into the original application data unit, which is then delivered to the application.

Scott
________________________________
From: Eric Travis [[email-masked]]
Sent: Wednesday, January 07, 2015 12:56 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Internet Draft for Bundle Security

Scott,

On Tue, Jan 6, 2015 at 10:51 AM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:

Good question, but I don’t think it’s that difficult.  During any period of contact there’s plenty we don’t know, but we do know the local node’s own transmission rate in bits per second.  A simple approach is to fragment the outgoing bundle into chunks such that each fragment’s payload represents one second’s worth of transmission at the current transmission rate.  In that case, no matter when the connection is lost you have wasted at most one second of transmission – one second’s worth of data that needs to be transmitted at the next contact opportunity.

This is of course an extreme; depending on your expectations of the link’s volatility and how much you are willing to risk having to retransmit, you might increase your chunk size to five second’s worth of transmission, or sixty.  The main point is that you avoid all of the ever-burgeoning complexity of reactive fragmentation, greatly simplifying DTN.

Scott

I'm not sure I'm understanding this properly and want to avoid making poor assumptions on intent:

Let's say we have a TCP-based CLA, it really isn't trivial to provide the instantaneous effective data
rate - especially before any data has been sent - but let's assume that I could quickly provide you an
accurate, steady-state value.

Is the first (and each successive) bundle scheduled to be transferred over this connection going to
be proactively fragmented into (N second * current data rate) payload chunks for transmission, rather
than atomic bundle itself?

If the above is correct, is the intent to reassemble these fragments before forwarding to the next hop,
and when there are untransferred fragments, will the next pairwise (same peer) connection resume
with the first untransferred fragment?

Eric