Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

From: Eric Travis <[email-masked]>
Date: Fri, 9 Jan 2015 02:15:39 -0500

Scott,

Thanks for the feedback...

I do understand the motivation here - especially in situations where the
underlying
paths are high-latency the links are (effectively) simplex.  All my other
concerns
aside,  your final line amplifies my major concern with the approach:

|  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.

Without coalescing the bundle fragments at the intermediate nodes, the
approach
depends on recursive fragmentation (fragmenting fragments) [*] - something
that
is explicitly prohibited in RFC 5050 [Section 5.8, 2nd paragraph:
"(However, there
is only one 'level' of fragmentation, as in IP fragmentation.)"] [**] and
is an ill-advised
direction to go.

Eric

[*] The initial transmission cycle will segment the source bundle sets an
initial Q.
     Unless there is a guarantee that each successive transmission cycle
depends
     on a Q' that is larger than Q, the fragments will need to be
re-fragmented to make
     forward progress.

[**] A clever person could propose that sub-fragmention could be supported
(as all
      offsets are relative to the original/atomic/complete bundle payload,
but please,
      *please* don't go there :)

On Wed, Jan 7, 2015 at 2:54 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  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]> 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: "Templin, Fred L" <[email-masked]>
Date: Fri, 9 Jan 2015 16:19:32 +0000

I think can Bundle-in-Bundle Encapsulation be used for when hop-by-hop
proactive fragmentation is necessary?

Thanks – Fred
[email-masked]

From: dtn [mailto:[email-masked]] On Behalf Of Eric Travis
Sent: Thursday, January 08, 2015 11:16 PM
To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott,
Thanks for the feedback...
I do understand the motivation here - especially in situations where the underlying
paths are high-latency the links are (effectively) simplex.  All my other concerns
aside,  your final line amplifies my major concern with the approach:

Without coalescing the bundle fragments at the intermediate nodes, the approach
depends on recursive fragmentation (fragmenting fragments) [*] - something that
is explicitly prohibited in RFC 5050 [Section 5.8, 2nd paragraph: "(However, there
is only one 'level' of fragmentation, as in IP fragmentation.)"] [**] and is an ill-advised
direction to go.
Eric

[*] The initial transmission cycle will segment the source bundle sets an initial Q.
     Unless there is a guarantee that each successive transmission cycle depends
     on a Q' that is larger than Q, the fragments will need to be re-fragmented to make
     forward progress.
[**] A clever person could propose that sub-fragmention could be supported (as all
      offsets are relative to the original/atomic/complete bundle payload, but please,
      *please* don't go there :)

On Wed, Jan 7, 2015 at 2:54 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>]
Sent: Wednesday, January 07, 2015 12:56 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]<mailto:[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

---

From: Amy Alford <[email-masked]>
Date: Fri, 9 Jan 2015 14:32:24 -0500

My read of 5050 is different than yours.  There is no difference between
fragmenting initially into 10 fragments of length 100 vs fragmenting into
two fragments of length 500 and then fragmenting each of those into 5
fragments of length 100.  The comment about multiple layers refers to the
fact that the results in these two cases are indistinguishable.

Aside from proactive fragmentation, 5050 fragmentation poses problems for
BSP because so little is ruled out.  Very little is said about managing
extension blocks during fragment reassembly.  Extension blocks can be
added, removed, or modified (appending to a route logging block, for
example) in transit either before or after fragmentation.  Some routing
strategies may lead to bundle duplication.  In that case, the final
destination may receive a set of fragments that "cover" the payload but
aren't disjoint.

On Fri, Jan 9, 2015 at 2:15 AM, Eric Travis <[email-masked]>
wrote:

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

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 9 Jan 2015 19:43:52 +0000

I agree with Amy.

Sent from my Verizon Wireless 4G LTE DROID

Amy Alford <[email-masked]> wrote:

My read of 5050 is different than yours.  There is no difference between fragmenting initially into 10 fragments of length 100 vs fragmenting into two fragments of length 500 and then fragmenting each of those into 5 fragments of length 100.  The comment about multiple layers refers to the fact that the results in these two cases are indistinguishable.

Aside from proactive fragmentation, 5050 fragmentation poses problems for BSP because so little is ruled out.  Very little is said about managing extension blocks during fragment reassembly.  Extension blocks can be added, removed, or modified (appending to a route logging block, for example) in transit either before or after fragmentation.  Some routing strategies may lead to bundle duplication.  In that case, the final destination may receive a set of fragments that "cover" the payload but aren't disjoint.

On Fri, Jan 9, 2015 at 2:15 AM, Eric Travis <[email-masked]<mailto:[email-masked]>> wrote:
Scott,

Eric

Scott

Scott,

Scott

Eric

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

---

From: "Juan A. Fraire" <[email-masked]>
Date: Fri, 9 Jan 2015 16:53:30 -0300

I also agree with Amy, "one level of fragmentation" doesn't imply that
fragmentation must occur once in a bundle lifetime but that reassembly does
not depend on a layered fragmentation hierarchy. This is, if a bundle get
fragmented 2 times, I wont need to complete the reassembly of a full level
2 fragment before executing a partial reassembly of a higher level
fragment. Hard to explain for non-english speaker :)

Regards,

J.Fraire

On Fri, Jan 9, 2015 at 4:43 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  I agree with Amy.
>
>  *Sent from my Verizon Wireless 4G LTE DROID*
>
>
>  Aside from proactive fragmentation, 5050 fragmentation poses problems
> for BSP because so little is ruled out.  Very little is said about managing

---

From: Eric Travis <[email-masked]>
Date: Fri, 9 Jan 2015 15:01:43 -0500

Fred,

> [email-masked]

It a clever idea -  but, respectfully, the road to Hell is paved with
clever ideas.

This approach trades fragmenting fragments with creating an increasingly large
number of decreasingly smaller bundles whose value are interdependent, adding
load on the network infrastructure and decreasing accountability, probably of
complete bundle delivery and I'm not sure how it would deal with security.

The tool box is large, why is the group consensus on the using the
sledge hammer?

Eric

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 9 Jan 2015 20:10:34 +0000

Hi Eric,

I am not going to hold fast to this idea. Fragmentation and reassembly are
controversial in the extreme even at the IP packet level (remember the
seminal "Fragmentation Considered Harmful"). Also, others have spoken
up who seem to know more than I do about BP fragmentation so I would
recommend checking those posts.

Thanks - Fred

> -----Original Message-----
> From: Eric Travis [mailto:[email-masked]]
> Sent: Friday, January 09, 2015 12:02 PM
> To: Templin, Fred L
> Cc: Burleigh, Scott C (312B); [email-masked]

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Fri, 9 Jan 2015 20:11:01 +0000

I am still learning the ins and outs of DTN.

Question; If I would build this out the each node would be required to do processing and in most area where Delay/Disruptive technologies are needed we would want the systems to be uncomplicated as possible (KISS) because we have limited resources and limited access to the nodes.  So why would we not want the end nodes to be responsible for the majority of the management and processing and not burden the intermediate nodes.

Am I way off base on this?

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer
System Architectures and Networks Branch
21000 Brookpark Rd
Cleveland, OH 44135
[email-masked]
Office: 216-433-5179

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Juan A. Fraire
Sent: Friday, January 09, 2015 2:54 PM
To: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]
Cc: Amy Alford; Eric Travis; [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

I also agree with Amy, "one level of fragmentation" doesn't imply that fragmentation must occur once in a bundle lifetime but that reassembly does not depend on a layered fragmentation hierarchy. This is, if a bundle get fragmented 2 times, I wont need to complete the reassembly of a full level 2 fragment before executing a partial reassembly of a higher level fragment. Hard to explain for non-english speaker :)

Regards,

J.Fraire

On Fri, Jan 9, 2015 at 4:43 PM, Burleigh, Scott C (312B) <[email-masked] <mailto:[email-masked]> > wrote:

	I agree with Amy.

	Amy Alford <[email-masked] <mailto:[email-masked]> > wrote:

	On Fri, Jan 9, 2015 at 2:15 AM, Eric Travis <[email-masked] <mailto:[email-masked]> > wrote:

		Scott,

		Eric

		On Wed, Jan 7, 2015 at 2:54 PM, Burleigh, Scott C (312B) <[email-masked] <mailto:[email-masked]> > wrote:

			Scott

			From: Eric Travis [[email-masked] <mailto:[email-masked]> ]
			Sent: Wednesday, January 07, 2015 12:56 AM
			To: Burleigh, Scott C (312B)
			Cc: [email-masked] <mailto:[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:

				Scott

			Eric

			

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

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

---

From: Amy Alford <[email-masked]>
Date: Fri, 9 Jan 2015 15:40:38 -0500

What is the advantage of using bundle in bundle encapsulation over building
the functionality into the convergence layer?

On Fri, Jan 9, 2015 at 11:19 AM, Templin, Fred L <[email-masked]>
wrote:

> *From:* dtn [mailto:[email-masked]] *On Behalf Of *Eric Travis
> *Sent:* Thursday, January 08, 2015 11:16 PM
> *Subject:* Re: [dtn] Proactive Fragmentation, was: Internet Draft for
> Bundle Security
>
>
>
> Scott,
>
> 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
> 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
> 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: "Templin, Fred L" <[email-masked]>
Date: Fri, 9 Jan 2015 20:55:26 +0000

Hi Amy,

My comment was framed from the standpoint of what I know about IP fragmentation,
which I have written quite a bit about. With IPv4, fragmentation can occur either at the
source host or at any hop along the path from the source to the destination (but, it is
only the final destination that reassembles). With IPv6, fragmentation can only occur
at the source host – in-the-network fragmentation is deprecated. So, the question is
whether BP fragmentation is more like IPv4 fragmentation or IPv6 fragmentation.

If each BP fragment needs to include its own security parameters, then I think it is
more like IPv6 fragmentation, since any in-the-network fragmentation in the path
would invalidate the security parameters – or am I wrong? So, if an end-to-end
fragmentation is enabled by BP, then BIBE would allow a hop-by-hop fragmentation
where the ingress bundle endpoint is the source and the egress bundle endpoint
is the destination. In that case, the BIBE ingress can provide per-fragment security
codes that the BIBE egress can validate.

But again, this is from the standpoint of someone who knows a little bit about
IP fragmentation but not much at all about BP fragmentation.

Thanks – Fred

From: Amy Alford [mailto:[email-masked]]
Sent: Friday, January 09, 2015 12:41 PM
To: Templin, Fred L
Cc: Eric Travis; Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

What is the advantage of using bundle in bundle encapsulation over building the functionality into the convergence layer?

On Fri, Jan 9, 2015 at 11:19 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
I think can Bundle-in-Bundle Encapsulation be used for when hop-by-hop
proactive fragmentation is necessary?

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

From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Travis

Scott,

Scott

Scott

---

From: Eric Travis <[email-masked]>
Date: Fri, 9 Jan 2015 16:02:11 -0500

Amy,

Rereading the original text with your comment in mind:

> fact that the results in these two cases are indistinguishable.

Rereading the original text with your comment in mind, I agree with you.
Unfortunately that nullifies
a decade old positive feeling about how the intent was to minimize the
risks of fragmentation in the BP.

It does not change my opinion that gratuitous use of proactive
fragmentation is *at best* a premature
optimization.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 9 Jan 2015 21:06:41 +0000

I believe bundle-in-bundle encapsulation should in fact be functionality that is implemented at the convergence layer; that's the way my BIBE Internet Draft is written.

The advantage of bundle-in-bundle encapsulation is that it doesn't introduce anything new but instead simply leverages all of the BP ecosystem that is already in place.  I think it's simple and powerful.

Scott
________________________________
From: Amy Alford [[email-masked]]
Sent: Friday, January 09, 2015 12:40 PM
To: Templin, Fred L
Cc: Eric Travis; Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Thanks – Fred

Scott,

Scott

Scott

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 9 Jan 2015 21:15:21 +0000

Eric, the fact that an idea is clever doesn't necessarily make it wrong.

It is true that the application of Bundle Security Protocol to fragments needs to be designed with some care.  I think Ed's SBSP draft does that, but I won't claim that no additional work needs to be done.

I don't understand why iterative fragmentation increases the load on network infrastructure or decreases accountability any more than doing the same fragmentation at the application layer would do.  Actually, I would expect it to impose *less* of a load on the network because it can in theory be done only when truly needed, due to local link conditions; when the application does fragmentation it doesn't have this information and therefore might create a larger number of small fragments than is truly needed in order to get the data through the network.

This is not a sledgehammer.  It is not the road to Hell.  It is an engineering decision.

Scott
________________________________________
From: Eric Travis [[email-masked]]
Sent: Friday, January 09, 2015 12:01 PM
To: Templin, Fred L
Cc: Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Fred,

Eric

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 9 Jan 2015 21:16:57 +0000

I think we are in agreement here, Eric: the gratuitous use of just about anything is a bad idea.

Scott
________________________________
From: dtn [[email-masked]] on behalf of Eric Travis [[email-masked]]
Sent: Friday, January 09, 2015 1:02 PM
To: Amy Alford
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Amy,

On Fri, Jan 9, 2015 at 2:32 PM, Amy Alford <[email-masked]<mailto:[email-masked]>> wrote:
My read of 5050 is different than yours.  There is no difference between fragmenting initially into 10 fragments of length 100 vs fragmenting into two fragments of length 500 and then fragmenting each of those into 5 fragments of length 100.  The comment about multiple layers refers to the fact that the results in these two cases are indistinguishable.

Rereading the original text with your comment in mind, I agree with you.  Unfortunately that nullifies
a decade old positive feeling about how the intent was to minimize the risks of fragmentation in the BP.

It does not change my opinion that gratuitous use of proactive fragmentation is *at best* a premature
optimization.

---

From: Eric Travis <[email-masked]>
Date: Fri, 9 Jan 2015 16:19:44 -0500

Fred,

Concerns/arguments regarding fragmentation in bundling go back the better
part of 2 decades.
Back then, it was generally me that was in support of exploring
fragmentation (as it was a
research project and the hard problems were the attraction - at least for
me).  The fodder for
the "discussions" was from the collected wisdom/experience of the internet
community.

Fragmentation is likely necessary as a last resort for some scenarios, but
it is important to
cull those out and build an architecture that can generally avoid it.  This
is why I asked about
for NEED versus WANT.

Proper convergence layer support can mostly avoid the WANT to fragment
bundles that can't
be transferred in a single contact period.  The determination on
fragmentation should be
predicated on the available storage at the next hop node.  That would lead
to a discussion
on coordination between nodes - another function best dealt with at the
convergence layer.

Eric

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 9 Jan 2015 21:20:34 +0000

Not at all.  Nothing requires intermediate nodes to do fragmentation, custody transfer, etc.  The intent of the specifications, I think, is to provide rules for doing these things in the event that you need to.

Scott
________________________________________
From: Sheehe, Charles J. (GRC-LCA0) [[email-masked]]
Sent: Friday, January 09, 2015 12:11 PM
To: Juan A. Fraire; Burleigh, Scott C (312B)
Cc: Amy Alford; Eric Travis; [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Juan A. Fraire
Sent: Friday, January 09, 2015 2:54 PM
To: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]
Cc: Amy Alford; Eric Travis; [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Regards,

J.Fraire

        I agree with Amy.

                Scott,

                Eric

                        Scott

                        Scott,

                                Scott

                        Eric

---

From: Eric Travis <[email-masked]>
Date: Fri, 9 Jan 2015 18:54:05 -0500

Scott,

In the interest of desiring a mutual understanding of our respective points
of view...

Clever is neither necessarily right or wrong.  But clever  (as in quick
witted) doesn't
infer a deep consideration of all the underlying requirements, design
alternatives and
the secondary effects.  Clever is a smart person making a quick decision
regarding a
particular aspect  of  a larger problem. Clever is often the starting point
to an engineering
solution, but the original idea usually evolves in the process.

I made no comment on the SBSP draft and fragmentation. I am pleased the
interplay
is recognized as a requirement.

I can not help you to understand why something that is done N-transactions
rather than
1 transaction increases the load on the infrastructure.  The same goes for
the probability
of delivery.  Each bundle or fragment has a non-zero probability of *not*
being delivered.
Fragmenting a bundle into N fragments likely decreases the probability that
the bundle is
successfully delivered. (yes, that is not a universal truth)   Successfully
delivering just
N-1 fragments means the infrastructure has wasted the expended resources
not to
mention the lost opportunity costs.

In comparing segmentation (fragmentation) at the application layer, bundle
layer *and*
convergence layer, the convergence layer has the best knowledge required.
The
application layer creates an atomic entity and passes it off to the bundle
layer for
end-to-end delivery.  The bundle layer seeks to hop that atomic unit
between
intermediate bundle layer entities in support of end-to-end delivery.  The
convergence
layer entities facilitate the hop-by-hop transfers.  The need for
segmentation
(fragmentation) arises from a deficiency  in a resource:
     - capacity - storage (an intermediate frame or buffer)
     - time - the duration of a connection

In *most* cases, it is the lowest layer (here, the convergence layer) that
has the
best information for handling this segmentation *and* can undo the impacts
so at
the higher level the segmentation and reassembly are transparent.

Your argument against the application doing the fragmentation is the same
as mine
against the bundle layer doing the fragmentation.

I don't understand the why the convergence layer is/was such a neglected
element of
the architecture.

| This is not a sledgehammer.  It is not the road to Hell.  It is an
engineering decision.

In the metaphorical toolbox, bundle fragmentation (whether wrapping them in
bundles
or not) *is* the sledgehammer.  There are better, more precise tools
available - I am
concerned that a systematic approach is not being embraced.

Our definition of engineering undoubtedly differs from yours, but probably
overlaps
in most places.  Hopefully neither embraces system built from accreting
clever (per
my above definition) solutions to an evolving problems space.

My Hell has been using/supporting systems of clever components.  I would
like
to see bundling become a viable, long term solution that supports my future
needs.
So, I hope your road map is the correct one.

To combine two messages into one:

|On Fri, Jan 9, 2015 at 4:16 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:
|  I think we are in agreement here, Eric: the gratuitous use of just about
anything is a bad idea.

Without desiring to be flippant or hostile, merely honest: given the
trigger of this thread and
past experience,  we probably don't agree about what is gratuitous and what
is a premature
optimization.

Eric

On Fri, Jan 9, 2015 at 4:15 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

> It is true that the application of Bundle Security Protocol to fragments
> needs to be designed with some care.  I think Ed's SBSP draft does that,
> but I won't claim that no additional work needs to be done.
>
> I don't understand why iterative fragmentation increases the load on
> network infrastructure or decreases accountability any more than doing the
> same fragmentation at the application layer would do.  Actually, I would
> expect it to impose *less* of a load on the network because it can in
> theory be done only when truly needed, due to local link conditions; when
> the application does fragmentation it doesn't have this information and
> therefore might create a larger number of small fragments than is truly
> needed in order to get the data through the network.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 10 Jan 2015 00:17:44 +0000

Hi,

> Each bundle or fragment has a non-zero probability of *not* being delivered.  
> Fragmenting a bundle into N fragments likely decreases the probability that the bundle is 
> successfully delivered. (yes, that is not a universal truth)   Successfully delivering just 
> N-1 fragments means the infrastructure has wasted the expended resources not to 

Actually, I think this is a key area where BP fragmentation and reassembly differs from 
IP fragmentation and reassembly. With BP, we have reliable delivery of bundles and
bundle fragments whereas with IP fragments can be lost due to errors, congestion, etc.

For IP, one of the main complaints in "Fragmentation Considered Harmful" is that the loss
of a single fragment triggers the retransmission of all fragments (loss unit smaller than
retransmission unit). But for BP, reliable delivery means that that should never happen.
So, the only loss that could occur is resource limitations or memory errors in the node
that needs to reassemble the bundle. But, that is an end system problem, and not a
network problem. And, if the end system is somehow incapacitated retransmission
is not going to help anyway.

Thanks - Fred
 
--- converted from html ---
From: Eric Travis [mailto:[email-masked]] 
Sent: Friday, January 09, 2015 3:54 PM
To: Burleigh, Scott C (312B)
Cc: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott,
In the interest of desiring a mutual understanding of our respective points of view...

Clever is neither necessarily right or wrong.  But clever  (as in quick witted) doesn't 
infer a deep consideration of all the underlying requirements, design alternatives and 
the secondary effects.  Clever is a smart person making a quick decision regarding a 
particular aspect  of  a larger problem. Clever is often the starting point to an engineering 
solution, but the original idea usually evolves in the process.
I made no comment on the SBSP draft and fragmentation. I am pleased the interplay 
is recognized as a requirement.

I can not help you to understand why something that is done N-transactions rather than 
1 transaction increases the load on the infrastructure.  The same goes for the probability
of delivery.  Each bundle or fragment has a non-zero probability of *not* being delivered.  
Fragmenting a bundle into N fragments likely decreases the probability that the bundle is 
successfully delivered. (yes, that is not a universal truth)   Successfully delivering just 
N-1 fragments means the infrastructure has wasted the expended resources not to 
mention the lost opportunity costs.
In comparing segmentation (fragmentation) at the application layer, bundle layer *and* 
convergence layer, the convergence layer has the best knowledge required.  The 
application layer creates an atomic entity and passes it off to the bundle layer for 
end-to-end delivery.  The bundle layer seeks to hop that atomic unit between 
intermediate bundle layer entities in support of end-to-end delivery.  The convergence 
layer entities facilitate the hop-by-hop transfers.  The need for segmentation 
(fragmentation) arises from a deficiency  in a resource:
     - capacity - storage (an intermediate frame or buffer)
     - time - the duration of a connection
In *most* cases, it is the lowest layer (here, the convergence layer) that has the 
best information for handling this segmentation *and* can undo the impacts so at 
the higher level the segmentation and reassembly are transparent. 
Your argument against the application doing the fragmentation is the same as mine 
against the bundle layer doing the fragmentation.

I don't understand the why the convergence layer is/was such a neglected element of
the architecture.

| This is not a sledgehammer.  It is not the road to Hell.  It is an engineering decision.
In the metaphorical toolbox, bundle fragmentation (whether wrapping them in bundles 
or not) *is* the sledgehammer.  There are better, more precise tools available - I am 
concerned that a systematic approach is not being embraced.
Our definition of engineering undoubtedly differs from yours, but probably overlaps 
in most places.  Hopefully neither embraces system built from accreting clever (per 
my above definition) solutions to an evolving problems space.

My Hell has been using/supporting systems of clever components.  I would like 
to see bundling become a viable, long term solution that supports my future needs. 
So, I hope your road map is the correct one.
To combine two messages into one:

|On Fri, Jan 9, 2015 at 4:16 PM, Burleigh, Scott C (312B) <[email-masked]> wrote:
|  I think we are in agreement here, Eric: the gratuitous use of just about anything is a bad idea. 
Without desiring to be flippant or hostile, merely honest: given the trigger of this thread and 
past experience,  we probably don't agree about what is gratuitous and what is a premature 
optimization.

Eric

On Fri, Jan 9, 2015 at 4:15 PM, Burleigh, Scott C (312B) <[email-masked]> wrote:
Eric, the fact that an idea is clever doesn't necessarily make it wrong.

Scott

Eric

---

From: <[email-masked]>
Date: Sat, 10 Jan 2015 00:35:11 +0000

"With BP, we have reliable delivery of bundles and bundle fragments"

No, you don't.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn <[email-masked]> on behalf of Templin, Fred L <[email-masked]>
Sent: Saturday, 10 January 2015 11:17:44 AM
To: Eric Travis; Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi,

Thanks - Fred

--- converted from html ---
From: Eric Travis [mailto:[email-masked]]
Sent: Friday, January 09, 2015 3:54 PM
To: Burleigh, Scott C (312B)
Cc: Templin, Fred L; [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott,

Eric

Scott

Eric

---

From: Eric Travis <[email-masked]>
Date: Fri, 9 Jan 2015 21:25:22 -0500

Fred,

I find this to be a remarkable assertion, I'm genuinely interested in what
leads
you to believe it to be true?

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sat, 10 Jan 2015 19:02:20 +0000

Eric, some remarks in-line below.

Scott

Scott,

I can not help you to understand why something that is done N-transactions rather than
1 transaction increases the load on the infrastructure.
>>           But of course I never said that I did not understand this.  I said that I did not understand why something that is done in N transactions initiated by BP (that is, the production of N fragments of a large bundle, i.e., N bundles to process) increases the load on the infrastructure any more than doing the same thing in N transactions initiated by application does (that is, the production of bundles containing N application data units, i.e., N bundles to process).  And I am still hoping for clarification on that point.
>>           In fact, dividing the application’s large atomic data item into N application data units prior to encapsulation in bundles may impose a heavier load on the network infrastructure than fragmentation would.  Suppose the data path is from A to B to C to D, and the links from A to B and from C to D are fast and stable but the link from B to C is dodgy.  If fragmentation to minimize the chance of bundle transmission failure on the B/C link is done at the application, then node A must forward N bundles, node B must receive and forward N bundles, node C must receive and forward N bundles, and node D must receive and deliver N bundles.  If fragmentation is instead done by BP at node B then A only needs to forward 1 bundle and node B only needs to receive 1 bundle.
>>           Certainly, as you argue below, it would be even better for the fragmentation over the B/C link to be done at the convergence layer at node B; in that case, each of the four nodes only has to deal with a single bundle, a still lower load on the network.  I completely agree with you that we tend to undervalue the role of the convergence-layer protocols in the DTN architecture.
>>           The argument for bundle fragmentation is simply that in some cases the convergence layer can’t do the job.  Supposed instead of A-B-C-D the path may travers multiple C nodes; that is, some of the data from node B will be forwarded to node D by node C1, some by node C2, some by node C3.  The convergence layer endpoint at node B can no longer expect its peer to reassemble the bundle, because C1 would receive some of the fragments and C2 would receive others.  C1 and C2 might even utilize different convergence-layer protocols.  In this case, since the entire bundle cannot be forwarded from B to D via C, you unfortunately have to fragment it.
The same goes for the probability
>>           Sure.  But this is likewise true if the application, rather than BP, has fragmented the data.

|On Fri, Jan 9, 2015 at 4:16 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
|  I think we are in agreement here, Eric: the gratuitous use of just about anything is a bad idea.
Without desiring to be flippant or hostile, merely honest: given the trigger of this thread and
past experience,  we probably don't agree about what is gratuitous and what is a premature
optimization.

>>           Here again I think we agree.

Eric

On Fri, Jan 9, 2015 at 4:15 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
Eric, the fact that an idea is clever doesn't necessarily make it wrong.

Scott
Cc: Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>

Eric

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sat, 10 Jan 2015 19:22:39 +0000

Eric, I won’t presume to explain Fred’s reasoning, but I will offer an observation of my own.  As we have been discussing, the key is again the importance of the convergence-layer protocol.  Because it is possible (actually is common, I believe) to use reliable protocols like TCP and LTP at the convergence layer, the likelihood of losing one of the N fragments of a large bundle can be sharply reduced: there can be hop-by-hop acknowledgment and retransmission of each fragment, individually, within the network.  IP fragmentation, lacking this architectural advantage, is subject to fragment loss that can only be repaired by retransmission of the original unfragmented packet.

As an aside, the advantages conferred at the convergence layer also make multi-source reliable streaming multicast, which is difficult in the Internet, straightforward in DTN.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Eric Travis
Sent: Friday, January 09, 2015 6:25 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Fred,
I find this to be a remarkable assertion, I'm genuinely interested in what leads
you to believe it to be true?

On Fri, Jan 9, 2015 at 7:17 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks - Fred

--- converted from html ---
From: Eric Travis [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, January 09, 2015 3:54 PM
To: Burleigh, Scott C (312B)
Cc: Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott,

Eric

Scott

Eric

---

From: Amy Alford <[email-masked]>
Date: Sat, 10 Jan 2015 15:06:58 -0500

The advantage an application has is that it doesn't have to throw out the
data if n-1 fragments arrive.  If infrequent lost fragments are ok, it can
just tolerate them.  If not, it can use a forward error correction scheme
so that the loss of one fragment doesn't prevent reassembly.

On Sat, Jan 10, 2015 at 2:02 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

> *From:* Eric Travis [mailto:[email-masked]]
> *Sent:* Friday, January 09, 2015 3:54 PM
> *Cc:* Templin, Fred L; [email-masked]
> >>           But of course I never said that I did not understand this.  I
> said that I did not understand why something that is done in N transactions
> initiated by BP (that is, the production of N fragments of a large bundle,
> i.e., N bundles to process) increases the load on the infrastructure any
> more than doing the same thing in N transactions initiated by application
> does (that is, the production of bundles containing N application data
> units, i.e., N bundles to process).  And I am still hoping for
> clarification on that point.
>
> >>           In fact, dividing the application’s large atomic data item
> into N application data units prior to encapsulation in bundles may impose
> a heavier load on the network infrastructure than fragmentation would.
> Suppose the data path is from A to B to C to D, and the links from A to B
> and from C to D are fast and stable but the link from B to C is dodgy.  If
> fragmentation to minimize the chance of bundle transmission failure on the
> B/C link is done at the application, then node A must forward N bundles,
> node B must receive and forward N bundles, node C must receive and forward
> N bundles, and node D must receive and deliver N bundles.  If fragmentation
> is instead done by BP at node B then A only needs to forward 1 bundle and
> node B only needs to receive 1 bundle.
>
> >>           Certainly, as you argue below, it would be even better for
> the fragmentation over the B/C link to be done at the convergence layer at
> node B; in that case, each of the four nodes only has to deal with a single
> bundle, a still lower load on the network.  I completely agree with you
> that we tend to undervalue the role of the convergence-layer protocols in
> the DTN architecture.
>
> >>           The argument for bundle fragmentation is simply that in some
> cases the convergence layer can’t do the job.  Supposed instead of A-B-C-D
> the path may travers multiple C nodes; that is, some of the data from node
> B will be forwarded to node D by node C1, some by node C2, some by node
> C3.  The convergence layer endpoint at node B can no longer expect its peer
> to reassemble the bundle, because C1 would receive some of the fragments
> and C2 would receive others.  C1 and C2 might even utilize different
> convergence-layer protocols.  In this case, since the entire bundle cannot
> be forwarded from B to D via C, you unfortunately have to fragment it.
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sat, 10 Jan 2015 20:28:36 +0000

Absolutely, and fragmentation of application data prior to bundle encapsulation is always an option.  Bundle fragmentation is by no means always the best choice.

But there are indeed multiple alternatives.  I think it’s useful to understand the advantages and disadvantages of all of them so that deployment decisions can be made thoughtfully rather than by reflex.

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Saturday, January 10, 2015 12:07 PM
To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

The advantage an application has is that it doesn't have to throw out the data if n-1 fragments arrive.  If infrequent lost fragments are ok, it can just tolerate them.  If not, it can use a forward error correction scheme so that the loss of one fragment doesn't prevent reassembly.

On Sat, Jan 10, 2015 at 2:02 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
Eric, some remarks in-line below.

Scott

Scott,

Eric

Scott

Eric

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 11 Jan 2015 21:01:04 +0000

Hi, Fred.

Firstly, I think that moving to proactive fragmentation as the general 
rule is contrary to the
architectural principles of DTN as described in RFC 4838. Bundles are 
supposed to be
self-contained application data units and my understanding that the idea 
is to keep them in
one piece as far as reasonably possible.

Moving on to details...

IPv6 source-only fragmentation relies on the source being able to know 
the Path MTU
to the destination or to use the default guaranteed 1280 octets if it 
hasn't been able
to  measure the Path MTU.  In the case of opportunistic networks the 
source has no way
of knowing anything like a Path MTU and DTN is much closer to the 
practicalities of the
IPv4 case where Path MTU determination is not realistic.  For 
opportunistic DTN, Path
MTU is a stochastic variable dependent on the vagaries of the mobility 
model and the
intermittencies of wireless connectivity.  Thus selecting an appropriate 
value for the unit
size of a proactively fragmented bundle is pretty much a 
finger-in-the-air exercise.
I realize that in the space case or any more closely controlled 
environment the source
might have a better idea, but promoting proactive fragmentation in DTN 
as a general
solution doesn't seem like a good way to go if you are seeking to fulfil 
more general
use cases.

Bundle-in-bundle encapsulation as a general solution around 
fragmentation will also hit up
against the problems that  IPv6 has been fighting when the path contains 
tunnels.  Path MTU
determination gets very complicated if extra encapsulation is needed for 
tunnels: How much
leeway do you allow for the tunnel encapsulation? What happens with 
nested tunnels?  Very
rapidly you can end up with empty payloads! And DTN is significantly 
worse than IPv6 with
traditional primary blocks although if you go towards the compressed 
addressing you might be
alright, but that is, IMO, not an appropriate solution for the 
opportunistic case.

Extension blocks as specified in RFC 5050 also tend to get in the way of 
all sorts of
fragmentation, but particularly proactive fragmentation:

   - Pre-primary block extension headers have to be carried in all 
fragments, so if you have
     significant amounts of pre-primary block headers, they will reduce 
your payload size.

   - If your intermediate nodes want to add extension blocks and you 
have chosen the
     payload size to fill out the expected Path MTU, then you will have 
more problems.
     Do you fragment again? How do you know what Path MTU was being used?

   - If either pre- or post-primary block extensions are bigger than the 
PathMTU then you
     can't use RFC 5050 at all.

One area which would need further consideration is things such as the 
expanding logging block
when reactive fragmentation is applied.  The log will not be attached to 
the non-final blocks if
the logging block is post-primary, and will extend the pre-primary size 
in every fragment if it
is pre-primary.

And yes the interactions with the old BSP are mind-blowingly complex.  I 
haven't studied
the details of the SBSP so I can't comment on whether this does simplify 
things as claimed.

However, I would stick with the predominance of reactive fragmentation 
atn the DTN level if
you don't have any foreknowledge of the Path MTU; realize that you have 
to give yourself a
good margin for expansion if intermediate nodes are allowed to stick on 
extra extension blocks.
Finally, if you know something about a particular link's MTU, then use a 
convergence layer
that handles local fragmentation and reassembly hidden form the DTN layer.

On 09/01/15 20:55, Templin, Fred L wrote:
> *From:*Amy Alford [mailto:[email-masked]]
> *Sent:* Friday, January 09, 2015 12:41 PM
> *To:* Templin, Fred L
> *Cc:* Eric Travis; Burleigh, Scott C (312B); [email-masked]
> What is the advantage of using bundle in bundle encapsulation over 
> building the functionality into the convergence layer?
>
> On Fri, Jan 9, 2015 at 11:19 AM, Templin, Fred L 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>
>
>     *From:*dtn [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Eric Travis
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [dtn] Proactive Fragmentation, was: Internet Draft
>     for Bundle Security
>
>     Scott,
>
>     On Wed, Jan 7, 2015 at 2:54 PM, Burleigh, Scott C (312B)
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         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.
>
>         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]
>         <mailto:[email-masked]>]
>         *Cc:* [email-masked] <mailto:[email-masked]>
>         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
>
>         rate - especially before any data has been sent - but let's
>         assume that I could quickly provide you an
>         Is the first (and each successive) bundle scheduled to be
>         transferred over this connection going to
>         If the above is correct, is the intent to reassemble these
>         fragments before forwarding to the next hop,

---

From: Amy Alford <[email-masked]>
Date: Sun, 11 Jan 2015 19:27:59 -0500

This brought to mind an implementation difficulty I've run into with
proactive fragmentation in DTN2.

It's hard to predict extension block sizes in order to pick appropriate
fragment payload sizes to keep the entire fragment under some given MTU
size.  You need to decide how you're splitting the payload before you add
BSP blocks.  Once you've decided how to split the payload, you add a
variable length BSP block.  BSP signatures are highly variable in length
because the signature is formatted in CMS (which can potentially contain
certificate chains).

The issue is that extension blocks can be added or modified after
fragmentation.  As Elwyn just pointed out, with a small MTU, leaving a
little extra "head room" for extension block growth may use up your MTU
altogether.

On Sun, Jan 11, 2015 at 4:01 PM, Elwyn Davies <[email-masked]> wrote:

> IPv6 source-only fragmentation relies on the source being able to know the
> Path MTU
> size of a proactively fragmented bundle is pretty much a finger-in-the-air
> exercise.
> might have a better idea, but promoting proactive fragmentation in DTN as
> a general
> Bundle-in-bundle encapsulation as a general solution around fragmentation
> will also hit up
> leeway do you allow for the tunnel encapsulation? What happens with nested
> tunnels?  Very
> rapidly you can end up with empty payloads! And DTN is significantly worse
> than IPv6 with
>   - If your intermediate nodes want to add extension blocks and you have
> chosen the
> the logging block is post-primary, and will extend the pre-primary size in
> every fragment if it
> is pre-primary.
>
> However, I would stick with the predominance of reactive fragmentation atn
> the DTN level if
> you don't have any foreknowledge of the Path MTU; realize that you have to
> give yourself a
> *From:* Amy Alford [mailto:[email-masked] <[email-masked]>]
> On Fri, Jan 9, 2015 at 11:19 AM, Templin, Fred L <
> [email-masked]> wrote:
>
> dtn mailing [email-masked]://www.ietf.org/mailman/listinfo/dtn
>
>
>

---

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

Hi Elwyn:

You mentioned the following: "Firstly, I think that moving to proactive fragmentation as the general rule is contrary to the
architectural principles of DTN as described in RFC 4838. "

I am unable to understand this assertion given my reading of the relevant section at the following URL as follows. Please can you share the portion of this document that you are referring to that provides the general rule to the contrary?
https://tools.ietf.org/html/rfc4838#section-3.9
BEGIN QUOTE>>
DTN fragmentation and reassembly are designed to improve the
   efficiency of bundle transfers by ensuring that contact volumes are
   fully utilized and by avoiding retransmission of partially-forwarded
   bundles.  There are two forms of DTN fragmentation/reassembly:

Proactive Fragmentation

Reactive Fragmentation
<<END QUOTE

Many thanks.

Best regards
Kapali

From: Elwyn Davies [mailto:[email-masked]]
Sent: Monday, January 12, 2015 2:31 AM
To: Templin, Fred L; Amy Alford
Cc: Burleigh, Scott C (312B); Eric Travis; [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi, Fred.

Firstly, I think that moving to proactive fragmentation as the general rule is contrary to the
architectural principles of DTN as described in RFC 4838.  Bundles are supposed to be
self-contained application data units and my understanding that the idea is to keep them in
one piece as far as reasonably possible.

Moving on to details...

IPv6 source-only fragmentation relies on the source being able to know the Path MTU
to the destination or to use the default guaranteed 1280 octets if it hasn't been able
to  measure the Path MTU.  In the case of opportunistic networks the source has no way
of knowing anything like a Path MTU and DTN is much closer to the practicalities of the
IPv4 case where Path MTU determination is not realistic.  For opportunistic DTN, Path
MTU is a stochastic variable dependent on the vagaries of the mobility model and the
intermittencies of wireless connectivity.  Thus selecting an appropriate value for the unit
size of a proactively fragmented bundle is pretty much a finger-in-the-air exercise.
I realize that in the space case or any more closely controlled environment the source
might have a better idea, but promoting proactive fragmentation in DTN as a general
solution doesn't seem like a good way to go if you are seeking to fulfil more general
use cases.

Bundle-in-bundle encapsulation as a general solution around fragmentation will also hit up
against the problems that  IPv6 has been fighting when the path contains tunnels.  Path MTU
determination gets very complicated if extra encapsulation is needed for tunnels: How much
leeway do you allow for the tunnel encapsulation? What happens with nested tunnels?  Very
rapidly you can end up with empty payloads! And DTN is significantly worse than IPv6 with
traditional primary blocks although if you go towards the compressed addressing you might be
alright, but that is, IMO, not an appropriate solution for the opportunistic case.
Extension blocks as specified in RFC 5050 also tend to get in the way of all sorts of
fragmentation, but particularly proactive fragmentation:

  - Pre-primary block extension headers have to be carried in all fragments, so if you have
    significant amounts of pre-primary block headers, they will reduce your payload size.

  - If your intermediate nodes want to add extension blocks and you have chosen the
    payload size to fill out the expected Path MTU, then you will have more problems.
    Do you fragment again? How do you know what Path MTU was being used?

  - If either pre- or post-primary block extensions are bigger than the PathMTU then you
    can't use RFC 5050 at all.

One area which would need further consideration is things such as the expanding logging block
when reactive fragmentation is applied.  The log will not be attached to the non-final blocks if
the logging block is post-primary, and will extend the pre-primary size in every fragment if it
is pre-primary.

And yes the interactions with the old BSP are mind-blowingly complex.  I haven't studied
the details of the SBSP so I can't comment on whether this does simplify things as claimed.

However, I would stick with the predominance of reactive fragmentation atn the DTN level if
you don't have any foreknowledge of the Path MTU; realize that you have to give yourself a
good margin for expansion if intermediate nodes are allowed to stick on extra extension blocks.
Finally, if you know something about a particular link's MTU, then use a convergence layer
that handles local fragmentation and reassembly hidden form the DTN layer.

at the source host - in-the-network fragmentation is deprecated. So, the question is

would invalidate the security parameters - or am I wrong? So, if an end-to-end

Thanks - Fred

From: Amy Alford [mailto:[email-masked]]
Sent: Friday, January 09, 2015 12:41 PM
To: Templin, Fred L
Cc: Eric Travis; Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Thanks - Fred

Scott,

Scott

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

dtn mailing list

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 12 Jan 2015 16:33:52 +0000

I would say that MTU size shouldn’t be a consideration in this discussion at all.  As Elwyn points out, it is not realistic to expect to know the path MTU size in a DTN-based network.  Since MTU size cannot in the general case be known, clearly we should never even try to fragment bundles to fit into MTU size.

MTU size considerations in a DTN-based network are imposed at the convergence layer.  The job of dealing with them ought to be delegated to the convergence-layer protocol adapters, which in all cases that I can think of will segment and reassemble the transmitted data at the convergence layer, hop-by-hop, constrained by the varying MTU sizes on the various hops.  This segmentation does not produce BP fragments.

Fragmenting bundles to fit into an MTU size is not at all what the proactive fragmentation procedure I’ve been discussing attempts to do.  The intent of the fragmentation I’ve been talking about is to deal with interruption in connectivity, not to deal with MTU size.

In that context, selecting an appropriate value for the unit size of a proactively fragmented bundle is not a decision that has to be based on nonexistent information (i.e., MTU size).  It is a decision that can be based on information that is much more accessible:

·         How many bytes of data per second can I transmit on this link?  (Again, no instantaneous statistical accuracy is needed here.  If my link is TCP/IP over 100Base-T Ethernet, then I can send at most 12.5 million bytes per second.  If my link is S-band via a ClydeSpace radio that has been configured for transmission at 2 Mbps, then I can send at most 250,000 bytes per second.)

·         How many seconds of wasted transmission due to connectivity loss am I willing to risk on this link?  If I know (from operational history) that I lose connectivity about once an hour, then wasting 5 seconds of transmission per loss of connectivity would be a continuous bandwidth degradation of .139%; is that acceptable?  If I know that the link is opportunistic and could be dropped at any moment, then maybe the only way I can be confident of forwarding any bundles at all is to be very conservative and risk only one second’s worth of transmission at a time.  It’s a management decision.

Multiply those two numbers together and the result is the maximum size bundle I want to transmit over this link.  I proactively fragment to that size.  (And I do this fragmentation only at the moment when I am about to transmit over the link.  I would never propose that a bundle be proactively chopped up into N fragments at the source, before forwarding begins.  That would defeat the intent.)

Certainly one can accomplish the same purpose with reactive fragmentation, and when we first thought up reactive fragmentation it sounded great to me.  But reactive fragmentation has two serious drawbacks:

·         It relies on signaling from the receiving node.  That introduces additional transmission overhead, and it’s ineffective when round trip times are long, as in underwater or deep space communication or in scenarios with time-disjoint forward and return links.

·         It’s not secure.  The received fragment cannot be authenticated: if the bundle authentication block follows the payload block then it hasn’t been received, and if it precedes the payload block then it can’t be verified, because it covers the entire bundle rather than just the received fragment.  This at the very least exposes the network to denial-of-service attacks, and someone more ingenious than I am might find other ways to exploit it as well.

Proactively fragmenting bundles as needed, where needed, at the moment of transmission avoids both problems: all information needed to control the fragmentation is available locally, and the fragment is a complete bundle with all applicable extension blocks attached.

I definitely agree that we need to rethink very carefully the rules for handling extension blocks when fragmenting bundles.  But the need for that careful thinking doesn’t invalidate the approach, because the motivating operational scenario is still there: you have to deal with unplanned connectivity loss somehow.

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Sunday, January 11, 2015 4:28 PM
To: Elwyn Davies
Cc: Templin, Fred L; Burleigh, Scott C (312B); Eric Travis; [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

This brought to mind an implementation difficulty I've run into with proactive fragmentation in DTN2.

It's hard to predict extension block sizes in order to pick appropriate fragment payload sizes to keep the entire fragment under some given MTU size.  You need to decide how you're splitting the payload before you add BSP blocks.  Once you've decided how to split the payload, you add a variable length BSP block.  BSP signatures are highly variable in length because the signature is formatted in CMS (which can potentially contain certificate chains).

The issue is that extension blocks can be added or modified after fragmentation.  As Elwyn just pointed out, with a small MTU, leaving a little extra "head room" for extension block growth may use up your MTU altogether.

On Sun, Jan 11, 2015 at 4:01 PM, Elwyn Davies <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Fred.

Moving on to details...

Thanks – Fred

Thanks – Fred

Scott,

Scott

Scott

dtn mailing list

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 12 Jan 2015 18:16:58 +0000

Hi.

On 12/01/15 16:33, Burleigh, Scott C (312B) wrote:
>
> I would say that MTU size shouldn’t be a consideration in this 
> discussion at all.  As Elwyn points out, it is not realistic to expect 
> to know the path MTU size in a DTN-based network. Since MTU size 
> cannot in the general case be known, clearly we should never even try 
> to fragment bundles to fit into MTU size.
>
Let's say "never even try to fragment bundles into a statically 
determined MTU".  The dynamic determination described below amounts to 
determining a link MTU, but I am happy I know what you mean.
>
> MTU size considerations in a DTN-based network are imposed at the 
> convergence layer.  The job of dealing with them ought to be delegated 
> to the convergence-layer protocol adapters, which in all cases that I 
> can think of will segment and reassemble the transmitted data at the 
> convergence layer, hop-by-hop, constrained by the varying MTU sizes on 
> the various hops.  This segmentation does not produce BP fragments.
>
Right.
>
> Fragmenting bundles to fit into an MTU size is not at all what the 
> proactive fragmentation procedure I’ve been discussing attempts to 
> do.  The intent of the fragmentation I’ve been talking about is to 
> deal with interruption in connectivity, not to deal with MTU size.
>
That's fine - the discussion appeared to have been heading off in the 
other direction which prompted my response.
>
> In that context, selecting an appropriate value for the unit size of a 
> proactively fragmented bundle is not a decision that has to be based 
> on nonexistent information (i.e., MTU size).  It is a decision that 
> can be based on information that is much more accessible:
>
> ·How many bytes of data per second can I transmit on this link? 
> (Again, no instantaneous statistical accuracy is needed here.  If my 
> link is TCP/IP over 100Base-T Ethernet, then I can send at most 12.5 
> million bytes per second.  If my link is S-band via a ClydeSpace radio 
> that has been configured for transmission at 2 Mbps, then I can send 
> at most 250,000 bytes per second.)
>
> ·How many seconds of wasted transmission due to connectivity loss am I 
> willing to risk on this link?  If I know (from operational history) 
> that I lose connectivity about once an hour, then wasting 5 seconds of 
> transmission per loss of connectivity would be a continuous bandwidth 
> degradation of .139%; is that acceptable?  If I know that the link is 
> opportunistic and could be dropped at any moment, then maybe the only 
> way I can be confident of forwarding any bundles at all is to be very 
> conservative and risk only one second’s worth of transmission at a 
> time.  It’s a management decision.
>
.. which also has to take into account the overhead in the resulting 
ensemble of bundles and that is extension block dependent.
>
> Multiply those two numbers together and the result is the maximum size 
> bundle I want to transmit over this link.
>
[i.e., work out the instantaneous MTU :-) ]
>
> I proactively fragment to that size.  (And I do this fragmentation 
> only at the moment when I am about to transmit over the link.  I would 
> never propose that a bundle be proactively chopped up into N fragments 
> at the source, before forwarding begins.  That would defeat the intent.)
>
I'll now swap sides: If you are using contact graph routing or similar 
where you expect to know what the path is and what the notional contact 
opportunity volume is for each hop, I would probably *want* to fragment 
the bundle to suit the minimum value over the hops on the path, rather 
than just fragmenting to the current hop 'MTU',  because otherwise I 
might get sub-optimal refragmentation.
>
> Certainly one can accomplish the same purpose with reactive 
> fragmentation, and when we first thought up reactive fragmentation it 
> sounded great to me.  But reactive fragmentation has two serious 
> drawbacks:
>
> ·It relies on signaling from the receiving node.  That introduces 
> additional transmission overhead, and it’s ineffective when round trip 
> times are long, as in underwater or deep space communication or in 
> scenarios with time-disjoint forward and return links.
>
> ·It’s not secure.  The received fragment cannot be authenticated: if 
> the bundle authentication block follows the payload block then it 
> hasn’t been received, and if it precedes the payload block then it 
> can’t be verified, because it covers the entire bundle rather than 
> just the received fragment.  This at the very least exposes the 
> network to denial-of-service attacks, and someone more ingenious than 
> I am might find other ways to exploit it as well.
>
> Proactively fragmenting bundles as needed, where needed, at the moment 
> of transmission avoids both problems: all information needed to 
> control the fragmentation is available locally, and the fragment is a 
> complete bundle with all applicable extension blocks attached.
>
Unfortunately, much of this information may be only at the probabilistic 
level in an opportunistic network.  Calculating the proactive bundle 
size would either have to be conservative (some number of s.d.'s below 
the mean contact opportunity volume) or acknowledge that it will be 
wrong a significant fraction of the time (and so you might need reactive 
fragmentation as well).

Building reactive fragmentation over typical wi-fi terrestrial contacts 
using a reliable IP transport (read 'TCP') is a fairly low cost, low 
overhead business, so I think it is less of problem than you state for 
the all-terrestrial in-air use case. However, I agree that there are 
intermediate uses cases, such as the underwater vehicle case, that are 
truly opportunistic with long RTTs and noisy links.  OTOH I am not sure 
how many hops are typical underwater - single hop is probably simpler to 
solve.

I am not sure I understand your assessment of the 'authentication 
issue'.  The BAB is security source to security destination (maybe 
e2e).  AFAIK it wouldn't normally be checked at an arbitrary 
intermediate node (no keys there generally) and if all goes well it can 
be checked in the reassembled bundle at the destination.  BUT, and its a 
big but, as Amy and others know from an extensive discussion about 18 
months ago on the dtnrg list, reassembling bundles secured with BSP 
turns out to be something of a nightmare. The need to know the whole 
bundle sounds like integrity rather than authentication  and if it is 
really going to mitigate DoS attacks, the receiver has to be able to 
abort close to bundle start.  This is more like securing the hop-by-hop 
link and authenticating the next/previous hop node than per bundle in 
the middle of the network.
>
> I definitely agree that we need to rethink very carefully the rules 
> for handling extension blocks when fragmenting bundles.
>
Very much so!
>
> But the need for that careful thinking doesn’t invalidate the 
> approach, because the motivating operational scenario is still there: 
> you have to deal with unplanned connectivity loss somehow.
>
Yes
> *Sent:* Sunday, January 11, 2015 4:28 PM
> *To:* Elwyn Davies
> *Cc:* Templin, Fred L; Burleigh, Scott C (312B); Eric Travis; [email-masked]
> It's hard to predict extension block sizes in order to pick 
> appropriate fragment payload sizes to keep the entire fragment under 
> some given MTU size. You need to decide how you're splitting the 
> payload before you add BSP blocks.  Once you've decided how to split 
> the payload, you add a variable length BSP block.  BSP signatures are 
> highly variable in length because the signature is formatted in CMS 
> (which can potentially contain certificate chains).
>
> little extra "head room" for extension block growth may use up your 
> MTU altogether.
>
>         <mailto:[email-masked]>
>         *Subject:* Re: [dtn] Proactive Fragmentation, was: Internet
>         Draft for Bundle Security
>
>         What is the advantage of using bundle in bundle encapsulation
>         over building the functionality into the convergence layer?
>
>             *Subject:* Re: [dtn] Proactive Fragmentation, was:
>             Internet Draft for Bundle Security
>
>             Scott,
>
>             is only one 'level' of fragmentation, as in IP
>             fragmentation.)"] [**] and is an ill-advised
>             direction to go.
>
>             Eric
>
>                 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
>
>                 On Tue, Jan 6, 2015 at 10:51 AM, Burleigh, Scott C
>                 (312B) <[email-masked]
>                     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.
>
>                     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
>                 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
>                 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
>                 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

---

From: Eric Travis <[email-masked]>
Date: Mon, 12 Jan 2015 14:06:21 -0500

Scott,

I apologize for not going (fully) in-line to respond to your in-line,
but I find the in-line**2 format difficult to parse…  Even this gives
me troubles:

But of course I never said that I did not understand this.  I said that I
> did not understand why something that is done in N transactions initiated
> by BP (that is, the production of N fragments of a large bundle, i.e., N
> bundles to process)  increases the load on the infrastructure any more than
> doing the same thing in  N transactions initiated by application does (that
> is, the production of bundles containing N application data units, i.e., N
> bundles to process).  And I am still hoping for clarification on that point.
>

You said:

>                 I don't understand why iterative fragmentation increases
>> the load on network infrastructure
>>                 or decreases accountability any more than doing the same
>> fragmentation at the application
>>                 layer would do.”
>>
>
If one chooses to construct a large bundle  that *will* be reliably
delivered (the sender *will* request
retransmission if it does not receive an ACK from the target), dividing the
large bundle into N smaller
bundles would reduce the unit of retransmission - decreasing the load [and
making the rest of the data
available sooner].

I do recognize the prevalent belief that fragments never get lost (expire
in their path) or fail to move
forward because the convergence layer use reliable transport…  I will
continue to worry about
corruption and loss.

More to your precise query:

If the initially created N bundles were somehow the correct size to
traverse without fragmentation
and there is no loss, then there is no appreciable difference to N bundles
or N fragments of identical size.

The difference is your use of *“iterative”*  - each round of iterative
fragmentation increases the cost
of  processing the  aggregate number of bundle headers and increases the
aggregate bundle overhead
relative to the payload.  Dependent on the path, you can’t discount the
possibility that each bundle will
be iteratively fragmented.  You understand the load multiplier of this
situation.

I would advocate applications be prudent in what they declare to be an
atomic unit of transfer but
never claimed if that we true it would render your proactive fragmentation
approach unnecessary.
What I had asked - somewhere earlier than the parent of your message -
(paraphrased):

      Why is the proactive fragmentation approach is *better* than allowing
the segmentation to occur
      at the convergence layer?

At this time, the ONLY place that proactive fragmentation makes sense is
when you are attempting
to route a large bundle through a node that does not (and can never) have
enough buffer space to
hold it.  Building smaller source bundles *reduces* this possibility.

[skipping two paragraphs]

   The argument for bundle fragmentation is simply that in some cases the
>    convergence layer can’t do the job.  Supposed instead of A-B-C-D the
> path may
>    travers multiple C nodes; that is, some of the data from node B will be
> forwarded
>    to node D by node C1, some by node C2, some by node C3.  The convergence
>    layer endpoint at node B can no longer expect its peer to reassemble
> the bundle,
>    because C1 would receive some of the fragments and C2 would receive
> others.
>    C1 and C2 might even utilize different convergence-layer protocols.  In
> this case,
>     since the entire bundle cannot be forwarded from B to D via C, you
> unfortunately
>     have to fragment it.
>

I fully agree with you - this is a [if not THE] case where segmentation at
the bundle
level is the most appropriate response.  I’ve acknowledge this above, and I
believe
earlier in this exchange.  Enabling this probably requires hinting from the
convergence
layer and coordination between peer convergence layer entities.

This is different than proactively fragmenting all/most/some bundles
because this
*may* be the case.  Trying to avoid this situation  should be the goal…

While we disagree on how and when to do this avoidance, I think we agree
that the
convergence layer can be part of the larger solution (I’m not saying we
do/will
agree the how), but at least this is something.

<trimming for brevity>

Eric

---

From: Eric Travis <[email-masked]>
Date: Mon, 12 Jan 2015 15:24:19 -0500

Scott,

I don't want to rehash the many discussions that periodically occurred
on the irtf dtn list (and those before that), but please recognize that a
reliable transport protocol (say TCP), will not *knowingly* deliver
corrupted
data. They are not infallible.

A reliable transport protocol only "protects" the data from send-buffer to
peer receive-buffer.

This duration is an important qualifier - it does not cover the path from
storage
to main memory to send-buffer, or the reverse path from the peer receive
buffer.

There is a path from convergence layer to bundle layer and from there to
non-volatile
storage. Even if your convergence protocol were absolutely perfect (the
convergence
layer verifying the transferred data), you bundle is still *not* protected.

Within a node, undetected errors can be introduced in traversing either the
forward
or reverse paths, as can intermediate processing (fragmentation).  The
aggregate
risk is further increased because the same paths (receiver and sender) are
traversed
at each bundle way-point.

While we can't eliminate the possibility of undetected errors, we can take
advantage
of a large body of prior art and experience and do a better job at seeking,
catching
and reacting to the errors when we can.

Closing the loop within this thread, looking for errors can cause fragments
to be
discarded in transit, ultimately (from my understanding) triggering a
retransmission
of the entire bundle.

Fred said:

For IP, one of the main complaints in "Fragmentation Considered Harmful" is
> that the loss
> network problem. And, if the end system is somehow incapacitated
> retransmission is not
> going to help anyway.
>

This is what I was reacting to, as it seems to recognizes the relevant
vulnerabilities,
but inexplicably limits them to only the target end-systems.

Data *needs* end-to-end protection - and I will note that this should
include the path
between the application and the bundle provider.

I will acknowledge that some communities want even error-ed data to be
delivered,
but there should also be an option for communities to receive reliable
delivery.

I really don't want to go down this rabbit hole now, and certainly not in a
sub-thread
of a sub-thread.

Please recognize that it is a source of irritation to continually be told -
because
a single link in a chain is infallible, the entire chain is infallible.
More so when the
belief in infallibility is misplaced.

I hope this explains my question to Fred.

Eric

On Sat, Jan 10, 2015 at 2:22 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  Eric, I won’t presume to explain Fred’s reasoning, but I will offer an
> observation of my own.  As we have been discussing, the key is again the
> importance of the convergence-layer protocol.  Because it is possible
> (actually is common, I believe) to use reliable protocols like TCP and LTP
> at the convergence layer, the likelihood of losing one of the N fragments
> of a large bundle can be sharply reduced: there can be hop-by-hop
> acknowledgment and retransmission of each fragment, individually, within
> the network.  IP fragmentation, lacking this architectural advantage, is
> subject to fragment loss that can only be repaired by retransmission of the
> original unfragmented packet.
>
>
>
> As an aside, the advantages conferred at the convergence layer also make
> multi-source reliable streaming multicast, which is difficult in the
> Internet, straightforward in DTN.
>
>
>
> Scott
>
>
>
> *Sent:* Friday, January 09, 2015 6:25 PM
> *To:* Templin, Fred L
> *Cc:* [email-masked]
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 12 Jan 2015 22:34:24 +0000

Hi, Elwyn.  I think we are converging.  A couple more remarks in-line below.

Scott

From: Elwyn Davies [mailto:[email-masked]]
Sent: Monday, January 12, 2015 10:17 AM
To: Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi.

On 12/01/15 16:33, Burleigh, Scott C (312B) wrote:
I would say that MTU size shouldn’t be a consideration in this discussion at all.  As Elwyn points out, it is not realistic to expect to know the path MTU size in a DTN-based network.  Since MTU size cannot in the general case be known, clearly we should never even try to fragment bundles to fit into MTU size.
Let's say "never even try to fragment bundles into a statically determined MTU".  The dynamic determination described below amounts to determining a link MTU, but I am happy I know what you mean.

Ø  Okay, “instantaneous MTU”.  I am inclined to prefer a more restrictive concept of MTU as being imposed by frame size limits (which are pretty intransigent) rather than by operational preference (which I think of as being discretionary), but if it helps us communicate then I am for it.

Fragmenting bundles to fit into an MTU size is not at all what the proactive fragmentation procedure I’ve been discussing attempts to do.  The intent of the fragmentation I’ve been talking about is to deal with interruption in connectivity, not to deal with MTU size.
That's fine - the discussion appeared to have been heading off in the other direction which prompted my response.

·         How many seconds of wasted transmission due to connectivity loss am I willing to risk on this link?  If I know (from operational history) that I lose connectivity about once an hour, then wasting 5 seconds of transmission per loss of connectivity would be a continuous bandwidth degradation of .139%; is that acceptable?  If I know that the link is opportunistic and could be dropped at any moment, then maybe the only way I can be confident of forwarding any bundles at all is to be very conservative and risk only one second’s worth of transmission at a time.  It’s a management decision.
.. which also has to take into account the overhead in the resulting ensemble of bundles and that is extension block dependent.

Ø  Sure.

Multiply those two numbers together and the result is the maximum size bundle I want to transmit over this link.
[i.e., work out the instantaneous MTU :-) ]

I proactively fragment to that size.  (And I do this fragmentation only at the moment when I am about to transmit over the link.  I would never propose that a bundle be proactively chopped up into N fragments at the source, before forwarding begins.  That would defeat the intent.)
I'll now swap sides: If you are using contact graph routing or similar where you expect to know what the path is and what the notional contact opportunity volume is for each hop, I would probably *want* to fragment the bundle to suit the minimum value over the hops on the path, rather than just fragmenting to the current hop 'MTU',  because otherwise I might get sub-optimal refragmentation.

Ø  I don’t think you would, though.  Even with contact graph routing you don’t necessarily know the path (buffer occupancy conditions could force you to redirect at any point), and the notional contact opportunity volume that can be anticipated at the source doesn’t take into account the existing transmission backlogs at all the forwarding points.  I really think you get optimal fragmentation if you defer it until you’ve really got no alternative, at which point I think you also have got the best (most current and certain) information on which to base your decision.

Proactively fragmenting bundles as needed, where needed, at the moment of transmission avoids both problems: all information needed to control the fragmentation is available locally, and the fragment is a complete bundle with all applicable extension blocks attached.
Unfortunately, much of this information may be only at the probabilistic level in an opportunistic network.  Calculating the proactive bundle size would either have to be conservative (some number of s.d.'s below the mean contact opportunity volume) or acknowledge that it will be wrong a significant fraction of the time (and so you might need reactive fragmentation as well).

Ø  Would it really only be probabilistic?  If you’ve got an opportunistic contact with some data mule, using TCP/IP/802.11g at the convergence layer, can’t you safely guess that your maximum transmission data rate is 54 Mbps, so 6.75 million bytes/sec?  And if it’s an opportunistic contact then you can lose it at any moment, so maybe the most you want to risk wasting on connection loss is 1 second’s worth of transmission, so your proactive fragmentation size is 6.75 million bytes.

Building reactive fragmentation over typical wi-fi terrestrial contacts using a reliable IP transport (read 'TCP') is a fairly low cost, low overhead business, so I think it is less of problem than you state for the all-terrestrial in-air use case. However, I agree that there are intermediate uses cases, such as the underwater vehicle case, that are truly opportunistic with long RTTs and noisy links.  OTOH I am not sure how many hops are typical underwater - single hop is probably simpler to solve.

I am not sure I understand your assessment of the 'authentication issue'.  The BAB is security source to security destination (maybe e2e).  AFAIK it wouldn't normally be checked at an arbitrary intermediate node (no keys there generally) and if all goes well it can be checked in the reassembled bundle at the destination.  BUT, and its a big but, as Amy and others know from an extensive discussion about 18 months ago on the dtnrg list, reassembling bundles secured with BSP turns out to be something of a nightmare.   The need to know the whole bundle sounds like integrity rather than authentication  and if it is really going to mitigate DoS attacks, the receiver has to be able to abort close to bundle start.  This is more like securing the hop-by-hop link and authenticating the next/previous hop node than per bundle in the middle of the network.

Ø  The security source and security destination of a BAB are supposed to be the local node and the neighboring security-aware node to which the bundle is currently being transmitted; RFC 6257 implies that this is mandatory (“the ciphersuite ID MUST be documented as a hop-by-hop [rather than end-to-end] authentication ciphersuite”) without saying so directly, but I think the Streamlined BSP Internet Draft is explicit on this point.  When the receiving neighbor node reactively fragments a bundle it cannot authenticate this received fragmentary bundle.  Authentication of each received bundle is intended to defend the network (not the receiving node) against denial of service, by enabling the receiving node to discard inauthentic bundles rather than forward them into the network.  Reactive fragmentation defeats that defense.

I definitely agree that we need to rethink very carefully the rules for handling extension blocks when fragmenting bundles.
Very much so!

But the need for that careful thinking doesn’t invalidate the approach, because the motivating operational scenario is still there: you have to deal with unplanned connectivity loss somehow.
Yes

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Sunday, January 11, 2015 4:28 PM
To: Elwyn Davies
Cc: Templin, Fred L; Burleigh, Scott C (312B); Eric Travis; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Moving on to details...

Thanks – Fred

Thanks – Fred

Scott,

Scott

Scott

dtn mailing list

dtn mailing list

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 13 Jan 2015 06:48:43 +0000

Elwyn >> Authentication of each received bundle is intended to defend the network (not the receiving node) against denial of service, by enabling the receiving node to discard inauthentic bundles rather than forward them into the network.  Reactive fragmentation defeats that defense.

Scott>> But the need for that careful thinking doesn’t invalidate the approach, because the motivating operational scenario is still there: you have to deal with unplanned connectivity loss somehow.

Kapali >>

-        It is possible to refine the specification of DTN [Streamlined] Bundle Security Protocols while satisfying the concerns of Elwyn and Scott.

o   Reference 0: https://tools.ietf.org/html/rfc6257#section-1.2 (terminology: source, destination, forwarders, “next hop” or intermediary receivers)

o   Reference 1: https://tools.ietf.org/html/rfc6257#section-3.8 (fragmentation rules and guidelines)

o   Reference 2: https://tools.ietf.org/html/rfc6257#section-2 (security blocks: BAB, PIB, PCB, ESB)

-        Status quo:

o   BAB, (PIB, PCB), and ESB are specified to be in the header of a DTN bundle.

o   It is specified that header of bundle must not be fragmented

o   It is specified that all DTN nodes in the path of a bundle MUST BE able to verify PIB in addition to BAB in order to prevent unauthorized injection of bundles into a DTN instance

-        Problem:

o   Size of BAB is determined by either source or forwarder (refer to terminology)

§  BAB ensures that unauthorized nodes cannot inject bundles into a DTN instance

·        Side note: It is not specified that forwarders MUST remove and drop received BABs but this is implied (or implicit) because BAB is specified to provide only “hop-by-hop” data security.

o   Size of (PIB, PCB) is determined by source

§  Can be more than 1024 bytes because it MAY include sender’s certificate and certificate chain

§  PIB ensures that no DTN node can alter a bundle and avoid detection of the alteration by the destination or “next hop”

·        This security requirement that even the “next hop” must be able to verify PIB is making fragmentation problematic.

§  PCB ensures that only the destination can decrypt and have access to the plaintext corresponding to the payload data (ADU = Application Data Unit)

o   Size of ESB is potentially determined by source and all forwarders in the path of the bundle

o   No DTN node can know the MTU of a DTN link to which it does not have access or connection

o   Reference 1 explicitly disallows fragmentation of security header including (BAB, PIB, PCB, and ECB)

-         Solution: Refine and update Bundle Security Protocol specification

o   The need to fragment BAB will never occur if forwarders are not required to forward received BAB

§  Keep BAB in the header and explicitly specify the dropping of received BABs from the header of the bundle, which cannot be fragmented

o   Allow ONLY the destination to verify correctness of PIB . Intermediary receivers MUST NOT verify correctness of PIB.

§  Thus PIBs, which can be arbitrarily long depending, can be fragmented

§  MitM (Man-in-the-Middle) on ADU can be prevented at the destination

§  BAB already ensures that unauthorized bundles cannot be injected into the DTN instance based on trust assumptions on forwarders

o   Assume that forwarders are trusted to follow the DTN instance’s policy for forwarding bundles in the network. The policy MUST BE explicitly and authentically communicated to all forwarders in the DTN instance by that DTN instance’s authorized administrator.

§  Policy can be enumerated as follows.

·        MUST NOT forward unauthorized bundles in this DTN instance

·        MUST forward unauthorized bundles in this DTN instance

·        ALL authorized bundles MUST be forwarded in this DTN instance

·        ALL authorized bundles MAY be forwarded in this DTN instance

o   Summary of solution: Except BAB, everything else can be fragmented. BAB never needs to be fragmented because it never crosses a single hop.

-        Additional info: Although the following statement regarding authentication and Denial of Service may already be known in this group, it is useful to reiterate the idea in this context.

§  Expensive authentication procedures at the router or other receiver end could result in Denial of Service.

·        http://eprints.qut.edu.au/419/1/Reid2004-VoIPDoS.pdf (Section 2.2)

·        http://www.google.com/patents/WO2008084271A2?cl=en (Application of ideas from Section 2.2 to securing communications in industrial automation controls)

·        Note that an authentication procedure is deemed to be expensive in relation to the computing power available at the receiver end.

o   If the receiver is not resource constrained and there are no real-time processing requirements, then it is safe to assume that ALL authentication procedures are inexpensive.

From: Burleigh, Scott C (312B) [mailto:[email-masked]]
Sent: Tuesday, January 13, 2015 4:04 AM
To: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

From: Elwyn Davies [mailto:[email-masked]]
Sent: Monday, January 12, 2015 10:17 AM
To: Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi.

Ø  Sure.

Scott

Moving on to details...

Thanks – Fred

Thanks – Fred

Scott,

Scott

Scott

dtn mailing list

dtn mailing list

---

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

From: <I-Viswanathan>, Kapaleeswaran <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 13, 2015 1:48 AM
To: "Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Elwyn >> Authentication of each received bundle is intended to defend the network (not the receiving node) against denial of service, by enabling the receiving node to discard inauthentic bundles rather than forward them into the network.

"Reactive fragmentation defeats that defense."

This is the case for security as implemented in RFC5050 and the corresponding bundle security specification (BSP).

I think if we authenticate the header, separate of the bundle, we may provide a lot of flexibility.  If we are going to allow for large bundles, Mbytes and beyond, one probably needs to do that.  One probably doesn't want to get a Gbyte bundle over a wireless system (or wired for that matter) only to decide that you will not accept bundles from that source either due to authentication or, after authenticating, due to policy.

Will

---

From: Amy Alford <[email-masked]>
Date: Tue, 13 Jan 2015 14:01:37 -0500

Hi Kapali,
I just wanted to clarify a couple of points about the existing specs.

BAB is hop by hop, but only between "security aware" nodes.  There may be
DTN routers between a BAB security source and BAB security destination.
The only limitation is that they don't have BSP implementations.  (The
second paragraph of RFC6257, section 2
<https://tools.ietf.org/html/rfc6257#section-2> mentions this.)  Therefore,
it is possible for fragmentation to occur after a BAB block is added.

Routers are not required to verify PIB blocks unless they are the security
destination.  5050 says they are allowed to but not required to.  Depending
on how key management is handled, they may not be able to verify signatures
from some sources.    The 9th paragraph of RFC6257, section 3.6
<https://tools.ietf.org/html/rfc6257#section-3.6> describes this.

No extension block can be fragmented, ever.  Bundles containing extension
blocks can be fragmented unless the DO_NOT_FRAGMENT flag is set in the
primary block.  Fragmentation applies to the payload only.  This is
described in 5050, section 5.8
<https://tools.ietf.org/html/rfc5050#section-5.8>.

If a bundle containing a PIB block is fragmented, the first fragment will
contain the PIB (which now cannot be verified).  If a PIB block is added to
a fragment, it will have a field that indicates which portion of the
original payload it applies to (paragraph 5 of 6257, section 4.2
<https://tools.ietf.org/html/rfc6257#section-4.2>).  So, any router
receiving a fragment with a PIB block can distinguish these two cases.

Enforcing policy regarding PIB blocks is different from verifying the
signature on a PIB block.  A BSP compliant router may choose to discard
bundles with PIB blocks with invalid signatures, but also forward bundles
with no PIB blocks.  So, a router has the option of forwarding fragments
with unverifiable PIB blocks that refer to the whole bundle, while also
discarding fragments with PIB blocks that apply to the current fragment but
are invalid. 6257 states that routers must have security policies.  It says
very little about what they must be or whether they are user configurable.

I pulled out 4 slides that illustrate 5050 extension blocks and
fragmentation at a pretty high level here.
<https://docs.google.com/presentation/d/1KVlDyr3GYoC_Q3G4xis0Qg-nIbFTV_8pS1Qs7inQDZM/pub?start=false&loop=false&delayms=60000&slide=id.g381b0bfc1_0465>
The
last slide is showing how convoluted the situation can get when a bundle is
duplicated by a router (some of the routing schemes in DTN2 forward more
than one copy of the same bundle).  A destination may receive a set of
fragments which suffices to recover the payload but which contains
overlapping fragments of the payload.  The first bullet point in the list
in 5050, section 5.8 <https://tools.ietf.org/html/rfc5050#section-5.8> refers
to this. The same slide demonstrates adding a PIB to a fragment.

- Amy

On Tue, Jan 13, 2015 at 1:48 AM, I-Viswanathan, Kapaleeswaran <
[email-masked]> wrote:

>  Elwyn >> Authentication of each received bundle is intended to defend
> the network (not the receiving node) against denial of service, by enabling
> the receiving node to discard inauthentic bundles rather than forward them
> into the network.  Reactive fragmentation defeats that defense.
>
>
>
> Scott>> But the need for that careful thinking doesn’t invalidate the
> approach, because the motivating operational scenario is still there: you
> have to deal with unplanned connectivity loss somehow.
>
>
>
> Kapali >>
>
> -        It is possible to refine the specification of DTN [Streamlined]
> Bundle Security Protocols while satisfying the concerns of Elwyn and Scott.
>
> o   Reference 0: https://tools.ietf.org/html/rfc6257#section-1.2
> (terminology: source, destination, forwarders, “next hop” or intermediary
> receivers)
>
> o   It is specified that all DTN nodes in the path of a bundle MUST BE
> able to verify PIB in addition to BAB in order to prevent unauthorized
> injection of bundles into a DTN instance
>
>  -        Problem:
>
> ·        Side note: It is not specified that forwarders MUST remove and
> drop received BABs but this is implied (or implicit) because BAB is
> specified to provide only “hop-by-hop” data security.
>
> §  PIB ensures that no DTN node can alter a bundle and avoid detection of
> the alteration by the destination or “next hop”
>
> ·        This security requirement that even the “next hop” must be able
> to verify PIB is making fragmentation problematic.
>
> §  PCB ensures that only the destination can decrypt and have access to
> the plaintext corresponding to the payload data (ADU = Application Data
> Unit)
>
> §  Keep BAB in the header and explicitly specify the dropping of received
> BABs from the header of the bundle, which cannot be fragmented
>
> o   Allow *ONLY* the destination to verify correctness of PIB .
> Intermediary receivers MUST NOT verify correctness of PIB.
>
> §  BAB already ensures that unauthorized bundles cannot be injected into
> the DTN instance based on trust assumptions on forwarders
>
> o   Assume that forwarders are trusted to follow the DTN instance’s
> policy for forwarding bundles in the network. The policy MUST BE explicitly
> and authentically communicated to all forwarders in the DTN instance by
> that DTN instance’s authorized administrator.
>
> o   Summary of solution: Except BAB, everything else can be fragmented.
> BAB never needs to be fragmented because it never crosses a single hop.
>
>
>
> -        Additional info: Although the following statement regarding
> authentication and Denial of Service may already be known in this group, it
> is useful to reiterate the idea in this context.
>
> ·        http://www.google.com/patents/WO2008084271A2?cl=en (Application
> of ideas from Section 2.2 to securing communications in industrial
> automation controls)
>
> ·        Note that an authentication procedure is deemed to be expensive
> in relation to the computing power available at the receiver end.
>
> o   If the receiver is not resource constrained and there are no
> real-time processing requirements, then it is safe to assume that ALL
> authentication procedures are inexpensive.
>
>
>
>
>
> *From:* Burleigh, Scott C (312B) [mailto:[email-masked]]
> *Sent:* Tuesday, January 13, 2015 4:04 AM
> *To:* [email-masked]
>
> *From:* Elwyn Davies [mailto:[email-masked] <[email-masked]>]
> *Sent:* Monday, January 12, 2015 10:17 AM
> *To:* Burleigh, Scott C (312B); [email-masked]
> I would say that MTU size shouldn’t be a consideration in this discussion
> at all.  As Elwyn points out, it is not realistic to expect to know the
> path MTU size in a DTN-based network.  Since MTU size cannot in the general
> case be known, clearly we should never even try to fragment bundles to fit
> into MTU size.
>
> Let's say "never even try to fragment bundles into a statically determined
> MTU".  The dynamic determination described below amounts to determining a
> link MTU, but I am happy I know what you mean.
>
> Ø  Okay, “instantaneous MTU”.  I am inclined to prefer a more restrictive
> concept of MTU as being imposed by frame size limits (which are pretty
> intransigent) rather than by operational preference (which I think of as
> being discretionary), but if it helps us communicate then I am for it.
>
>
>
> convergence layer.  The job of dealing with them ought to be delegated to
> the convergence-layer protocol adapters, which in all cases that I can
> think of will segment and reassemble the transmitted data at the
> convergence layer, hop-by-hop, constrained by the varying MTU sizes on the
> various hops.  This segmentation does not produce BP fragments.
>
> Right.
>
>
>
> proactive fragmentation procedure I’ve been discussing attempts to do.  The
> intent of the fragmentation I’ve been talking about is to deal with
> interruption in connectivity, not to deal with MTU size.
>
> proactively fragmented bundle is not a decision that has to be based on
> nonexistent information (i.e., MTU size).  It is a decision that can be
> based on information that is much more accessible:
>
> ·       How many bytes of data per second can I transmit on this link?
> (Again, no instantaneous statistical accuracy is needed here.  If my link
> is TCP/IP over 100Base-T Ethernet, then I can send at most 12.5 million
> bytes per second.  If my link is S-band via a ClydeSpace radio that has
> been configured for transmission at 2 Mbps, then I can send at most 250,000
> bytes per second.)
>
> ·       How many seconds of wasted transmission due to connectivity loss
> am I willing to risk on this link?  If I know (from operational history)
> opportunistic and could be dropped at any moment, then maybe the only way I
> can be confident of forwarding any bundles at all is to be very
> conservative and risk only one second’s worth of transmission at a time.
> It’s a management decision.
>
> I proactively fragment to that size.  (And I do this fragmentation only at
> the moment when I am about to transmit over the link.  I would never
> propose that a bundle be proactively chopped up into N fragments at the
> source, before forwarding begins.  That would defeat the intent.)
>
> opportunity volume is for each hop, I would probably *want* to fragment the
> bundle to suit the minimum value over the hops on the path, rather than
> just fragmenting to the current hop 'MTU',  because otherwise I might get
> sub-optimal refragmentation.
>
>
>
> Ø  I don’t think you would, though.  Even with contact graph routing you
> don’t necessarily know the path (buffer occupancy conditions could force
> you to redirect at any point), and the notional contact opportunity volume
> that can be anticipated at the source doesn’t take into account the
> existing transmission backlogs at all the forwarding points.  I really
> think you get optimal fragmentation if you defer it until you’ve really got
> no alternative, at which point I think you also have got the best (most
> current and certain) information on which to base your decision.
>
> Certainly one can accomplish the same purpose with reactive fragmentation,
> and when we first thought up reactive fragmentation it sounded great to
> me.  But reactive fragmentation has two serious drawbacks:
>
> ·       It relies on signaling from the receiving node.  That introduces
> ·       It’s not secure.  The received fragment cannot be authenticated:
> if the bundle authentication block follows the payload block then it hasn’t
> been received, and if it precedes the payload block then it can’t be
> verified, because it covers the entire bundle rather than just the received
> fragment.  This at the very least exposes the network to denial-of-service
> attacks, and someone more ingenious than I am might find other ways to
> exploit it as well.
>
>
>
> Proactively fragmenting bundles as needed, where needed, at the moment of
> transmission avoids both problems: all information needed to control the
> fragmentation is available locally, and the fragment is a complete bundle
> with all applicable extension blocks attached.
>
> level in an opportunistic network.  Calculating the proactive bundle size
> would either have to be conservative (some number of s.d.'s below the mean
> contact opportunity volume) or acknowledge that it will be wrong a
> significant fraction of the time (and so you might need reactive
> fragmentation as well).
>
>
>
> Ø  Would it really only be probabilistic?  If you’ve got an opportunistic
> contact with some data mule, using TCP/IP/802.11g at the convergence layer,
> can’t you safely guess that your maximum transmission data rate is 54 Mbps,
> so 6.75 million bytes/sec?  And if it’s an opportunistic contact then you
> can lose it at any moment, so maybe the most you want to risk wasting on
> connection loss is 1 second’s worth of transmission, so your proactive
> fragmentation size is 6.75 million bytes.
>
> overhead business, so I think it is less of problem than you state for the
> all-terrestrial in-air use case. However, I agree that there are
> truly opportunistic with long RTTs and noisy links.  OTOH I am not sure how
> many hops are typical underwater - single hop is probably simpler to solve.
>
> I am not sure I understand your assessment of the 'authentication issue'.
> The BAB is security source to security destination (maybe e2e).  AFAIK it
> wouldn't normally be checked at an arbitrary intermediate node (no keys
> there generally) and if all goes well it can be checked in the reassembled
> bundle at the destination.  BUT, and its a big but, as Amy and others know
> from an extensive discussion about 18 months ago on the dtnrg list,
> reassembling bundles secured with BSP turns out to be something of a
> nightmare.   The need to know the whole bundle sounds like integrity rather
> than authentication  and if it is really going to mitigate DoS attacks, the
> receiver has to be able to abort close to bundle start.  This is more like
> securing the hop-by-hop link and authenticating the next/previous hop node
> than per bundle in the middle of the network.
>
>
>
> Ø  The security source and security destination of a BAB are supposed to
> be the local node and the neighboring security-aware node to which the
> bundle is currently being transmitted; RFC 6257 implies that this is
> mandatory (“the ciphersuite ID MUST be documented as a hop-by-hop [rather
> than end-to-end] authentication ciphersuite”) without saying so directly,
> but I think the Streamlined BSP Internet Draft is explicit on this point.
> When the receiving neighbor node reactively fragments a bundle it cannot
> authenticate this received fragmentary bundle.  Authentication of each
> received bundle is intended to defend the network (not the receiving node)
> against denial of service, by enabling the receiving node to discard
> inauthentic bundles rather than forward them into the network.  Reactive
> fragmentation defeats that defense.
>
> I definitely agree that we need to rethink very carefully the rules for
> handling extension blocks when fragmenting bundles.
>
> Very much so!
>
> But the need for that careful thinking doesn’t invalidate the approach,
> because the motivating operational scenario is still there: you have to
> deal with unplanned connectivity loss somehow.
>
> Yes
>
>
> Scott
>
>
>

---

From: Eric Travis <[email-masked]>
Date: Tue, 13 Jan 2015 16:40:43 -0500

Hi Kapali,

There is an atomic unit (bundle header and extension blocks) at layer N
that is too big to move forward.
There is a service provider at layer N-1 that can segment the Layer N
atomic unit into 2 or more chunks
that can be transferred and reassembled into an atomic unit delivered to
the peer Layer N.

Splitting Layer N-1 transfers across subsequent contact periods add some
complication, but are workable.

Thoughts?

Eric

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 14 Jan 2015 13:33:37 +0000

Hi Amy

Many thanks for the clarifications. I will get back to you after internalizing the interconnections between fragmentation rules in RFC6257 and RFC 5050 that you have mentioned. I shall respond by Friday this week.

In the meantime, please can you check if the attached flow chart is compliant with the bundle processing rules in Section 3.6 of RFC 6257<https://tools.ietf.org/html/rfc6257#section-3.6>?

I am also trying to associate the content of Section 3.9 of RFC 6257<https://tools.ietf.org/html/rfc6257#section-3.9> with our conversation. I believe that it already has hints for making reactive fragmentation work while ensuring security against DoS on DTN networks. We may need to use public key cryptography for BAB generation and verification. I am still trying to clarify this thought in my mind but I feel confident that this is possible.

Best regards
Kapali

From: Amy Alford [mailto:[email-masked]]
Sent: Wednesday, January 14, 2015 12:32 AM
To: I-Viswanathan, Kapaleeswaran
Cc: Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi Kapali,

BAB is hop by hop, but only between "security aware" nodes.  There may be DTN routers between a BAB security source and BAB security destination.  The only limitation is that they don't have BSP implementations.  (The second paragraph of RFC6257, section 2 <https://tools.ietf.org/html/rfc6257#section-2>  mentions this.)  Therefore, it is possible for fragmentation to occur after a BAB block is added.

Routers are not required to verify PIB blocks unless they are the security destination.  5050 says they are allowed to but not required to.  Depending on how key management is handled, they may not be able to verify signatures from some sources.    The 9th paragraph of RFC6257, section 3.6<https://tools.ietf.org/html/rfc6257#section-3.6> describes this.

No extension block can be fragmented, ever.  Bundles containing extension blocks can be fragmented unless the DO_NOT_FRAGMENT flag is set in the primary block.  Fragmentation applies to the payload only.  This is described in 5050, section 5.8<https://tools.ietf.org/html/rfc5050#section-5.8>.

If a bundle containing a PIB block is fragmented, the first fragment will contain the PIB (which now cannot be verified).  If a PIB block is added to a fragment, it will have a field that indicates which portion of the original payload it applies to (paragraph 5 of 6257, section 4.2<https://tools.ietf.org/html/rfc6257#section-4.2>).  So, any router receiving a fragment with a PIB block can distinguish these two cases.

Enforcing policy regarding PIB blocks is different from verifying the signature on a PIB block.  A BSP compliant router may choose to discard bundles with PIB blocks with invalid signatures, but also forward bundles with no PIB blocks.  So, a router has the option of forwarding fragments with unverifiable PIB blocks that refer to the whole bundle, while also discarding fragments with PIB blocks that apply to the current fragment but are invalid. 6257 states that routers must have security policies.  It says very little about what they must be or whether they are user configurable.

I pulled out 4 slides that illustrate 5050 extension blocks and fragmentation at a pretty high level here.<https://docs.google.com/presentation/d/1KVlDyr3GYoC_Q3G4xis0Qg-nIbFTV_8pS1Qs7inQDZM/pub?start=false&loop=false&delayms=60000&slide=id.g381b0bfc1_0465> The last slide is showing how convoluted the situation can get when a bundle is duplicated by a router (some of the routing schemes in DTN2 forward more than one copy of the same bundle).  A destination may receive a set of fragments which suffices to recover the payload but which contains overlapping fragments of the payload.  The first bullet point in the list in 5050, section 5.8<https://tools.ietf.org/html/rfc5050#section-5.8> refers to this. The same slide demonstrates adding a PIB to a fragment.

- Amy

On Tue, Jan 13, 2015 at 1:48 AM, I-Viswanathan, Kapaleeswaran <[email-masked]<mailto:[email-masked]>> wrote:
Elwyn >> Authentication of each received bundle is intended to defend the network (not the receiving node) against denial of service, by enabling the receiving node to discard inauthentic bundles rather than forward them into the network.  Reactive fragmentation defeats that defense.

Kapali >>

-        Status quo:

-        Problem:

•  BAB ensures that unauthorized nodes cannot inject bundles into a DTN instance

•        Side note: It is not specified that forwarders MUST remove and drop received BABs but this is implied (or implicit) because BAB is specified to provide only “hop-by-hop” data security.

•  Can be more than 1024 bytes because it MAY include sender’s certificate and certificate chain

•  PIB ensures that no DTN node can alter a bundle and avoid detection of the alteration by the destination or “next hop”

•        This security requirement that even the “next hop” must be able to verify PIB is making fragmentation problematic.

•  PCB ensures that only the destination can decrypt and have access to the plaintext corresponding to the payload data (ADU = Application Data Unit)

•  Keep BAB in the header and explicitly specify the dropping of received BABs from the header of the bundle, which cannot be fragmented

•  Thus PIBs, which can be arbitrarily long depending, can be fragmented

•  MitM (Man-in-the-Middle) on ADU can be prevented at the destination

•  BAB already ensures that unauthorized bundles cannot be injected into the DTN instance based on trust assumptions on forwarders

•  Policy can be enumerated as follows.

•        MUST NOT forward unauthorized bundles in this DTN instance

•        MUST forward unauthorized bundles in this DTN instance

•        ALL authorized bundles MUST be forwarded in this DTN instance

•        ALL authorized bundles MAY be forwarded in this DTN instance

•  Expensive authentication procedures at the router or other receiver end could result in Denial of Service.

•        http://eprints.qut.edu.au/419/1/Reid2004-VoIPDoS.pdf (Section 2.2)

•        http://www.google.com/patents/WO2008084271A2?cl=en (Application of ideas from Section 2.2 to securing communications in industrial automation controls)

•        Note that an authentication procedure is deemed to be expensive in relation to the computing power available at the receiver end.

From: Burleigh, Scott C (312B) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, January 13, 2015 4:04 AM
To: [email-masked]<mailto:[email-masked]>

Scott

Hi.

>  Okay, “instantaneous MTU”.  I am inclined to prefer a more restrictive concept of MTU as being imposed by frame size limits (which are pretty intransigent) rather than by operational preference (which I think of as being discretionary), but if it helps us communicate then I am for it.

•       How many bytes of data per second can I transmit on this link?  (Again, no instantaneous statistical accuracy is needed here.  If my link is TCP/IP over 100Base-T Ethernet, then I can send at most 12.5 million bytes per second.  If my link is S-band via a ClydeSpace radio that has been configured for transmission at 2 Mbps, then I can send at most 250,000 bytes per second.)

•       How many seconds of wasted transmission due to connectivity loss am I willing to risk on this link?  If I know (from operational history) that I lose connectivity about once an hour, then wasting 5 seconds of transmission per loss of connectivity would be a continuous bandwidth degradation of .139%; is that acceptable?  If I know that the link is opportunistic and could be dropped at any moment, then maybe the only way I can be confident of forwarding any bundles at all is to be very conservative and risk only one second’s worth of transmission at a time.  It’s a management decision.
.. which also has to take into account the overhead in the resulting ensemble of bundles and that is extension block dependent.

>  Sure.

>  I don’t think you would, though.  Even with contact graph routing you don’t necessarily know the path (buffer occupancy conditions could force you to redirect at any point), and the notional contact opportunity volume that can be anticipated at the source doesn’t take into account the existing transmission backlogs at all the forwarding points.  I really think you get optimal fragmentation if you defer it until you’ve really got no alternative, at which point I think you also have got the best (most current and certain) information on which to base your decision.

•       It relies on signaling from the receiving node.  That introduces additional transmission overhead, and it’s ineffective when round trip times are long, as in underwater or deep space communication or in scenarios with time-disjoint forward and return links.

•       It’s not secure.  The received fragment cannot be authenticated: if the bundle authentication block follows the payload block then it hasn’t been received, and if it precedes the payload block then it can’t be verified, because it covers the entire bundle rather than just the received fragment.  This at the very least exposes the network to denial-of-service attacks, and someone more ingenious than I am might find other ways to exploit it as well.

>  Would it really only be probabilistic?  If you’ve got an opportunistic contact with some data mule, using TCP/IP/802.11g at the convergence layer, can’t you safely guess that your maximum transmission data rate is 54 Mbps, so 6.75 million bytes/sec?  And if it’s an opportunistic contact then you can lose it at any moment, so maybe the most you want to risk wasting on connection loss is 1 second’s worth of transmission, so your proactive fragmentation size is 6.75 million bytes.

>  The security source and security destination of a BAB are supposed to be the local node and the neighboring security-aware node to which the bundle is currently being transmitted; RFC 6257 implies that this is mandatory (“the ciphersuite ID MUST be documented as a hop-by-hop [rather than end-to-end] authentication ciphersuite”) without saying so directly, but I think the Streamlined BSP Internet Draft is explicit on this point.  When the receiving neighbor node reactively fragments a bundle it cannot authenticate this received fragmentary bundle.  Authentication of each received bundle is intended to defend the network (not the receiving node) against denial of service, by enabling the receiving node to discard inauthentic bundles rather than forward them into the network.  Reactive fragmentation defeats that defense.

Scott

Moving on to details...

Thanks – Fred

Thanks – Fred

Scott,

Scott

Scott

dtn mailing list

dtn mailing list

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 14 Jan 2015 13:38:04 +0000

Hi Eric

Please can you provide me with the reference document(s) and section(s) for atomic unit at Layer N and service provider at Layer N - 1?  I need to understand the processing pre and post conditions along with the security assumptions before making up my mind on thoughts that may be valid.

Many thanks

Best regards
Kapali

From: Eric Travis [mailto:[email-masked]]
Sent: Wednesday, January 14, 2015 3:11 AM
To: I-Viswanathan, Kapaleeswaran
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi Kapali,
There is an atomic unit (bundle header and extension blocks) at layer N that is too big to move forward.
There is a service provider at layer N-1 that can segment the Layer N atomic unit into 2 or more chunks
that can be transferred and reassembled into an atomic unit delivered to the peer Layer N.
Splitting Layer N-1 transfers across subsequent contact periods add some complication, but are workable.

Thoughts?
Eric

Kapali >>

-        Status quo:

-        Problem:

Scott

Hi.

Scott

Moving on to details...

Thanks – Fred

Thanks – Fred

Scott,

Scott

Scott

dtn mailing list

dtn mailing list

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Wed, 14 Jan 2015 13:50:03 +0000

Hi
I thought that the paper on " Bundles Fragmentation in Vehicular Delay-Tolerant Networks " may help in our discussion.  http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5985945&tag=1

Also the vehicular opportunistic networking should be added to our use case.

And possibly the use of Toilet Paper Reactive Fragmentation while noting there conclusion about processing.

Thanks
Chuck 

Charles J. Sheehe III
Electronics Engineer

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of I-Viswanathan, Kapaleeswaran
Sent: Wednesday, January 14, 2015 8:38 AM
To: Eric Travis
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi Eric

Many thanks 

Best regards

Kapali

Hi Kapali,

Thoughts?

Eric 

On Tue, Jan 13, 2015 at 1:48 AM, I-Viswanathan, Kapaleeswaran <[email-masked] <mailto:[email-masked]> > wrote:

	Kapali >>

	-        Status quo: 

	-        Problem: 

	*  BAB ensures that unauthorized nodes cannot inject bundles into a DTN instance

	*        Side note: It is not specified that forwarders MUST remove and drop received BABs but this is implied (or implicit) because BAB is specified to provide only “hop-by-hop” data security.

	*  Can be more than 1024 bytes because it MAY include sender’s certificate and certificate chain

	*  PIB ensures that no DTN node can alter a bundle and avoid detection of the alteration by the destination or “next hop”

	*        This security requirement that even the “next hop” must be able to verify PIB is making fragmentation problematic. 

	*  PCB ensures that only the destination can decrypt and have access to the plaintext corresponding to the payload data (ADU = Application Data Unit)

	*  Keep BAB in the header and explicitly specify the dropping of received BABs from the header of the bundle, which cannot be fragmented

	*  Thus PIBs, which can be arbitrarily long depending, can be fragmented

	*  MitM (Man-in-the-Middle) on ADU can be prevented at the destination

	*  BAB already ensures that unauthorized bundles cannot be injected into the DTN instance based on trust assumptions on forwarders

	*  Policy can be enumerated as follows.

	*        MUST NOT forward unauthorized bundles in this DTN instance

	*        MUST forward unauthorized bundles in this DTN instance

	*        ALL authorized bundles MUST be forwarded in this DTN instance

	*        ALL authorized bundles MAY be forwarded in this DTN instance

	*  Expensive authentication procedures at the router or other receiver end could result in Denial of Service. 

	*        http://eprints.qut.edu.au/419/1/Reid2004-VoIPDoS.pdf (Section 2.2)

	*        http://www.google.com/patents/WO2008084271A2?cl=en (Application of ideas from Section 2.2 to securing communications in industrial automation controls)

	*        Note that an authentication procedure is deemed to be expensive in relation to the computing power available at the receiver end. 

	 

	From: Burleigh, Scott C (312B) [mailto:[email-masked] <mailto:[email-masked]> ] 
	Sent: Tuesday, January 13, 2015 4:04 AM
	To: [email-masked] <mailto:[email-masked]> 

	Scott

	From: Elwyn Davies [mailto:[email-masked]] 
	Sent: Monday, January 12, 2015 10:17 AM
	To: Burleigh, Scott C (312B); [email-masked] <mailto:[email-masked]> 
	Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

	Hi.

	*  Okay, “instantaneous MTU”.  I am inclined to prefer a more restrictive concept of MTU as being imposed by frame size limits (which are pretty intransigent) rather than by operational preference (which I think of as being discretionary), but if it helps us communicate then I am for it.

	Right.

		*       How many bytes of data per second can I transmit on this link?  (Again, no instantaneous statistical accuracy is needed here.  If my link is TCP/IP over 100Base-T Ethernet, then I can send at most 12.5 million bytes per second.  If my link is S-band via a ClydeSpace radio that has been configured for transmission at 2 Mbps, then I can send at most 250,000 bytes per second.)

		*       How many seconds of wasted transmission due to connectivity loss am I willing to risk on this link?  If I know (from operational history) that I lose connectivity about once an hour, then wasting 5 seconds of transmission per loss of connectivity would be a continuous bandwidth degradation of .139%; is that acceptable?  If I know that the link is opportunistic and could be dropped at any moment, then maybe the only way I can be confident of forwarding any bundles at all is to be very conservative and risk only one second’s worth of transmission at a time.  It’s a management decision.

	*  Sure.

	*  I don’t think you would, though.  Even with contact graph routing you don’t necessarily know the path (buffer occupancy conditions could force you to redirect at any point), and the notional contact opportunity volume that can be anticipated at the source doesn’t take into account the existing transmission backlogs at all the forwarding points.  I really think you get optimal fragmentation if you defer it until you’ve really got no alternative, at which point I think you also have got the best (most current and certain) information on which to base your decision.   

		*       It relies on signaling from the receiving node.  That introduces additional transmission overhead, and it’s ineffective when round trip times are long, as in underwater or deep space communication or in scenarios with time-disjoint forward and return links.

		*       It’s not secure.  The received fragment cannot be authenticated: if the bundle authentication block follows the payload block then it hasn’t been received, and if it precedes the payload block then it can’t be verified, because it covers the entire bundle rather than just the received fragment.  This at the very least exposes the network to denial-of-service attacks, and someone more ingenious than I am might find other ways to exploit it as well.

	*  Would it really only be probabilistic?  If you’ve got an opportunistic contact with some data mule, using TCP/IP/802.11g at the convergence layer, can’t you safely guess that your maximum transmission data rate is 54 Mbps, so 6.75 million bytes/sec?  And if it’s an opportunistic contact then you can lose it at any moment, so maybe the most you want to risk wasting on connection loss is 1 second’s worth of transmission, so your proactive fragmentation size is 6.75 million bytes.

	*  The security source and security destination of a BAB are supposed to be the local node and the neighboring security-aware node to which the bundle is currently being transmitted; RFC 6257 implies that this is mandatory (“the ciphersuite ID MUST be documented as a hop-by-hop [rather than end-to-end] authentication ciphersuite”) without saying so directly, but I think the Streamlined BSP Internet Draft is explicit on this point.  When the receiving neighbor node reactively fragments a bundle it cannot authenticate this received fragmentary bundle.  Authentication of each received bundle is intended to defend the network (not the receiving node) against denial of service, by enabling the receiving node to discard inauthentic bundles rather than forward them into the network.  Reactive fragmentation defeats that defense.

	Very much so!

	Yes

		Scott

		From: Amy Alford [mailto:[email-masked] <mailto:[email-masked]> ] 
		Sent: Sunday, January 11, 2015 4:28 PM
		To: Elwyn Davies
		Cc: Templin, Fred L; Burleigh, Scott C (312B); Eric Travis; [email-masked] <mailto:[email-masked]> 
		Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

		On Sun, Jan 11, 2015 at 4:01 PM, Elwyn Davies <[email-masked] <mailto:[email-masked]> > wrote:

			Hi, Fred.

			Moving on to details...

				Hi Amy,

				Thanks – Fred

				From: Amy Alford [mailto:[email-masked] <mailto:[email-masked]> ] 
				Sent: Friday, January 09, 2015 12:41 PM
				To: Templin, Fred L
				Cc: Eric Travis; Burleigh, Scott C (312B); [email-masked] <mailto:[email-masked]> 
				Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

				On Fri, Jan 9, 2015 at 11:19 AM, Templin, Fred L <[email-masked] <mailto:[email-masked]> > wrote:

					Thanks – Fred

					From: dtn [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Eric Travis

					Scott,

					Eric

					Scott

					Scott,

					Scott

					Eric

---

From: Eric Travis <[email-masked]>
Date: Wed, 14 Jan 2015 13:31:00 -0500

Hi Kapali,

If you need more information than I provided to address the abstract
query,
I apologize for being too abstract and withdraw the query.

Regards,

Eric

On Wed, Jan 14, 2015 at 8:38 AM, I-Viswanathan, Kapaleeswaran <
[email-masked]> wrote:

>  Hi Eric
>
>
>
> Please can you provide me with the reference document(s) and section(s)
> for atomic unit at Layer N and service provider at Layer N - 1?  I need to
> understand the processing pre and post conditions along with the security
> assumptions before making up my mind on thoughts that may be valid.
>
>
>
> Many thanks
>
>
>
> Best regards
>
> Kapali
>
>
>
> *Sent:* Wednesday, January 14, 2015 3:11 AM
> *To:* I-Viswanathan, Kapaleeswaran
>
> *Cc:* [email-masked]

---

From: Amy Alford <[email-masked]>
Date: Wed, 14 Jan 2015 15:27:25 -0500

Your flow chart misses removing the BAB in the case that an incoming bundle
has one but policy doesn't require it.

If a BAB contains no security destination, you are the security
destination.

The default ciphersuite also supports multiple parallel BABs to cover the
case where the last hop doesn't know what the next security aware node is.
So, your flowchart should take into account the possibility that the bundle
contains more than one BAB, but you are only the security destination for
one of them.

Other than those points, it looks right.  My read of the spec is that if
your security policy does not require a BAB, it's up to you whether you
validate any that you receive.
- Amy

On Wed, Jan 14, 2015 at 8:33 AM, I-Viswanathan, Kapaleeswaran <
[email-masked]> wrote:

>  Hi Amy
>
>
>
> Many thanks for the clarifications. I will get back to you after
> internalizing the interconnections between fragmentation rules in RFC6257
> and RFC 5050 that you have mentioned. I shall respond by Friday this week.
>
>
>
> In the meantime, please can you check if the attached flow chart is
> compliant with the bundle processing rules in Section 3.6 of RFC 6257
> <https://tools.ietf.org/html/rfc6257#section-3.6>?
>
>
>
> I am also trying to associate the content of Section 3.9 of RFC 6257
> <https://tools.ietf.org/html/rfc6257#section-3.9> with our conversation.
> I believe that it already has hints for making reactive fragmentation work
> while ensuring security against DoS on DTN networks. We may need to use
> public key cryptography for BAB generation and verification. I am still
> trying to clarify this thought in my mind but I feel confident that this is
> possible.
>
>
>
> Best regards
>
> Kapali
>
>
>
> *From:* Amy Alford [mailto:[email-masked]]
> *Sent:* Wednesday, January 14, 2015 12:32 AM
> *Cc:* Burleigh, Scott C (312B); [email-masked]
>
> <https://tools.ietf.org/html/rfc6257#section-2> mentions this.)
>  Therefore, it is possible for fragmentation to occur after a BAB block is
> added.
>
>
>
> <https://docs.google.com/presentation/d/1KVlDyr3GYoC_Q3G4xis0Qg-nIbFTV_8pS1Qs7inQDZM/pub?start=false&loop=false&delayms=60000&slide=id.g381b0bfc1_0465> The

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 14 Jan 2015 22:09:58 +0000

Let’s see if I can do a payload reassembly here… There is value in extracting key assertions for the Wiki. Before doing that, I wanted to see if I parsed the discussions correctly:

There are cases when a BPA itself must either fragment or drop a bundle.  One proposed case is when the storage available to the BPA is too small to hold the entire bundle. Another proposed case is when a particular CLA/CL does not support fragmentation and cannot support the bundle size.

To the extent that those cases (and others?) are reasonable to expect in a DTN overlay, it seems incorrect to say they are unsupported and to abandon bundles when those cases occur in the network. It seems that often BPA-level fragmentation is a WANT but in a few cases it is a NEED.

Assuming the BP specification continues to define some kind of fragmentation:

- BP fragmentation should be pro-active and not reactive. Reactive fragmentation should be implemented in a CL or perhaps in a CLA.

- The BP specification should identify the interface between the BPA and a CLA. This interface should include information on whether the CLA/CL can fragment bundles and could provide measurement data back to the BPA. A BPA should never fragment a bundle if it feels the CLA/CL would do a better job.

- There are certain network deployments where fragmentation-by-policy based on “instantaneously calculated MTU” might reduce the impact of retransmission over disrupted links. The decision (and wisdom) to attempt such an optimization is a matter of policy and does not require change to the specification to accommodate.

- There is no magic number for a bundle fragment size. A fragment size selected by a BPA does not guarantee subsequent fragmentation won’t happen. I.e., if you cannot fragment a fragment then there may be no purpose to fragmentation at all.

- There exist several problematic cases of extension-block handling in the presence of fragmentation, including (1) extension blocks that are too large to transmit, (2) extension blocks that change in size through the network, (3) adding extension blocks to fragments en-route.

- RFC6257 has several issues with fragmentation. SBSP may solve some or all of them.

-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 Burleigh, Scott C (312B)
Sent: Monday, January 12, 2015 5:34 PM
To: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

Hi.

Scott

Moving on to details...

Thanks – Fred

Thanks – Fred

Scott,

Scott

Scott

dtn mailing list

dtn mailing list

---

From: Eric Travis <[email-masked]>
Date: Wed, 14 Jan 2015 20:20:42 -0500

Ed,

Thanks for the time and effort expended to distill this.

Eric

On Wed, Jan 14, 2015 at 5:09 PM, Birrane, Edward J. <
[email-masked]> wrote:

>  Let’s see if I can do a payload reassembly here… There is value in
> extracting key assertions for the Wiki. Before doing that, I wanted to see
> if I parsed the discussions correctly:
>
>
>
> There are cases when a BPA itself must either fragment or drop a bundle.
> One proposed case is when the storage available to the BPA is too small to
> hold the entire bundle. Another proposed case is when a particular CLA/CL
> does not support fragmentation and cannot support the bundle size.
>
>
>
> To the extent that those cases (and others?) are reasonable to expect in a
> DTN overlay, it seems incorrect to say they are unsupported and to abandon
> bundles when those cases occur in the network. It seems that often
> BPA-level fragmentation is a WANT but in a few cases it is a NEED.
>
>
>
> - BP fragmentation should be pro-active and not reactive. Reactive
> fragmentation should be implemented in a CL or perhaps in a CLA.
>
>
>
> - The BP specification should identify the interface between the BPA and a
> CLA. This interface should include information on whether the CLA/CL can
> fragment bundles and could provide measurement data back to the BPA. A BPA
> should never fragment a bundle if it feels the CLA/CL would do a better job.
>
>
>
> - There are certain network deployments where fragmentation-by-policy
> based on “instantaneously calculated MTU” might reduce the impact of
> retransmission over disrupted links. The decision (and wisdom) to attempt
> such an optimization is a matter of policy and does not require change to
> the specification to accommodate.
>
>
>
> - There is no magic number for a bundle fragment size. A fragment size
> selected by a BPA does not guarantee subsequent fragmentation won’t happen.
> I.e., if you cannot fragment a fragment then there may be no purpose to
> fragmentation at all.
>
>
>
> - There exist several problematic cases of extension-block handling in the
> presence of fragmentation, including (1) extension blocks that are too
> large to transmit, (2) extension blocks that change in size through the
> network, (3) adding extension blocks to fragments en-route.
>
>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 15 Jan 2015 16:36:54 +0000

I think one aspect of SBSP is especially relevant to this conversation.  SBSP removes “security destination” from the security block structure.  (The rationale for this is too lengthy to go into here but, for example, it eliminates the possibility of conflicting security destinations in different blocks mandating routes that make no sense.)  Instead, all security destinations are implicit.  The security destination of every block other than the BAB is the destination of the bundle.  The security destination of the BAB is always simply the node that receives the bundle, in any hop-by-hop transmission, and the security source of the BAB is always the node that sent the bundle over that hop.

This eliminates one of the problems Amy mentioned earlier, the possibility of fragmentation occurring after a BAB block is added but before it is verified (because there is a non-security-aware router between a BAB security source and BAB security destination).  By definition, in SBSP the BAB security destination always receives the bundle directly from the BAB security source.

Of course it is still possible for the receiving node (the BAB security destination) to be non-security aware and for it to fragment the received bundle.  But at that point the BAB that accompanied the received bundle has been stripped off; the receiver(s) of the fragments will simply receive bundles lacking BABs.

Scott

From: Birrane, Edward J. [mailto:[email-masked]]
Sent: Wednesday, January 14, 2015 2:10 PM
To: Burleigh, Scott C (312B); [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

….

-Ed

---

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Thu, 15 Jan 2015 18:06:38 +0000

Hi Eric

I respect your decision on collaboration irrespective of its content.

I requested information from you because I believed that without it I was unable generate reliable thoughts that I could share with you and this mailing list. The following are precise reasons for my information requests.

1.      Security of a system design is highly contextual.

2.      Security of a system design is always in its details – the adage ‘devil is in details’ may be a best fit when talking about analysis and design of system security.

a.      More security will make it unusable.

b.      Less security will make it a nuisance and therefore reduce its value to the society.

3.      While abstraction is a great tool for software functionality design, software security design requires detailing in addition. Thus, we are forced to look at abstracts as well as details at the same time and this, in my experience till date, complicates the exercise of system security design.

a.      A classic example is the TCP SYN flooding attack, which happened after nearly 20 years of the design of TCP, and the SYN-COOKIE design update that Linux kernels ship since 1997.

                                                    i.     Security analysis requires the designers to think about deviations from protocol (soundness of security) as well as conformance to protocol (completeness of security).

                                                   ii.     This requires details in addition to abstraction.

b.      While abstraction helps us reason about presence of functionality, it is details that helps us reason about absence of unintended side-effects.

c.      While specification of functionality deals with its presence, specification of security can only deal with its absence – in other words, only absence of security (or insecurity) can be specified as the research community is yet to find how to specify its presence. Even in cryptography, we do not prove security, we only reduce the possibility of insecurity to hard problems.

4.      Since we are talking about systems that need to be deployed on space systems that may be physically inaccessible and security systems always need at least one manual security configuration on devices (security bootstrapping), I had to understand status-quo, validate my understanding of status-quo, find well-defined problems, try to find a solution for the same, and the prove (in a reasonably objective manner) that the solution does indeed solve the problem but does not open new security vulnerability in the system design.

5.      Although I am optimistic that a solution may exist to allow reactive fragmentation while protecting the network against unauthorized insertion of bundles in a manner that is reasonably safe from Denial of Service attacks, I need more information to understand the context, problem, solution, and solution’s efficacy.

a.      When you mentioned about atomic unit Layer N and service provider at Layer N-1, I had to understand its context and content before I can have reliable thoughts that I can share with you and this mailing list.

I sincerely hope that you will understand that my mail was purely objective. I did not and do not hold anything personal against you or anybody else. I only seek to further the state of art while advancing my own understanding of secure distributed systems with a clear watch on time to market, which is a reason for my participation in this working group’s mailing list.

Have a nice day.

Best regards
Kapali

From: Eric Travis [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 12:01 AM
To: I-Viswanathan, Kapaleeswaran
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi Kapali,
If you need more information than I provided to address the abstract query,
I apologize for being too abstract and withdraw the query.

Regards,
Eric

On Wed, Jan 14, 2015 at 8:38 AM, I-Viswanathan, Kapaleeswaran <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric

Many thanks

Best regards
Kapali

Hi Kapali,

Thoughts?
Eric

---

From: Amy Alford <[email-masked]>
Date: Thu, 15 Jan 2015 13:12:05 -0500

If a non-security aware node receives a BAB, there's no mandate that they
remove it.  I expect them to forward it and set the "block was forwarded
without processing" flag.

In SBSP, I thought we decided that bundles with BAB blocks must have the
"do not fragment" flag set.  I don't see that in the draft.  It says first
fragment, then BAB.  It also says that non-security aware nodes might
fragment after BAB anyway, and in that case, reassemble before validating.
I'm trying to convince myself that receivers can distinguish whether they
validate then reassemble or reassemble then validate every time.
- Amy

On Thu, Jan 15, 2015 at 11:36 AM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  I think one aspect of SBSP is especially relevant to this conversation.
> SBSP removes “security destination” from the security block structure.
> (The rationale for this is too lengthy to go into here but, for example, it
> eliminates the possibility of conflicting security destinations in
> different blocks mandating routes that make no sense.)  Instead, all
> security destinations are implicit.  The security destination of every
> block other than the BAB is the destination of the bundle.  The security
> destination of the BAB is always simply the node that receives the bundle,
> in any hop-by-hop transmission, and the security source of the BAB is
> always the node that sent the bundle over that hop.
>
>
>
> This eliminates one of the problems Amy mentioned earlier, the possibility
> of fragmentation occurring after a BAB block is added but before it is
> verified (because there is a non-security-aware router between a BAB
> security source and BAB security destination).  By definition, in SBSP the
> BAB security destination always receives the bundle directly from the BAB
> security source.
>
>
>
> Of course it is still possible for the receiving node (the BAB security
> destination) to be non-security aware and for it to fragment the received
> bundle.  But at that point the BAB that accompanied the received bundle has
> been stripped off; the receiver(s) of the fragments will simply receive
> bundles lacking BABs.
>
>
>
> Scott
>
>
>
> *From:* Birrane, Edward J. [mailto:[email-masked]]
> *Sent:* Wednesday, January 14, 2015 2:10 PM
> *Subject:* RE: [dtn] Proactive Fragmentation, was: Internet Draft for
> Bundle Security
>
>
>
> ….
>
>
>

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Thu, 15 Jan 2015 18:12:52 +0000

Hi Amy:

If you time permits, please can you update the flow chart? The reason for my request is because I am unable to visualize how to change the flow chart using your inputs. I am attaching the original PPT to this mail.

PS:

1)      If you are able to update the flowchart, please modify the file by suffixing it with ‘_Amy’ so that we can keep track of versions. I intend to create additional pictorial representations of various DTN RFCs and make the same available to this WG. The pictorial representations may help us in finding issues as well as finding novel solutions.

2)      I am unable to access Google docs, so if the file size is small, kindly send them as attachments.

Many thanks.

Best regards
Kapali

Sent: Thursday, January 15, 2015 1:57 AM

Your flow chart misses removing the BAB in the case that an incoming bundle has one but policy doesn't require it.

If a BAB contains no security destination, you are the security destination.

The default ciphersuite also supports multiple parallel BABs to cover the case where the last hop doesn't know what the next security aware node is.  So, your flowchart should take into account the possibility that the bundle contains more than one BAB, but you are only the security destination for one of them.

Other than those points, it looks right.  My read of the spec is that if your security policy does not require a BAB, it's up to you whether you validate any that you receive.
- Amy

On Wed, Jan 14, 2015 at 8:33 AM, I-Viswanathan, Kapaleeswaran <[email-masked]<mailto:[email-masked]>> wrote:
Hi Amy

Best regards
Kapali

From: Amy Alford [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 14, 2015 12:32 AM
To: I-Viswanathan, Kapaleeswaran
Cc: Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>

Hi Kapali,

- Amy

Kapali >>

-        Status quo:

-        Problem:

Scott

Hi.

Scott

Moving on to details...

Thanks – Fred

Thanks – Fred

Scott,

Scott

Scott

dtn mailing list

dtn mailing list

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 15 Jan 2015 19:18:41 +0000

I wrote this looking only at the SBSP draft, which says in 3.3.1 “A BAB received in a bundle MUST be stripped before the bundle is forwarded.”  I think this is perhaps a little ambiguous.  Strictly speaking, as written it applies only to security-aware nodes, but I thought the intent was that it ought to apply universally: section 2 says “BABs operate between topologically adjacent nodes”, and that principle would be violated if security-aware node C received a bundle forwarded by non-security-aware node B with a BAB attached by security-aware node A.

We could easily preserve the principle by requiring that the “Discard block if it can’t be processed” flag be set in all BABs.  The draft doesn’t say this, though, so maybe I’m mistaken.

However, the fact that the draft doesn’t require that bundles with BABs have the “do not fragment” flag set does make more sense if BABs are supposed to be stripped: the flag isn’t needed, because at the time you’d be considering fragmentation the bundle would no longer have a BAB.  Then, once the fragmentation has happened (if it has happened), you can safely attach a BAB to each fragment.

“The decision to fragment a bundle MUST be made prior to adding authentication to the bundle.  The bundle MUST first be fragmented and authentication applied to each individual fragment.”  (section 3.4)

On the other hand, you are right that the draft says “If a bundle with a BAB is fragmented by a non-security-aware node, then the entire bundle must be re-assembled before being processed to allow for the proper verification of the BAB.”  On reflection, I think this is an inconsistency in the spec: we really never want that condition to arise, do we?  Everything becomes way simpler if we just require that the “Discard block if it can’t be processed” flag be set in all BABs.

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 10:12 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

If a non-security aware node receives a BAB, there's no mandate that they remove it.  I expect them to forward it and set the "block was forwarded without processing" flag.

In SBSP, I thought we decided that bundles with BAB blocks must have the "do not fragment" flag set.  I don't see that in the draft.  It says first fragment, then BAB.  It also says that non-security aware nodes might fragment after BAB anyway, and in that case, reassemble before validating.  I'm trying to convince myself that receivers can distinguish whether they validate then reassemble or reassemble then validate every time.
- Amy

On Thu, Jan 15, 2015 at 11:36 AM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
I think one aspect of SBSP is especially relevant to this conversation.  SBSP removes “security destination” from the security block structure.  (The rationale for this is too lengthy to go into here but, for example, it eliminates the possibility of conflicting security destinations in different blocks mandating routes that make no sense.)  Instead, all security destinations are implicit.  The security destination of every block other than the BAB is the destination of the bundle.  The security destination of the BAB is always simply the node that receives the bundle, in any hop-by-hop transmission, and the security source of the BAB is always the node that sent the bundle over that hop.

Scott

From: Birrane, Edward J. [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 14, 2015 2:10 PM
To: Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

….

-Ed

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

---

From: Amy Alford <[email-masked]>
Date: Thu, 15 Jan 2015 14:26:39 -0500

Maybe that was the flag I was thinking of.  Does anyone have a use case in
which non-security aware routers are interspersed with routers that want to
do hop-by-hop authentication?

I can see wanting to build a sub-network that was closed to traffic
originating elsewhere, but which also routes bundles across an open
network.  In that case, it isn't really hop by hop authentication.  I think
PIB would solve that.
- Amy

On Thu, Jan 15, 2015 at 2:18 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  I wrote this looking only at the SBSP draft, which says in 3.3.1 “A BAB
> received in a bundle MUST be stripped before the bundle is forwarded.”  I
> think this is perhaps a little ambiguous.  Strictly speaking, as written it
> applies only to security-aware nodes, but I thought the intent was that it
> ought to apply universally: section 2 says “BABs operate between
> topologically adjacent nodes”, and that principle would be violated if
> security-aware node C received a bundle forwarded by non-security-aware
> node B with a BAB attached by security-aware node A.
>
>
>
> We could easily preserve the principle by requiring that the “Discard
> block if it can’t be processed” flag be set in all BABs.  The draft doesn’t
> say this, though, so maybe I’m mistaken.
>
>
>
> However, the fact that the draft doesn’t require that bundles with BABs
> have the “do not fragment” flag set does make more sense if BABs are
> supposed to be stripped: the flag isn’t needed, because at the time you’d
> be considering fragmentation the bundle would no longer have a BAB.  Then,
> once the fragmentation has happened (if it has happened), you can safely
> attach a BAB to each fragment.
>
>
>
> “The decision to fragment a bundle MUST be made prior to adding
> authentication to the bundle.  The bundle MUST first be fragmented and
> authentication applied to each individual fragment.”  (section 3.4)
>
>
>
> On the other hand, you are right that the draft says “If a bundle with a
> BAB is fragmented by a non-security-aware node, then the entire bundle must
> be re-assembled before being processed to allow for the proper verification
> of the BAB.”  On reflection, I think this is an inconsistency in the spec:
> we really never want that condition to arise, do we?  Everything becomes
> way simpler if we just require that the “Discard block if it can’t be
> processed” flag be set in all BABs.
>
>
>
> Scott
>
>
>
> *Sent:* Thursday, January 15, 2015 10:12 AM

---

From: Amy Alford <[email-masked]>
Date: Thu, 15 Jan 2015 14:43:36 -0500

It sounds like the question bouncing around can be reduced to:
Is there a use case where proactive fragmentation has too much overhead and
fragments must traverse distinct paths?

If fragments don't need to traverse distinct paths, pushing fragmentation
down to the convergence layer clears up a lot of problems with extension
blocks.

The example they give in the VDTN requires fragments to traverse different
paths (since two specific vehicles are unlikely to pass each other twice
and bundles are too big to transmit in a single contact).

They conclude that reactive fragmentation is substantially more efficient,
but the overhead numbers for proactive fragmentation seem high.  They split
a 100k bundle into 4k fragments, and said the total amount of data to
transfer became 117k.  That's over 500 bytes of header per fragment.  My
memory was that ​a primary block is around 70 bytes, plus uri data.  Is
anyone else sure on that number?

The VDTN is using epidemic routing of fragments. I wonder if it's the case
that these sort of highly unpredictable links that make you want reactive
fragmentation at the bundle layer are always going to be using epidemic
routing.  If so, would network coding work better altogether?

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 15 Jan 2015 20:15:47 +0000

In Line:

The example they give in the VDTN requires fragments to traverse different paths (since two specific vehicles are unlikely to pass each other twice and bundles are too big to transmit in a single contact).

I think this is a valid use case.  However, I know of ICN being used/demonstrated for this case – or at least for vehicle data mule applications.  I think ICN and publish/subscribe may win out over DTN in this space – particularly if it is informations such as road conditions, or traffic or "Why is traffic stopped, what's happening ahead?"

They conclude that reactive fragmentation is substantially more efficient, but the overhead numbers for proactive fragmentation seem high.  They split a 100k bundle into 4k fragments, and said the total amount of data to transfer became 117k.  That's over 500 bytes of header per fragment.

But this must be some very specific case with assumed contact times, radios, etc…  I would have to read the report, but 117K seems like not a whole lot of data to transfer in a epidemic routing scenario.  It seems like these numbers should depend on how many nodes, how they become connected and how many hops are permitted.

My memory was that ​a primary block is around 70 bytes, plus uri data.  Is anyone else sure on that number?

I'm pretty sure that is the number for RFC5050 – 70 bytes  uncompressed.

The VDTN is using epidemic routing of fragments. I wonder if it's the case that these sort of highly unpredictable links that make you want reactive fragmentation at the bundle layer are always going to be using epidemic routing.  If so, would network coding work better altogether?

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 15 Jan 2015 20:16:46 +0000

I think you might do this by configuring the gateways into the sub-network to require BABs on all bundles forwarded from nodes outside the sub-net but not on bundles forwarded from nodes inside the sub-net.  It would be hop-by-hop authentication, but only at the boundary and only on the outer surface of that boundary.

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 11:27 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Maybe that was the flag I was thinking of.  Does anyone have a use case in which non-security aware routers are interspersed with routers that want to do hop-by-hop authentication?

I can see wanting to build a sub-network that was closed to traffic originating elsewhere, but which also routes bundles across an open network.  In that case, it isn't really hop by hop authentication.  I think PIB would solve that.
- Amy

On Thu, Jan 15, 2015 at 2:18 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
I wrote this looking only at the SBSP draft, which says in 3.3.1 “A BAB received in a bundle MUST be stripped before the bundle is forwarded.”  I think this is perhaps a little ambiguous.  Strictly speaking, as written it applies only to security-aware nodes, but I thought the intent was that it ought to apply universally: section 2 says “BABs operate between topologically adjacent nodes”, and that principle would be violated if security-aware node C received a bundle forwarded by non-security-aware node B with a BAB attached by security-aware node A.

Scott

Scott

….

-Ed

---

---

From: Amy Alford <[email-masked]>
Date: Thu, 15 Jan 2015 15:23:48 -0500

I've updated the flow chart and attached it off-list, but you should be
aware this isn't the only 6257 compliant processing order.  DTN2 walks the
block list validating BSP blocks.  If any fail validation, the bundle is
discarded.  A BAB would fail validation if the security destination is the
current node and the HMAC is wrong.  A BAB would pass validation if the
HMAC verifies.  BABs with mismatching security destinations or no security
destination and an invalid HMAC are neutral.  After the block walking pass,
DTN2 verifies the bundle matches security policy.  If policy requires a
BAB, it checks that at least one BAB passed validation.

The difference is that DTN2 will throw out a bundle with an invalid BAB
that lists the current node as the security destination, even if policy
doesn't require a BAB.

On Thu, Jan 15, 2015 at 1:12 PM, I-Viswanathan, Kapaleeswaran <
[email-masked]> wrote:

>  Hi Amy:
>
>
>
> If you time permits, please can you update the flow chart? The reason for
> my request is because I am unable to visualize how to change the flow chart
> using your inputs. I am attaching the original PPT to this mail.
>
>
>
> PS:
>
> 1)      If you are able to update the flowchart, please modify the file
> by suffixing it with ‘_Amy’ so that we can keep track of versions. I intend
> to create additional pictorial representations of various DTN RFCs and make
> the same available to this WG. The pictorial representations may help us in
> finding issues as well as finding novel solutions.
>
> *Sent:* Thursday, January 15, 2015 1:57 AM
>
> Your flow chart misses removing the BAB in the case that an incoming
> bundle has one but policy doesn't require it.
>
>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 15 Jan 2015 20:27:58 +0000

Certainly the more fragments you generate, the more overhead you are going to incur, but that’s true whether your fragmentation is reactive or proactive.  If you do just-in-time proactive fragmentation rather than arbitrarily chopping the bundle up into pieces at the source, the number of fragments (and the resulting increase in overhead) can be limited to what you’re willing to tolerate.

And reactive fragmentation imposes overhead of its own that proactive fragmentation does not: you’ve got to have additional acknowledgment traffic from the receiving node, and that traffic flow is continuous whether you fragment or not.

Judging reactive vs proactive fragmentation strictly on the basis of imposed overhead seems awfully difficult to me, since it depends so completely on the specifics of your convergence-layer protocol, your proactive fragmentation policy, whether or not you’re using CBHE, and a lot of other factors.  I think what’s more salient is that reactive fragmentation is simply incompatible with bundle authentication.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Amy Alford
Sent: Thursday, January 15, 2015 11:44 AM
To: Sheehe, Charles J. (GRC-LCA0)
Cc: I-Viswanathan, Kapaleeswaran; Eric Travis; [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

It sounds like the question bouncing around can be reduced to:
Is there a use case where proactive fragmentation has too much overhead and fragments must traverse distinct paths?

If fragments don't need to traverse distinct paths, pushing fragmentation down to the convergence layer clears up a lot of problems with extension blocks.

They conclude that reactive fragmentation is substantially more efficient, but the overhead numbers for proactive fragmentation seem high.  They split a 100k bundle into 4k fragments, and said the total amount of data to transfer became 117k.  That's over 500 bytes of header per fragment.  My memory was that ​a primary block is around 70 bytes, plus uri data.  Is anyone else sure on that number?

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 15 Jan 2015 20:49:21 +0000

Actually  RFC5050 says exactly nothing about the size of a primary block, because it can vary so wildly; the RFC only defines the structure.  If you use ipn-scheme endpoint IDs and all of your nodes numbers are less than 128, and you’ve got a working clock, and your bundle time-to-live is limited to about 2 minutes, then the size of the primary block on the wire (CBHE-encoded) is 21 bytes.  It goes up from there.  If your endpoint IDs are all written in the dtn scheme and your scheme-specific parts are all 25 bytes (like “//amroc.jpl.nasa.gov/mail”) and your bundle time-to-live can be up to a day, then the size of the primary block on the wire is 242 bytes.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Thursday, January 15, 2015 12:16 PM
To: Amy Alford; Sheehe, Charles J. (GRC-LCA0)
Cc: I-Viswanathan, Kapaleeswaran; Eric Travis; [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

…

---

From: "Birrane, Edward J." <[email-masked]>
Date: Thu, 15 Jan 2015 23:06:31 +0000

Scott, Amy,

  We left this open in the spec. From 2.4:

“The block processing control flags value can be set to whatever
      values are required by local policy.  Cipher suite designers
      should carefully consider the effect of setting flags that either
      discard the block or delete the bundle in the event that this
      block cannot be processed.”

  I think the specification is ambiguous, but perhaps in a different manner than discussed. I.e., I claim Case 3 below is the ambiguity whereas I believe you are claiming Case 4 below is an ambiguity.

  First, some definitions.  A validated BAB means that a bundle was received, without modification, from the (topologically adjacent) BAB security source. When not asserted, the security source is presumed to be the BPA that transmitted the bundle to the receiving node.  The following convention may help when describing, textually, node topologies: SN# refers to a security-aware bundle node (SN1, SN2, etc…) and N# refers to a non-security-aware node(N1, N2, …). Prepending an F_ to the label implies the node will fragment the bundle (F_SN1, F_N2, etc…).

  I think (at least) 4 cases are worth mentioning here.

- Case 1: SN1 -> SN2
- Description:  Two security-aware adjacent nodes exchange a bundle with a BAB.
- Expectation: Absent malice, the BAB validates.

- Case 2: F_SN1 -> SN3
- Description: Two security-aware adjacent nodes exchange a bundle which is first fragmented. A BAB is added to each fragment and each fragment is authenticated on receipt.
- Expectation: Absent malice, each fragment gets a BAB at F_SN1 which authenticates at SN3 and is then removed prior to re-assembly or forwarding.

- Case 3: SN1 -> N2 -> SN3
- Description: Unbeknownst to SN1, the next hop will be to N2 which passes the bundle with BAB on to SN3.
- Expectation: The BAB should fail to validate. This naturally occurs if N2 changes anything in the bundle, or if SN3 uses N2’s identity when processing the BAB signatures based on the cipher suite. However, there is a case where N2 does not change the bundle and SN3 pulls the identity of SN1 from the security source option in the BAB itself and successfully validates the bundle.

- Case 4: SN1 -> F_N2 ->SN3
- Description: A bundle with a BAB routes through a non-security-aware node which fragments the bundle. At least one BAB remains with at least one fragment and is received by SN3.
- Expectation: SN3 fails to validate the BAB and the bundle is dropped. The bundle was modified between its security source and the next hop. By definition, it should not authenticate.  Removing the BAB at F_N2 we subvert authentication… consider a malicious F_N2.

So, to answer Amy’s question, if I receive a fragment with a BAB, I try and validate the fragment using the BAB.

- If the BAB validates, the BAB was meant for the fragment and I continue processing the fragment.

- If the BAB fails to validate, there are two possibilities: (A) The BAB was meant for the fragment and the fragment was modified en-route, or (B) the BAB was meant for some superset of the fragment. Either way, the bundle has clearly been modified since leaving the security source and we should proceed with caution by considering the fragment not authenticated and handled in accordance with policy.

-Ed

---

From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: Thursday, January 15, 2015 2:19 PM
To: Amy Alford
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

Scott

….

-Ed

---

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 16 Jan 2015 00:07:47 +0000

So, Ed, does the validity of case 3 mean that the statement in section 2 that “BABs operate between topologically adjacent nodes” is incorrect and should be revised?  Since SN1 and SN3 are not topologically adjacent?

I again suggest that everything becomes much simpler, without loss of generality, if we exclude cases 3 and 4 by setting the “Discard block if it can’t be processed” flag in all BABs.  Is there a downside to this that I am not spotting?

Scott

From: Birrane, Edward J. [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 3:07 PM
To: Burleigh, Scott C (312B); Amy Alford
Cc: [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott, Amy,

- Case 1: SN1 -> SN2

- Case 2: F_SN1 -> SN3

-Ed

---

Scott

Scott

….

-Ed

---

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 16 Jan 2015 00:57:41 +0000

Just wondering – it may help to get some input from users.  Who is implementing BAB in their networks and what is the topology?  The information may help reduce the problem space that needs to be considered.

Will

From: <Burleigh>, "Scott C (312B)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 15, 2015 7:07 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

……

……..

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Fri, 16 Jan 2015 10:37:07 +0000

Hi Amy

Many thanks for updates to the file and clarifications. I will study the flow chart provided by you.

I have a query in the meantime. Let’s say that DTN Node A wishes to send a bundle to DTN node B. For this to happen Nodes A and B must share the same HMAC key (message authentication key) associated with the hop (A, B) in their respective local key databases. How is this achieved? Is it pre-configured key or via a key management system?

Many thanks.

Best regards
Kapali

Sent: Friday, January 16, 2015 1:54 AM

I've updated the flow chart and attached it off-list, but you should be aware this isn't the only 6257 compliant processing order.  DTN2 walks the block list validating BSP blocks.  If any fail validation, the bundle is discarded.  A BAB would fail validation if the security destination is the current node and the HMAC is wrong.  A BAB would pass validation if the HMAC verifies.  BABs with mismatching security destinations or no security destination and an invalid HMAC are neutral.  After the block walking pass, DTN2 verifies the bundle matches security policy.  If policy requires a BAB, it checks that at least one BAB passed validation.

The difference is that DTN2 will throw out a bundle with an invalid BAB that lists the current node as the security destination, even if policy doesn't require a BAB.

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Fri, 16 Jan 2015 12:32:41 +0000

Ed - BP fragmentation should be pro-active and not reactive. Reactive fragmentation should be implemented in a CL or perhaps in a CLA.

n  This statement implies that reactively-fragmented-fragment reassembly must be done at CL or CLA level. And that proactively-fragmented-fragment reassembly must be done at BPA level.

§  If CL is TCP, then reassembly is by TCP. Nothing more to specify.

§  If CL is UDP, then reassembly is at CLA. This means additional storage and time-out functionality must be implemented by UDP CLAs.

§  With LTP, it is again likely to be implemented in CLA because LTP behaves both like UDP or TCP depending on the channel (green or red) that is used to transmit the bundle or parts of bundle.

·        One extra spec for LTP CLA may be needed:

·        Suppose a bundle, B, was fragmented into B1 and B2 by LTP CLA. If there is a delay between the opportunity for sending B1 and that for sending B2, how long should this delay be? This delay may be calculated by BPA based on inputs from LTP.

·        To avoid these complications, it may be safe to assume that bundle fragments be transmitted over red channel.

§  Useful reference: http://www.pcvr.nl/tcpip/udp_user.htm

Ed - There exist several problematic cases of extension-block handling in the presence of fragmentation, including (1) extension blocks that are too large to transmit, (2) extension blocks that change in size through the network, (3) adding extension blocks to fragments en-route.

·        Is there a need for ESB? Can it be dispensed with?

Ed - RFC6257 has several issues with fragmentation. SBSP may solve some or all of them.

·        A list of issues with RFC 6257 needs to be created so as to ensure that SBSP addresses all identified issues.

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Fri, 16 Jan 2015 12:51:52 +0000

Scot> I think one aspect of SBSP is especially relevant to this conversation.  SBSP removes “security destination” from the security block structure.  (The rationale for this is too lengthy to go into here but, for example, it eliminates the possibility of conflicting security destinations in different blocks mandating routes that make no sense.)  Instead, all security destinations are implicit.  The security destination of every block other than the BAB is the destination of the bundle.  The security destination of the BAB is always simply the node that receives the bundle, in any hop-by-hop transmission, and the security source of the BAB is always the node that sent the bundle over that hop.

>> This refinement can reduce the complexity of the logic and specification for routers and receiving BPA.  The assumption is that there is no difference between a security hop and a communication hop as is the case in RFC 6257 as Amy mentioned. In other words, all bundles received from a router that is non-security-aware must be considered as insecure (vis-à-vis denial of service attacks). But, the policy to accept or reject such bundles is at the receiving end.
>> We are also assuming that there is and will be nothing called multi-cast bundle.  A bundle will have a single destination and, therefore, contain either a single or no BAB.

>> Also, it is essential to separate the concerns for BAB and PIB. Routers must only examine BAB, if one is present, while only the CLA that is the security destination of PIB must verify PIB. Intermediate routers must not verify PIB as already may be the case as Amy has clarified.

>> It would be useful to provide a formal picture like a state transition diagram or a flow chart for BAB processing and other processing similar to the state transition diagram in TCP specification. https://tools.ietf.org/html/rfc793#section-3.2 (page 22)

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Fri, 16 Jan 2015 13:55:50 +0000

Hi

My opinion

The only way this really works is with pre shared keys.

What happens when a node out of sync with keys or it must be power cycled what is you out of band mechanism to reload/update the keys? 

Trusted boot with permanent master key. Comes up in clear commanded over the same DTN link and receives another set of keys to work from.

So how does this trust chain work and how will these networks be managed? I do not foresee sharing of these networks.

Chuck

Charles J. Sheehe III
Electronics Engineer

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of I-Viswanathan, Kapaleeswaran
Sent: Friday, January 16, 2015 5:37 AM
To: Amy Alford
Cc: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi Amy 

Many thanks. 

Best regards

Kapali

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 16 Jan 2015 15:42:46 +0000

Not exactly.  There is an important distinction in BP between the receiver of a bundle and the destination of the bundle: each forwarding node on the end-to-end path receives the bundle and then sends it, but the destination node is the final receiver (rather than forwarding the bundle to another node it delivers the bundle’s content to an application).  So a bundle can be multicast to any number of final destination nodes, but this is orthogonal to bundle authentication between sending and receiving nodes.  Each sender/receiver pair (hop) in the multicast tree may implement authentication using a different BAB, while each final destination node may verify the integrity of the bundle’s payload by checking its single PIB (or, in SBSP, its BIB).

Also, the CLA should never see any BSP blocks at all.  Verification of the PIB is a BSP function that is accomplished by the bundle protocol agent, not the CLA.  Intermediate forwarding nodes may validate the PIB if they wish, but the spec doesn’t require them to do that.

Scott

From: I-Viswanathan, Kapaleeswaran [mailto:[email-masked]]
Sent: Friday, January 16, 2015 4:52 AM
To: Burleigh, Scott C (312B); [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

---

From: Amy Alford <[email-masked]>
Date: Fri, 16 Jan 2015 13:33:07 -0500

I think I didn't ask the question I meant to.  I want to know if there's a
use case for BAB passing unchanged through a non-security aware node and
then being accepted at the next hop.

6257 clearly assumed that there were security aware and non-security aware
nodes coexisting in a network and that security aware nodes might route
data between themselves through non-security aware nodes.  This seems
reasonable.  The implicit assumption seems to be that you might want to
require BAB between all the security aware nodes.  I don't see any reason
to assume that all nodes who happen to have BSP implementations also share
keys with each other.  My sense is that if you want to require some kind of
authentication in a heterogeneous network, you're going to use PIB
(possibly with a symmetric key based ciphersuite).

The use case I see for BAB is in a network where you control the whole
network and all nodes are security aware and share keys.
- Amy

On Thu, Jan 15, 2015 at 3:16 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  I think you might do this by configuring the gateways into the
> sub-network to require BABs on all bundles forwarded from nodes outside the
> sub-net but not on bundles forwarded from nodes inside the sub-net.  It
> would be hop-by-hop authentication, but only at the boundary and only on
> the outer surface of that boundary.
>
>
>
> Scott
>
>
>
> *Sent:* Thursday, January 15, 2015 11:27 AM
>

---

From: Eric Travis <[email-masked]>
Date: Fri, 16 Jan 2015 13:39:02 -0500

On Fri, Jan 16, 2015 at 7:32 AM, I-Viswanathan, Kapaleeswaran <
[email-masked]> wrote:

>
>  n  This statement implies that reactively-fragmented-fragment reassembly
> must be done at CL or CLA level. And that proactively-fragmented-fragment
> reassembly must be done at BPA level.
>
> §  If CL is UDP, then reassembly is at CLA. This means additional storage
> and time-out functionality must be implemented by UDP CLAs.
>
Not quite - TCP or UDP are service providers *to* the convergence layer.
TCP segmentation and reassembly is NOT the same as segmentation and
reassembly by the CL(A).

Segmentation by the CLA would be when the contents of a bundle is only
partially transferred during a contact period and resumed during the next
contact period between the peer CLAs.   Think something functionally
identical to an FTP resume.

The BPA would submit an atomic entity to the CLA for transfer to a peer
BPA.  The CLA would return an asynchronous indication with a status
(complete, in-progress, failed because..., ?) for each bundle submitted.

This abstraction makes for cleaner BPA operations - "reactive
fragmentation" becomes a function of
the CLA and proactive fragmentation can be restricted to the cases where
the peer BPA is unable to store a particular bundle.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 16 Jan 2015 19:03:43 +0000

Right, that’s more or less the question I was asking at the end of my last email – what’s the downside of not supporting that use case?

I think it’s entirely valid to assume the coexistence of security-aware and non-security-aware nodes in a network, and the sort of bounded-subnetwork scenario I was describing might be an example.  In that case, sure, a security-aware node that is wholly inside the network might not require BABs from its neighbors but it might authenticate a bundle payload sent by a node that’s outside the network by verifying its PIB.  That doesn’t require support for passing a BAB unchanged through a non-security-aware node, though.

Part of what bothers me about the A-B-C-D scenario where A and C are security-aware, B is not, and C uses the BAB attached by A to authenticate bundles forwarded by B is that it seems to re-introduce dependency on routing into security: what if B decides to route to D through E instead of through C?  If BABs are using symmetric keys (not a foregone conclusion, but it’s what has been implemented so far), how does A know which key to use in building its BAB?  Does it now have to go back to attaching BABs for all possible nodes that the bundle might get forwarded through on its way to D?  I think this goes a long way toward unraveling the simplification that we were aiming for with SBSP.  Can’t we please just Not Do It?

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Friday, January 16, 2015 10:33 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

I think I didn't ask the question I meant to.  I want to know if there's a use case for BAB passing unchanged through a non-security aware node and then being accepted at the next hop.

6257 clearly assumed that there were security aware and non-security aware nodes coexisting in a network and that security aware nodes might route data between themselves through non-security aware nodes.  This seems reasonable.  The implicit assumption seems to be that you might want to require BAB between all the security aware nodes.  I don't see any reason to assume that all nodes who happen to have BSP implementations also share keys with each other.  My sense is that if you want to require some kind of authentication in a heterogeneous network, you're going to use PIB (possibly with a symmetric key based ciphersuite).

The use case I see for BAB is in a network where you control the whole network and all nodes are security aware and share keys.
- Amy

On Thu, Jan 15, 2015 at 3:16 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
I think you might do this by configuring the gateways into the sub-network to require BABs on all bundles forwarded from nodes outside the sub-net but not on bundles forwarded from nodes inside the sub-net.  It would be hop-by-hop authentication, but only at the boundary and only on the outer surface of that boundary.

Scott

Scott

Scott

….

-Ed

---

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sat, 17 Jan 2015 14:32:26 +0000

Scott,

  I am sorry if I wasn't clear in my last e-mail. In Case 3 and Case 4 the bundle should fail to authenticate and the receiving security-aware node should have the option to drop the bundle. The statement in Section 2 "BABs operate between topologically adjacent nodes" should be clarified to something like:"BABs validate between topologically adjacent security-aware nodes" as it is ambiguous what it means for a BAB to "operate" anyway...

  If we allow non-security-aware nodes to discard BABs (i.e. sacrifice authentication), we lose the ability to detect issues in the bundle.

 Consider Case 3 again. Case 3 can occur when a BPA thinks at bundle creation time the next hop is to SN3 so it adds a BAB and then, later, at bundle transmission time, the topology has changed and the next hop is now to N2. In this situation true hop-by-hop authentication is now impossible, so we can either sacrifice authentication or sacrifice the bundle.

  If we sacrifice authentication:

  Let an attacker change the bundle between SN1 and N2. N2 removes the BAB. SN3 receives the bundle from N2. SN3 cannot have a policy of requiring BABs from N2 since N2 is not security aware, so SN3 does not reject the bundle, which is then processed by SN3. That might be bad.

  Sacrificing authentication prevents two important pieces of information from getting to SN3: (1) that the previous "security-aware" hop was SN1 and (2) that a BAB signature was ever in the bundle.  If SN3 had *either* piece of information it could detect a problem and reject the bundle.

  So is authentication a nit which artificially prevents bundles from flowing or is it a necessary first-line defense in a contested overlay?

  My intuition is that it depends on the network and is likely a function of the stability of the topology. Hence, the thought that allowing non-security-aware nodes to remove BABs should be a matter of policy and not mandated in the specification. A security best-practices document could explain the pros and cons of the various approaches.

-Ed

________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (312B) <[email-masked]>
Sent: Thursday, January 15, 2015 7:07 PM
To: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

Scott, Amy,

- Case 1: SN1 -> SN2

- Case 2: F_SN1 -> SN3

-Ed

---

Scott

Scott

….

-Ed

---

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sat, 17 Jan 2015 14:34:50 +0000

?I wanted to make the suggestion that, in the interest of being able to find this conversation later, the subject line be changed to something more descriptive such as "diagramming security interactions" or "questions about (S)BSP".

I know that the use of a single subject line to carry multiple threads makes it difficult for me to go back and recreate conversations.

-Ed

From: dtn <[email-masked]> on behalf of I-Viswanathan, Kapaleeswaran <[email-masked]>

Hi Amy

I have a query in the meantime. Let's say that DTN Node A wishes to send a bundle to DTN node B. For this to happen Nodes A and B must share the same HMAC key (message authentication key) associated with the hop (A, B) in their respective local key databases. How is this achieved? Is it pre-configured key or via a key management system?

Many thanks.

Best regards
Kapali

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sat, 17 Jan 2015 15:03:11 +0000

Node A could list itself as the security-source for the BAB it adds.  Then at either C or D, when processing the BAB, they know it came from A.

I think an important observation here is that at BAB creation time, A thinks the next hop is C because the routing system said so. Then, later, the routing system goes to B instead, precisely because there is little dependency between the routing and security functions.

I am in complete agreement that under no circumstances should A, when applying BABs, consider anything other than the next hop as told to it by the separate routing function.

So, if a non-security-aware node ever receives a bundle with a BAB it means some part of the secure network got confused or acted on stale information. In strict networks the proper reaction to confusion is to discard the bundle. In more permissive networks the proper reaction may be to proceed anyway.

Perhaps when building the BAB the recommendation should be:

 - If authentication is required, set the "delete bundle if block can't be processed" flag.

 - If authentication is suggested, set the "discard block if it can't be processed" flag.

Is that a workable alternative?

That also closes the "loophole" of validating a Bundle-with-BAB that snuck through a non-security-aware node unchanged. While bits don't change, it isn't clear to me that validating in such a circumstance doesn't give you an attack vector.

-Ed

________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (312B) <[email-masked]>
Sent: Friday, January 16, 2015 2:03 PM
To: Amy Alford
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

Scott

Scott

Scott

….

-Ed

---

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sat, 17 Jan 2015 15:09:06 +0000

Taking my own advice, I renamed the subject to note a new thread.

"Is there a need for ESB? Can it be dispensed with?"

SBSP drops the ESB and redefines PIB and PCB as applying to any block and re-names them BIB and BCB.

"A list of issues with RFC 6257 needs to be created so as to ensure that SBSP addresses all identified issues.

Here are the main issues accumulated through the writing of SBSP.

 http://www.ietf.org/proceedings/87/slides/slides-87-dtnrg-3.pdf

---

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

Sure, node A can list itself as the security-source for the BAB it adds, so nodes C and D know that the BAB came from A.  But suppose the digest of the BAB is created using a symmetric key and the key shared by A and C is different from the one shared by A and D.  Which key does A use to create the BAB?  If A uses the A/C key to compute the BAB hash and the bundle happens to go to node D, node D (which doesn't have the A/C key) cannot authenticate the bundle and must discard it.

If it's true that under no circumstances should A, when applying BABs, consider anything other than the next hop as told to it by the separate routing function, then how can it compute the digest in the BAB in such a way that it can be validated by the next security-aware node?  Is the routing function required to tell the BPA what the next security-aware node on the path will be?

Again, I don't see the value of trying to preserve this artifact.  It provides no advantage, and by introducing the possibility of fragmenting a bundle that has a BAB it necessarily and needlessly increases the complexity of the protocol specification.

Scott

From: Birrane, Edward J. [mailto:[email-masked]]
Sent: Saturday, January 17, 2015 7:03 AM
To: Burleigh, Scott C (312B); Amy Alford
Cc: [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

-Ed

From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>

Right, that's more or less the question I was asking at the end of my last email - what's the downside of not supporting that use case?

I think it's entirely valid to assume the coexistence of security-aware and non-security-aware nodes in a network, and the sort of bounded-subnetwork scenario I was describing might be an example.  In that case, sure, a security-aware node that is wholly inside the network might not require BABs from its neighbors but it might authenticate a bundle payload sent by a node that's outside the network by verifying its PIB.  That doesn't require support for passing a BAB unchanged through a non-security-aware node, though.

Part of what bothers me about the A-B-C-D scenario where A and C are security-aware, B is not, and C uses the BAB attached by A to authenticate bundles forwarded by B is that it seems to re-introduce dependency on routing into security: what if B decides to route to D through E instead of through C?  If BABs are using symmetric keys (not a foregone conclusion, but it's what has been implemented so far), how does A know which key to use in building its BAB?  Does it now have to go back to attaching BABs for all possible nodes that the bundle might get forwarded through on its way to D?  I think this goes a long way toward unraveling the simplification that we were aiming for with SBSP.  Can't we please just Not Do It?

Scott

Scott

On Thu, Jan 15, 2015 at 2:18 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
I wrote this looking only at the SBSP draft, which says in 3.3.1 "A BAB received in a bundle MUST be stripped before the bundle is forwarded."  I think this is perhaps a little ambiguous.  Strictly speaking, as written it applies only to security-aware nodes, but I thought the intent was that it ought to apply universally: section 2 says "BABs operate between topologically adjacent nodes", and that principle would be violated if security-aware node C received a bundle forwarded by non-security-aware node B with a BAB attached by security-aware node A.

We could easily preserve the principle by requiring that the "Discard block if it can't be processed" flag be set in all BABs.  The draft doesn't say this, though, so maybe I'm mistaken.

However, the fact that the draft doesn't require that bundles with BABs have the "do not fragment" flag set does make more sense if BABs are supposed to be stripped: the flag isn't needed, because at the time you'd be considering fragmentation the bundle would no longer have a BAB.  Then, once the fragmentation has happened (if it has happened), you can safely attach a BAB to each fragment.

"The decision to fragment a bundle MUST be made prior to adding authentication to the bundle.  The bundle MUST first be fragmented and authentication applied to each individual fragment."  (section 3.4)

On the other hand, you are right that the draft says "If a bundle with a BAB is fragmented by a non-security-aware node, then the entire bundle must be re-assembled before being processed to allow for the proper verification of the BAB."  On reflection, I think this is an inconsistency in the spec: we really never want that condition to arise, do we?  Everything becomes way simpler if we just require that the "Discard block if it can't be processed" flag be set in all BABs.

Scott

On Thu, Jan 15, 2015 at 11:36 AM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
I think one aspect of SBSP is especially relevant to this conversation.  SBSP removes "security destination" from the security block structure.  (The rationale for this is too lengthy to go into here but, for example, it eliminates the possibility of conflicting security destinations in different blocks mandating routes that make no sense.)  Instead, all security destinations are implicit.  The security destination of every block other than the BAB is the destination of the bundle.  The security destination of the BAB is always simply the node that receives the bundle, in any hop-by-hop transmission, and the security source of the BAB is always the node that sent the bundle over that hop.

Scott

....

-Ed

---

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 20 Jan 2015 09:06:36 +0000

Ed >>  Here are the main issues accumulated through the writing of SBSP.
http://www.ietf.org/proceedings/87/slides/slides-87-dtnrg-3.pdf

Kapali >> Do let me know if you agree with the following recommendation.

ABOUT: This mail is about the content in Slide 16 of 19

RECOMMENDATION:
Current specification in the slide is either MAC-then-ENCRYPT or ENCRYPT-and-MAC.  Change specification to: ENCRYPT-then-MAC.

DEFINE:

-        MAC-then-ENCRYPT := Encrypt(MAC(bundle))

-        ENCRYPT-then-MAC := MAC(Encrypt(bundle))

-        ENCRYPT-and-MAC := (Encrypt(bundle) AND MAC(bundle))

BACKGROUND:
The following paper suggests that ENCRYPT-then-MAC is a secure approach irrespective of the configuration of block cipher used to encrypt the message. MAC-then-ENCRYPT is secure if only if CBC mode is used for encryption. ENCRYPT-and-MAC is insecure and must be avoided.
https://cseweb.ucsd.edu/~mihir/papers/oem.pdf

The following paper talks about proper implementation (message encoding) with security in mind. I believe that the bundle security protocol may require a Type 1 CT (Cryptographic Transform) as explained in the paper - if the security for two bundles from the same source are essentially independent and a bundle can be sent once and received twice.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.62.4531&rep=rep1&type=pdf

A less formal explanation is available at the following URL.
http://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 20 Jan 2015 09:21:17 +0000

Ed>> "A list of issues with RFC 6257 needs to be created so as to ensure that SBSP addresses all identified issues.

Kapali >> Slide 3 of 19

RECOMMENDATION:
We need to think about two types of security association or session protocols for the bundle protocol suite.

PERSPECTIVE:
At least two types of key management protocols are required for establishing:

1.      hop-by-hop keys for BAB

a.      This is a (public-key based) session key establishment protocol  between two hops.

                                                    i.     A single key associated between two hops may be used to calculate BAB for multiple bundles that may flow from one hop to another.

b.      Examples are IKE and ISAKAMP

                                                    i.     http://en.wikipedia.org/wiki/Internet_Key_Exchange

                                                   ii.     http://en.wikipedia.org/wiki/Internet_Security_Association_and_Key_Management_Protocol

2.      end-to-end (public) keys for BIB and BCB

a.      Example is S/MIME

                                                    i.     http://en.wikipedia.org/wiki/SMIME

From: Birrane, Edward J. [mailto:[email-masked]]
Sent: Saturday, January 17, 2015 8:39 PM
To: I-Viswanathan, Kapaleeswaran; Burleigh, Scott C (312B); [email-masked]
Subject: RE: [dtn] SBSP Goals and Objectives

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 20 Jan 2015 09:58:33 +0000

Hi Eric:

Agreed!

Hi Amy, Ed, Eric, and Scott:

Would the following requirements specifications for CLA be agreeable to the conversations thus far? I believe that it allows reactive fragmentation and security to co-exist. The only discussion to have, though, is how much of a change is it to the current SBSP? After looking at Ed’s proposed changes in the following URL, it may not be much. But, what do you think?

Discussions thus far in no particular order:

>> Eric’s forwarded email.

Ed>>

<<Ed

Scott>>
<<Scott

CLA Requirements:

1.      BPA shall provide a bundle for transmission to CLA.

2.      CLA may transmit the bundle with or without reactive-fragmentation to its peer CLA

3.      the CLA shall receive bundles with or without reactive-defragmentation from its peer CLA

4.      CLA shall add BAB to bundles received from its BPA

5.      if BAB is present, CLA must verify validity of BAB in a received bundle from its peer CLA after reactive-defragmentation, if reactive-defragmentation is needed.

6.      CLA shall only pass (upward) reactively-defragmented bundles to its BPA, if and only if the bundles were reactively-fragmented by its peer CLA

a.      This means that CLA must have local storage for partially received bundles

------------------                                                                              -------------------------
          BPA             <--BIB, BCB, end-to-end security assc-->           Peer BPA                    <-----Proactive Fragmentation
------------------                                                                              -------------------------
          CLA             <----BAB, hop security association------->         Peer CLA                    <-----Reactive Fragmentation and routing
               ------------------                                                                              -------------------------
          CL                <-----Datagram size, time-out, etc------>              CL
               ------------------                                                                              --------------------------

Amy required that a bundle (with a BAB) may go through an insecure DTN node, if one exists between two DTN nodes, and must not verify the BAB but only forward the same to another secure DTN node, to which it is connected.
               -----------                                                                                         -------------------
                   BPA       <--BIB, BCB, end-to-end security association-->         Peer BPA
               -----------                             ----------------                                    -------------------
                   CLA                                  Insecure CLA                                             Peer CLA
               -----------                             ------------------                                 --------------------
                     CL                                              CL                                                         CL
               -----------                             ------------------                                 ---------------------

The insecure CLA is a special DTN router configuration with the following requirements

1.      It shall receive bundles from CLA without verifying the validity of the BAB in the bundle

2.      It shall forward the received bundle along with the received BAB and without adding its own BAB

What do you think?

Best regards
Kapali

From: Eric Travis [mailto:[email-masked]]
Sent: Saturday, January 17, 2015 12:09 AM
To: I-Viswanathan, Kapaleeswaran
Cc: Birrane, Edward J.; Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

On Fri, Jan 16, 2015 at 7:32 AM, I-Viswanathan, Kapaleeswaran <[email-masked]<mailto:[email-masked]>> wrote:

•  This statement implies that reactively-fragmented-fragment reassembly must be done at CL or CLA level. And that proactively-fragmented-fragment reassembly must be done at BPA level.

•  If CL is TCP, then reassembly is by TCP. Nothing more to specify.

•  If CL is UDP, then reassembly is at CLA. This means additional storage and time-out functionality must be implemented by UDP CLAs.
Not quite - TCP or UDP are service providers *to* the convergence layer. TCP segmentation and reassembly is NOT the same as segmentation and reassembly by the CL(A).

Segmentation by the CLA would be when the contents of a bundle is only partially transferred during a contact period and resumed during the next contact period between the peer CLAs.   Think something functionally identical to an FTP resume.
The BPA would submit an atomic entity to the CLA for transfer to a peer BPA.  The CLA would return an asynchronous indication with a status (complete, in-progress, failed because..., ?) for each bundle submitted.
This abstraction makes for cleaner BPA operations - "reactive fragmentation" becomes a function of
the CLA and proactive fragmentation can be restricted to the cases where the peer BPA is unable to store a particular bundle.

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 20 Jan 2015 10:11:04 +0000

Hi:

Chuck >> The only way this really works is with pre shared keys.

Kapali >> If we have something like IKE and ISAKAMP, we can make it worked with a proper key management. I believe that the crux will be to have a public key assigned to every node, and a root public key as the only pre-shared key in a given DTN network.

Chuck>> What happens when a node out of sync with keys or it must be power cycled what is you out of band mechanism to reload/update the keys?

Kapali>>If a (session) key in a node is out of sync, then this can be detected when a new key index is received and remedied by running a single-pass or two pass key establishment protocol between two hops (or nodes).  I will try to detail these in the coming weeks for us.

Chuck >> So how does this trust chain work and how will these networks be managed? I do not foresee sharing of these networks.

When the bundle protocols is hooked onto a key management infrastructure and the key management infrastructure is hooked onto a public key infrastructure, this can be solved.

Kapali >> This is precisely the way IPSec (or IPv6) solved the  problem. The protocols are IKE, ISAKAMP, and Oakley. The general idea is that a long-term, non-changing root-public key(s) must be the only (set of) keys(s) that shall be pre-shared in the network. Ephemeral or session keys must not be pre-shared.

We may need to borrow protocols from other areas when the protocols do not require reliable communications or connections, which is the case with IPSec and IPv6. The only aspects of the protocol that need to be analyzed is the delay toleration of such protocols. In other words, can these protocol properties hold when time-outs are very long (possibly in days)?  This is something that we may wish to analyze and factor in.

Since cryptography protocols are event driven in general, we may be able to find established protocols and repurpose the same for DTN security.

Best regards

Kapali

-----Original Message-----
From: Sheehe, Charles J. (GRC-LCA0) [mailto:[email-masked]]
Sent: Friday, January 16, 2015 7:26 PM
To: I-Viswanathan, Kapaleeswaran; Amy Alford
Cc: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi

My opinion

Chuck

Charles J. Sheehe III

Electronics Engineer

21000 Brookpark Rd

Cleveland, OH 44135

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

Office: 216-433-5179

-----Original Message-----

To: Amy Alford

Cc: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; [email-masked]<mailto:[email-masked]>

Hi Amy

Many thanks.

Best regards

Kapali

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Tue, 20 Jan 2015 14:10:15 +0000

Hi

The issue I see is the topology of the network is not defined.
That is fine but, with large delay time between nodes, the management of the network as it get built out becomes ever more difficult.
Onion map like topology if used, then the boundary nodes would be assigned with sufficient resources to manage the nodes visible. Security management can be maintained due to the layered approach. 

A large ad hoc/opportunistic network with large delay times between nodes, I do not know how it can be managed centrally and secure the network.

Memory in space gets corrupted. Hardened memory in space is expensive.  "IKE, ISAKAMP, and Oakley. The general idea is that a long-term, non-changing root-public key(s) must be the only (set of) keys(s) that shall be pre-shared in the network." So when launched into space where would these core keys reside? The only trusted area that I know of would be in she secure boot, else it will may be over written.

Or we need to develop a bridge between  the large mobile ad hoc, rapidly changing world and the small networks, predictable contacts with slow to evolve tech. 

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of I-Viswanathan, Kapaleeswaran
Sent: Tuesday, January 20, 2015 5:11 AM
To: Birrane, Edward J.; Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; [email-masked]
Subject: Re: [dtn] SBSP Goals and Objectives

Hi:

Best regards

Kapali 

-----Original Message-----
From: Sheehe, Charles J. (GRC-LCA0) [mailto:[email-masked]] 
Sent: Friday, January 16, 2015 7:26 PM
To: I-Viswanathan, Kapaleeswaran; Amy Alford
Cc: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Hi

My opinion

Chuck

 

Charles J. Sheehe III

Electronics Engineer

21000 Brookpark Rd

Cleveland, OH 44135

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

Office: 216-433-5179

-----Original Message-----

From: dtn [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of I-Viswanathan, Kapaleeswaran

To: Amy Alford

Cc: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; [email-masked] <mailto:[email-masked]> 

Hi Amy 

 

 

Many thanks. 

Best regards

Kapali  

Cc: Burleigh, Scott C (312B); [email-masked] <mailto:[email-masked]> 

 

 

 

 

 

 http://www.ietf.org/proceedings/87/slides/slides-87-dtnrg-3.pdf <http://www.ietf.org/proceedings/87/slides/slides-87-dtnrg-3.pdf>

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 20 Jan 2015 15:35:36 +0000

Scott,

  I completely agree that the BAB is meant to only validate between two security-aware, topologically adjacent BPAs in a network.  As a matter of policy, we should use BAB block processing flags to handle these strange cases.  If we do that, there is no remaining issue of what happens when a security-aware node receives a BAB routed through a non-security-aware node - based on the block flags that simply will not happen.

  So, I propose the following:

1.       A minor change to the wording of SBSP saying that BABs *validate* (not operate) between security-aware, topologically-adjacent nodes.

2.       In the specification, when creating a BAB, BPAs MUST set *either* the "discard block if cannot process" or the "discard bundle is cannot process" flag, but not both.

3.       Some text be added to the BAB explaining the impact of setting one flag or the other. The impact is how policy chooses to react to a failure to authenticate a bundle as defined in change #1 above.

  This is, IMO, particularly beneficial because it closes a bothersome loopwhole where SN1 signs a hash using the key for SN3, adds itself as the BAB security source, routes through N2 by accident, and N2 does not modify the bundle in any way.  As the spec currently stands, SN3 could still validate the bundle. As improbable a series of events as that is, it is nice to close off that possibility.

-Ed

---

From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: Saturday, January 17, 2015 11:08 AM
To: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

-Ed

Scott

Scott

Scott

Scott

....

-Ed

---

---

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

Perfect.  I think this closes off several of the most troublesome unintended effects of the BSP spec, in a simple and unambiguous way.

Scott

From: Birrane, Edward J. [mailto:[email-masked]]
Sent: Tuesday, January 20, 2015 7:36 AM
To: Burleigh, Scott C (312B); [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott,

-Ed

---

Scott

-Ed

Scott

Scott

Scott

Scott

....

-Ed

---

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Tue, 20 Jan 2015 17:53:33 +0000

I agree that this is the better option.

ENCRYPT-then-MAC := MAC(Encrypt(bundle))

Chuck

Charles J. Sheehe III
Electronics Engineer

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of I-Viswanathan, Kapaleeswaran
Sent: Tuesday, January 20, 2015 4:07 AM
To: Birrane, Edward J.; Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]; [email-masked]
Subject: Re: [dtn] SBSP Goals and Objectives

RECOMMENDATION:

DEFINE: 

BACKGROUND:

---

From: Amy Alford <[email-masked]>
Date: Tue, 20 Jan 2015 13:21:34 -0500

Pushing reactive fragmentation down to the CLA doesn't require making the
CLA responsible for BAB.

Conceptually, a CLA is responsible for moving a blob of data (the bundle)
from one BPA to another, via some completely unspecified means.  They are
already free to support reactive fragmentation as long as they reassemble
the data before passing it off to the BPA.

I am wondering about implementation.  When a link goes down
mid-transmission, the CLA will need to decide whether to report failure or
wait for the link to reappear and continue transmission.  In practice, the
CLA will probably need to use routing information to make that decision.
That's ok, but it's slightly more complex than the current reactive
fragmentation implementation.
- Amy

On Tue, Jan 20, 2015 at 4:58 AM, I-Viswanathan, Kapaleeswaran <
[email-masked]> wrote:

> Would the following requirements specifications for CLA be agreeable to
> the conversations thus far? I believe that it allows reactive fragmentation
> and security to co-exist. The only discussion to have, though, is how much
> of a change is it to the current SBSP? After looking at Ed’s proposed
> changes in the following URL, it may not be much. But, what do you think?
>
>
>
> *Discussions thus far in no particular order:*
>
>
>
> >> Eric’s forwarded email.
>
>
>
> Ed>>
>
> *CLA Requirements: *
> 3.      the CLA shall receive bundles with or without
> reactive-defragmentation from its peer CLA
>
> 5.      if BAB is present, CLA must verify validity of BAB in a received
> bundle from its peer CLA after reactive-defragmentation, if
> reactive-defragmentation is needed.
>
> 6.      CLA shall only pass (upward) reactively-defragmented bundles to
> its BPA, if and only if the bundles were reactively-fragmented by its peer
> CLA
>
>           CLA             <----BAB, hop security
> association------->         Peer CLA                    <-----Reactive
> Fragmentation and routing
>
>
> ------------------
> Amy required that a bundle (with a BAB) may go through an insecure DTN
> node, if one exists between two DTN nodes, and must not verify the BAB but
> only forward the same to another secure DTN node, to which it is connected.
>
>                -----------
>                                              -------------------
>
>                    CLA                                  Insecure
> CLA                                             Peer CLA
>                      CL
> CL                                                         CL
>                -----------
> ------------------
> ---------------------
> *Sent:* Saturday, January 17, 2015 12:09 AM
> *Cc:* Birrane, Edward J.; Burleigh, Scott C (312B); [email-masked]

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 20 Jan 2015 23:19:08 +0000

Strictly speaking, I would say that you’re not doing reactive fragmentation if you don’t end up with two bundles conforming to section 5.8 of RFC 5050.  It is certainly not impossible for a CLA to do that (a CLA can do whatever it likes, even if that includes replicating a chunk of the functionality of a BPA), but I suspect that most CLA implementations do not.  In that sense, I would think that CLAs should normally never do reactive fragmentation and would normally have no need for routing information.

I expect most CLA implementations do segmentation/reassembly of the bundle as an unstructured blob, nominally the payload of a convergence-layer protocol data unit.  In the case of a link going down mid-transmission, I would think that one reasonable strategy would be to wait some length of time for the link to reappear, then resume transmission if it does and report failure if it doesn’t.  But again, a CLA implementation can certainly do whatever it likes.

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Tuesday, January 20, 2015 10:22 AM
To: I-Viswanathan, Kapaleeswaran
Cc: Eric Travis; Burleigh, Scott C (312B); [email-masked]; Birrane, Edward J.
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Pushing reactive fragmentation down to the CLA doesn't require making the CLA responsible for BAB.

Conceptually, a CLA is responsible for moving a blob of data (the bundle) from one BPA to another, via some completely unspecified means.  They are already free to support reactive fragmentation as long as they reassemble the data before passing it off to the BPA.

I am wondering about implementation.  When a link goes down mid-transmission, the CLA will need to decide whether to report failure or wait for the link to reappear and continue transmission.  In practice, the CLA will probably need to use routing information to make that decision.  That's ok, but it's slightly more complex than the current reactive fragmentation implementation.
- Amy

On Tue, Jan 20, 2015 at 4:58 AM, I-Viswanathan, Kapaleeswaran <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric:

Agreed!

Ed>>

Scott>>

CLA Requirements:

What do you think?

Best regards
Kapali

Cc: Birrane, Edward J.; Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 21 Jan 2015 06:25:04 +0000

Objective of BAB: To prevent unauthorized insertion of bundles into a DTN network so as to prevent Denial of Service attacks on highly constrained communication links.

Ed’s proposed change of CLA in order to support reactive fragmentation: CLA may fragment bundles reactively

Scenarios to be dealt with in field:

1.      Multiple fragments of DTN bundles may be received

2.      The time duration between the receipt of various fragments of DTN bundles may be arbitrarily long

3.      Until all fragments of a given DTN bundle are received, CLA will have to allocate storage for received fragments of bundles

a.      This requirement is needed to take your (Amy’s) following statement into account: When a link goes down mid-transmission, the CLA will need to decide whether to report failure or wait for the link to reappear and continue transmission.

Denial of Service attack on CLA: Send many fragments of DTN bundles to CLA by spoofing sending address of honest DTN nodes.

Possible prevention mechanisms:

1.      Black-list sending addresses that send lot of bundle fragments that never get defragmented

a.      This solution assumes that sending addresses cannot be spoofed

b.      Thus, this solution is not applicable for TCP or UDP

c.      It may be applicable for LTP but we shall be pushing security assumptions down the network stack, which is generally considered a risky strategy

2.      Allocating storage for bundle fragments only after validating BAB and black-listing addresses that send lot of bundle fragments that never get defragmented

a.      This solution can work for TCP and UDP as well.

b.      The residual denial of service risk will be an attack that can attempt overload the BAB verification mechanism of CLA by sending bundle fragments with bad BABs and spoofed addresses.

                                                    i.     This residual attack is a lesser evil than allocating potentially long-term storage for unauthenticated entities and can be tackled by having dedicated processing facilities for CLA’s BAB authentication.

c.      Now blacklisting will be at the level of a shared-key index instead of at the level of a network address, which is not under the control of either the sender or the receiver.

Concluding comments:
The second solution (moving BAB verification to CLA) appears to provide reduced DoS risk, which is an objective of BAB. Thus, the suggestion for moving BAB verification to CLA.

From a implementation complexity point of view, the changes proposed by Ed and Scott (Slide 7, http://www.ietf.org/proceedings/87/slides/slides-87-dtnrg-3.pdf) for Bundle-in-Bundle encapsulation can be exploited to ensure that the implementation complexity can be either reduced or controlled.

Sent: Tuesday, January 20, 2015 11:52 PM

Agreed!

Ed>>

Scott>>

CLA Requirements:

What do you think?

Best regards
Kapali

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 21 Jan 2015 16:20:18 +0000

I definitely agree that BAB validation – which applies to bundles that are fragments as well as to non-fragmented bundles – will effectively mitigate DOS attacks based on bundle fragmentation.  However, I don’t think it is necessary or desirable to push BAB validation down to the convergence layer for this purpose.

Bundle reassembly from fragments is performed by the bundle protocol agent, not the CLA, so that is the layer at which storage must be allocated to received bundle fragments pending reassembly.  The current design of BP, which performs security functions (including BAB validation) within the BPA, safely and efficiently aligns the solution with the problem.

A node may include any number of CLAs, not all of which will necessarily be implemented to the same high standard.  Validating BABs in the BPA excludes the possibility of a poorly implemented CLA constituting a security weakness that threatens the operation of the entire node.

The convergence layer is a great place to do segmentation/reassembly based on per-hop MTU size, and it’s a great place to do acknowledgment/retransmission constrained by environment-specific round-trip-time calculations; in short, I think it’s the right place to perform functions that are best done in different ways on different hops of the end-to-end path due to differences in medium and environment.  But I think common functions that are environment-neutral and may be performed at every node in the same way, such as authentication, are best performed in the BPA.

Scott

From: I-Viswanathan, Kapaleeswaran [mailto:[email-masked]]
Sent: Tuesday, January 20, 2015 10:25 PM
To: Amy Alford
Cc: Eric Travis; Burleigh, Scott C (312B); [email-masked]; Birrane, Edward J.
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Concluding comments:

Cc: Eric Travis; Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>; Birrane, Edward J.

Agreed!

Ed>>

Scott>>

CLA Requirements:

What do you think?

Best regards
Kapali

---

From: Amy Alford <[email-masked]>
Date: Wed, 21 Jan 2015 12:21:56 -0500

Ok, I think I misunderstood something.  If reactive fragmentation is pushed
down to the CLA level, then who reassembles the fragments?  I assumed the
receiving CLA.  So, fragmentation based DOS's are possible at the CLA
level, and the CLA would need to accept or mitigate that.  But, BPA to BPA
BAB works cleanly.

The other option is the BPA reassembles.  In that case, BPA to BPA BAB
isn't going to work.  However, the BPA can be responsible for dealing with
reassembly related DOS attacks.

On Wed, Jan 21, 2015 at 11:20 AM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  I definitely agree that BAB validation – which applies to bundles that
> are fragments as well as to non-fragmented bundles – will effectively
> mitigate DOS attacks based on bundle fragmentation.  However, I don’t think
> it is necessary or desirable to push BAB validation down to the convergence
> layer for this purpose.
>
>
>
> Bundle reassembly from fragments is performed by the bundle protocol
> agent, not the CLA, so that is the layer at which storage must be allocated
> to received bundle fragments pending reassembly.  The current design of BP,
> which performs security functions (including BAB validation) within the
> BPA, safely and efficiently aligns the solution with the problem.
>
>
>
> A node may include any number of CLAs, not all of which will necessarily
> be implemented to the same high standard.  Validating BABs in the BPA
> excludes the possibility of a poorly implemented CLA constituting a
> security weakness that threatens the operation of the entire node.
>
>
>
> The convergence layer is a great place to do segmentation/reassembly based
> on per-hop MTU size, and it’s a great place to do
> acknowledgment/retransmission constrained by environment-specific
> round-trip-time calculations; in short, I think it’s the right place to
> perform functions that are best done in different ways on different hops of
> the end-to-end path due to differences in medium and environment.  But I
> think common functions that are environment-neutral and may be performed at
> every node in the same way, such as authentication, are best performed in
> the BPA.
>
>
>
> Scott
>
>
>
> *From:* I-Viswanathan, Kapaleeswaran [mailto:
> [email-masked]]
> *Sent:* Tuesday, January 20, 2015 10:25 PM
> *To:* Amy Alford
> *Cc:* Eric Travis; Burleigh, Scott C (312B); [email-masked]; Birrane,
> Edward J.
> *Objective of BAB:* To prevent unauthorized insertion of bundles into a
> DTN network so as to prevent Denial of Service attacks on highly
> constrained communication links.
>
>
>
> *Ed’s proposed change of CLA in order to support reactive fragmentation: *CLA
> may fragment bundles reactively
>
>
>
> *Scenarios to be dealt with in field: *
>
> 3.       Until all fragments of a given DTN bundle are received, CLA will
> have to allocate storage for received fragments of bundles
>
> a.       This requirement is needed to take your (Amy’s) following
> statement into account: When a link goes down mid-transmission, the CLA
> will need to decide whether to report failure or wait for the link to
> reappear and continue transmission.
>
>
>
> *Denial of Service attack on CLA: *Send many fragments of DTN bundles to
> CLA by spoofing sending address of honest DTN nodes.
>
>
>
> *Possible prevention mechanisms:*
>
> c.       It may be applicable for LTP but we shall be pushing security
> assumptions down the network stack, which is generally considered a risky
> strategy
>
> 2.       Allocating storage for bundle fragments only after validating
> BAB and black-listing addresses that send lot of bundle fragments that
> never get defragmented
>
> b.      The residual denial of service risk will be an attack that can
> attempt overload the BAB verification mechanism of CLA by sending bundle
> fragments with bad BABs and spoofed addresses.
>
>                                                                i.      This
> residual attack is a lesser evil than allocating potentially long-term
> storage for unauthenticated entities and can be tackled by having dedicated
> processing facilities for CLA’s BAB authentication.
>
> c.       Now blacklisting will be at the level of a shared-key index
> instead of at the level of a network address, which is not under the
> control of either the sender or the receiver.
>
>
>
> *Concluding comments:*
>
> The second solution (moving BAB verification to CLA) appears to provide
> reduced DoS risk, which is an objective of BAB. Thus, the suggestion for
> moving BAB verification to CLA.
>
>
>
> From a implementation complexity point of view, the changes proposed by Ed
> and Scott (Slide 7,
> http://www.ietf.org/proceedings/87/slides/slides-87-dtnrg-3.pdf) for
> Bundle-in-Bundle encapsulation can be exploited to ensure that the
> implementation complexity can be either reduced or controlled.
>
>
>
>
>
>
>
> *Sent:* Tuesday, January 20, 2015 11:52 PM
> *Cc:* Eric Travis; Burleigh, Scott C (312B); [email-masked]; Birrane,
> Edward J.
> -------------------------
>
> -------------------------
>
> -------------------------
>
> --------------------------
>
>
>
>                                              -------------------
> ----------------                                    -------------------
>
>                    CLA                                  Insecure
> CLA                                             Peer CLA
>
>                -----------
> ------------------                                 --------------------
>
>                      CL
> CL                                                         CL
>
>                -----------
> ------------------
> ---------------------
>
>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 21 Jan 2015 17:53:37 +0000

I would say the latter option has always made more sense.  BAB validation between BPAs was (and is) always going to work except in the case of reactive fragmentation, which is how this thread got started.

Pushing “reactive fragmentation” down to the CLA doesn’t make it work any better, if indeed it is true reactive fragmentation – that is, you start with one bundle and end up with two smaller bundles – rather than just the ordinary segmentation/reassembly of unstructured blobs that CLAs have always done.  The problem is that the fragmentary bundle that was received can’t be authenticated, because no BAB was attached to it.

That will always be true, no matter where the reactive fragmentation is performed: by definition, the sender (whether at BP level or CL level) cannot have attached a BAB to the received fragmentary bundle, because it didn’t know what portion of the payload to compute the hash over.  (If it knew that, then it had enough information to perform just-in-time proactive fragmentation instead.)

So reactive fragmentation is always, by definition, incompatible with bundle authentication.  Therefore reactive fragmentation always exposes the network to DOS attacks via the receiving node.

So let’s not do reactive fragmentation.  Let’s instead always enable the BPA to invoke BAB validation to defeat DOS attacks.

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Wednesday, January 21, 2015 9:22 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Ok, I think I misunderstood something.  If reactive fragmentation is pushed down to the CLA level, then who reassembles the fragments?  I assumed the receiving CLA.  So, fragmentation based DOS's are possible at the CLA level, and the CLA would need to accept or mitigate that.  But, BPA to BPA BAB works cleanly.

The other option is the BPA reassembles.  In that case, BPA to BPA BAB isn't going to work.  However, the BPA can be responsible for dealing with reassembly related DOS attacks.

On Wed, Jan 21, 2015 at 11:20 AM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
I definitely agree that BAB validation – which applies to bundles that are fragments as well as to non-fragmented bundles – will effectively mitigate DOS attacks based on bundle fragmentation.  However, I don’t think it is necessary or desirable to push BAB validation down to the convergence layer for this purpose.

Scott

From: I-Viswanathan, Kapaleeswaran [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, January 20, 2015 10:25 PM
To: Amy Alford
Cc: Eric Travis; Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>; Birrane, Edward J.
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Concluding comments:

Agreed!

Ed>>

Scott>>

CLA Requirements:

What do you think?

Best regards
Kapali

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Thu, 22 Jan 2015 05:37:01 +0000

The following thoughts occurred to me.

1.      Large bundles will be (reactively) fragmented without authentication by the lower layers, if the bundle were large for transmission over a particular network.

a.      https://tools.ietf.org/html/rfc7122#section-3.1 : “The Bundle Protocol specification provides a bundle fragmentation concept [RFC5050] that allows a large bundle to be divided into bundle fragments.  If the Bundle Protocol is being encapsulated in DCCP or UDP, it therefore SHOULD create each fragment of sufficiently small size that it can then be encapsulated into a datagram that will not need to be fragmented at the IP layer.”

2.      So, either the BPA or the CLA needs to create bundles of appropriate size so that fragmentation of bundles will not happen with a high probability.

a.      If a bundle were reactively fragmented, then the bundle will be put together only by the lower communication layer (such as IP), whos peer fragmented the datagram on the first hand. This will be outside the control of CLA as well, if the bundle were to be too large.

3.      This means that even when BAB is present at the BPA layer, Denial of Service can happen at the lower layers, if the size of the bundle were to be too large, and therefore on the DTN network.

a.      The presence of BAB does not mitigate DoS on the DTN but only on the BPA layer. It cannot mitigate DoS on CLA or lower layers especially when the CL experiences long delays and disruptions. The BPA layer can assist in the mitigation of DoS on CLA or lower layers by specifying a maximum bundle size.

Therefore, we have the possible ways forward.

1.      Accept the residual risk on the network due to processing of BAB at the BPA layer.

a.      Provide DoS mitigation support for lower layers by specifying a maximum size of a bundle that any BPA shall generate.

2.      Allow CLA to determine the best size of datagram to be transmitted without fragmentation in between and to compute and verify BAB.

From: Burleigh, Scott C (312B) [mailto:[email-masked]]
Sent: Wednesday, January 21, 2015 11:24 PM
To: Amy Alford
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

Scott

Concluding comments:

Agreed!

Ed>>

Scott>>

CLA Requirements:

What do you think?

Best regards
Kapali

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 22 Jan 2015 13:19:16 +0000

In Line

From: <I-Viswanathan>, Kapaleeswaran <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 22, 2015 12:37 AM
To: "Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]" <[email-masked]<mailto:[email-masked]>>, Amy Alford <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Take five 1 Gbyte bundles coming into a data mule, each from different sources to different destinations.   The data mule will not contact the main forwarding node for 2 weeks.  Each of these 1 Gbyte bundles have been transmitted over convergence layers using a NACK oriented protocol via UDP.  The statement says to fragment sufficiently small size that it can be encapsulate into a datagram that will not have to be fragmented at the IP layer.  Think about how many bundles you have sitting in a  system memory that now have to be managed.

IMHO, authenticating the header separate of the payload allows for much less processing and may enable reactive fragmentation if you make the assumption that if you trust the header, you trust the payload.  I don't think that is a bad assumption.  I could be wrong.

IMHO, if you want to operate in an opportunistic environment with large bundles, you will need reactive fragmentation.

On the other hand, I believe some ICN implementations are chunking information sets (analogous to large bundles) up at the MTU size.  So, that has to be managed in storage, but, I don't believe  there is a lifetime associated with ICN chunks. So that simplifies management.  There is also sequencing to get out of order chunks back  together at the destination.

Will

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 22 Jan 2015 16:54:31 +0000

I certainly agree that authentication of bundles will not defend against a DOS attack that is a deluge of IP datagrams.  If you want to defend against that kind of attack, then you need a defense mechanism that deals with IP datagrams.  In a DTN deployment, that would be an IP DOS defense operating at the convergence layer, which might be a very good thing.

But if your defense against DOS attacks is going to be authentication of bundles (not authentication of datagrams), then this can only be done upon the reception of each entire bundle, and it has to be done at a layer of the protocol stack which understands the structure of bundles.  That is the bundle layer, not the convergence layer.

Doing BAB authentication in the BPA is certainly no riskier than doing it in a CLA would be.  No matter where you do it, you can’t do it until the entire bundle has been received – and as soon as the bundle has been received you can do BAB authentication in the BPA immediately.  There is no additional delay and no added risk.

It is true that finer-grained bundle transmission – fragmentation – enables authentication to be performed sooner (and more often), because completing the reception of a small bundle can happen more quickly than completing the reception of a large bundle.  This enables the resources occupied by inauthentic bundles to be reclaimed more quickly, potentially reducing the impact of a DOS attack on the node.

But of course someone who is mounting a DOS attack against you is not going to cooperate by limiting the attack bundles to a size that you find convenient.  CLA-directed bundle fragmentation is not a mechanism for mitigating DOS attacks.

Sure, we could set a maximum size for valid bundles, so that incoming bundles that pose a DOS threat could be discarded because they are too large rather than discarded because they are inauthentic.  That would save a bit of validation processing, at the cost of universally increasing transmission overhead and fragmentation/reassembly processing, regardless of the likelihood of DOS attacks.  But it’s not necessary.  If an incoming bundle is too large to fit into available reception buffer space, then it has to be discarded anyway.  If not, then as soon as it has been received and has failed authentication it is discarded immediately.  In neither case does a large attack  bundle pose much more of a threat than a small one.

[One further note: the fragmentation discussed in RFC 7122 (cited below) is proactive, not reactive, fragmentation.  “Reactive fragmentation” is what the receiver of a portion of a bundle does when connectivity to the sender is abruptly terminated, transforming the received partial bundle into a well-formed fragmentary bundle.  Proactive fragmentation to accommodate path MTU size is different.]

Scott

From: I-Viswanathan, Kapaleeswaran [mailto:[email-masked]]
Sent: Wednesday, January 21, 2015 9:37 PM
To: Burleigh, Scott C (312B); Amy Alford
Cc: [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

Scott

Concluding comments:

Agreed!

Ed>>

Scott>>

CLA Requirements:

What do you think?

Best regards
Kapali

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2015 17:21:46 +0000

Hi Scott,

Thanks for the reminder that DTN security is very much a multi-layered security scenario. Along
with bundle security, lower layers are expected to employ IP layer security and/or link-layer
security in environments where IP and link-layer security threats are present (e.g., on
unsecured links).

Thanks – Fred
[email-masked]

From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: Thursday, January 22, 2015 8:55 AM
To: I-Viswanathan, Kapaleeswaran; Amy Alford
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott

Scott

Scott

Concluding comments:

Agreed!

Ed>>

Scott>>

CLA Requirements:

What do you think?

Best regards
Kapali