Subject: [dtn] Erik Kline's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 02 Dec 2020 17:35:58 -0800

Erik Kline has entered the following ballot position for
draft-ietf-dtn-bpbis-29: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I was going to ballot as Discuss, but I lack some context on the history
of this document and its evolution.  Nevertheless, hopefully the "discuss"
points below leave a record of things about which I had some concern.

[[ discuss ]]

[ section 4.1.5.1.2 ]

* The encoding considerations mentions "dtn" scheme but this is the "ipn"
  scheme section so...should this be "ipn"?

[ section 5.2 ]

* Should step 2 be step 1 of 5.3 (not 5.4)?

[ section 5.4.2 ]

* It seems to me that the behaviour in step 1, which I think does make some
  sense, pretty easily sets up the potential for ping-ponging (AIUI).

  If true, should there be some text (perhaps in 5.4) acknowledging that
  forwarding a given bundle to a node for the 2nd time might warrant, at least,
  some reassessment of the routing/reachability state in the node?

  I fully understand that extensive routing discussion is out of scope
  for this document.

[ section 5.6 ]

* Does "cannot process" include "does not understand"?

  If so it might be good to use a different reason value from
  "Block unintelligible" so that some other node can understand that, for
  example, the CRC (if sent) was valid.

  Basically, consider differentiating between "understood but malformed" and
  "not understood".

[ section 5.9 ]

* The mention of non-overlapping fragments brings a few issues to mind that
  have been encountered in IPv6 when considering fragment handling:

    [1] How are overlapping fragments to be handled?  Are they ignored
    and/or cause any specific error to be generated? (vis. IPv6: RFC 5722)

    [2] What about "atomic fragments", i.e. a fragment that starts at
    offset zero and has a total payload length equal to the actual length
    of the payload (i.e. a fragmented payload consisting of a single fragment)?
    (vis. IPv6: RFC 6949)

    I'm guessing these should be silently accepted, but there might be some
    text saying they MUST/SHOULD NOT be generated.

[[ comments ]]

[ section 4.2.2 ]

* The Creation Timestamp element description seems to copy a bunch of text
  from 4.1.7.  Might be able to shorten the document a bit by referring to
  4.1.7 for extended discussion of creation timestamp operations.

[[ questions ]]

[ section 4.3.3 ]

* What's the value of using a {limit, incrementing_value} pair like this over
  just a single decrements_to_zero integer?  I'm not suggesting this be
  changed (it's probably too late anyway), but I was just curious as to the
  motivation.

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 4 Dec 2020 21:48:12 +0000

Hi, Erik.  Some thoughts on your comments, in-line below.

Scott

-----Original Message-----
From: Erik Kline via Datatracker <[email-masked]> 
Sent: Wednesday, December 2, 2020 5:36 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Fred Templin <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Erik Kline's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)

[[ discuss ]]

[ section 4.1.5.1.2 ]

>	Excellent catch.  Thank you.

[ section 5.2 ]

>	No, in the case of a locally sourced node we definitely DO NOT want to exclude the possibility of the node forwarding the bundle to itself (BP loopback).  The procedure described in 5.3 applies only to a bundle that has been forwarded by some node and has been received at the local node; the only entry into the procedure in 5.3 is from Step 5 of 5.6 (Bundle Reception).
>	It could well be argued that the content of 5.3 should simply be inserted at the end of 5.6.  The current organization was retained from RFC5050, for continuity, but I would be fine with making that change. 

[ section 5.4.2 ]

>	The question, I think, is how worried we are about ping-ponging.  If the node that is performing 5.4.2 decides to send the bundle back to the Previous Node, and that node then decides to reforward it again in the same way (based on its current information about the network topology), it's possible that the second forwarding attempt at this node will succeed because of changes in configuration or connectivity.
>	Obviously we can't tolerate infinite ping-ponging, but bundle lifetime and/or Hop Count limit will defend against that, even if routing implementations are simple-minded.  We've thought about this quite a bit, and I'd like to leave this text as is.

[ section 5.6 ]

>	I agree.  I would propose to add a new "Block unsupported" reason code to Figure 4 and substitute "Block unsupported" for "Block unintelligible" in 5.6.

[ section 5.9 ]

>	A darn good point.  On reviewing this section I think it needs to be rewritten as follows:

Note that the bundle fragmentation procedure described in 5.8 above may result in the replacement of a single original bundle with an arbitrarily large number of fragmentary bundles.  In order to be delivered at a destination node, the original bundle's payload must be reassembled from the payloads of those fragments.

The "salient extents" of a received fragment's payload are all continuous sequences of bytes in that payload that do not overlap with the salient extents of the payloads of any previously received fragments with the same source node ID and creation timestamp.  If the concatenation – as informed by fragment offsets and payload lengths – of the salient extents of the payloads of this fragment and  all previously received fragments with the same source node ID and creation timestamp as this fragment forms a continuous byte array whose length is equal to the total application data unit length noted in the fragment’s primary block, then:
•	This byte array -- the reassembled application data unit -- MUST replace the payload of that fragment whose salient extents include the extent at offset zero.  Note that this will enable delivery of the reconstituted original bundle as described in Step 1 of 5.7.
•	The "Reassembly pending" retention constraint MUST be removed from every other fragment with the same source node ID and creation timestamp as this fragment.

Note: reassembly of application data units from fragments occurs at the nodes that are members of destination endpoints as necessary; an application data unit MAY also be reassembled at some other node on the path to the destination.

>	A conformant implementation will never create such a fragment, because of the definition of "fragmenting" in the second paragraph of 5.8: the length of one of the fragments would be 0 and the length of the other would be M, both invalid.  But we can fortify this constraint by changing "are" to "MUST be".  I think the fragment acceptance procedure in 5.9 would handle such a fragment correctly if a non-conformant implementation created one.

[[ comments ]]

[ section 4.2.2 ]

>	Sure.

[[ questions ]]

[ section 4.3.3 ]

>	There was a very brief discussion of this in January of 2017.  Having the two fields does provide some additional information - if you only decrement hop limit to zero you have no idea what value it started out with, which might be important for some routers.  It wasn't a major point of contention and could have gone either way.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Dec 2020 09:47:41 +0000

Hi Scott,

WG, please pay attention here as there are text proposals. 

Some comments inline

Scott, I would note that your usage of > to mark the lines you added likely have
the reverse effect that you intended in a number of email software, including
Evolution. It is interpreted as a quote from previous email. Which has the
interesting effect that the text I should read was greyed while what was quoted
is black. 

On Fri, 2020-12-04 at 21:48 +0000, Burleigh, Scott C (US 312B) wrote:
> Cc: [email-masked]; [email-masked]; [email-masked]; Fred
> Templin <[email-masked]>; [email-masked]
> > 	No, in the case of a locally sourced node we definitely DO NOT want to
> > exclude the possibility of the node forwarding the bundle to itself (BP
> > loopback).  The procedure described in 5.3 applies only to a bundle that has
> > been forwarded by some node and has been received at the local node; the
> > only entry into the procedure in 5.3 is from Step 5 of 5.6 (Bundle
> > Reception).
> > 	It could well be argued that the content of 5.3 should simply be
> > inserted at the end of 5.6.  The current organization was retained from
> > RFC5050, for continuity, but I would be fine with making that change. 
> 
> [ section 5.4.2 ]
> 
> > 	The question, I think, is how worried we are about ping-ponging.  If the
> > node that is performing 5.4.2 decides to send the bundle back to the
> > Previous Node, and that node then decides to reforward it again in the same
> > way (based on its current information about the network topology), it's
> > possible that the second forwarding attempt at this node will succeed
> > because of changes in configuration or connectivity.
> > 	Obviously we can't tolerate infinite ping-ponging, but bundle lifetime
> > and/or Hop Count limit will defend against that, even if routing
> > implementations are simple-minded.  We've thought about this quite a bit,
> > and I'd like to leave this text as is.
> 
> [ section 5.6 ]
> 
> > 	I agree.  I would propose to add a new "Block unsupported" reason code
> > to Figure 4 and substitute "Block unsupported" for "Block unintelligible" in
> > 5.6.
> 
> [ section 5.9 ]
> 
> Note that the bundle fragmentation procedure described in 5.8 above may result
> in the replacement of a single original bundle with an arbitrarily large
> number of fragmentary bundles.  In order to be delivered at a destination
> node, the original bundle's payload must be reassembled from the payloads of
> those fragments.
> 
> The "salient extents" of a received fragment's payload are all continuous
> sequences of bytes in that payload that do not overlap with the salient
> extents of the payloads of any previously received fragments with the same
> source node ID and creation timestamp.  If the concatenation – as informed by
> fragment offsets and payload lengths – of the salient extents of the payloads
> of this fragment and  all previously received fragments with the same source
> node ID and creation timestamp as this fragment forms a continuous byte array
> whose length is equal to the total application data unit length noted in the
> fragment’s primary block, then:
> •	This byte array -- the reassembled application data unit -- MUST replace
> the payload of that fragment whose salient extents include the extent at
> offset zero.  Note that this will enable delivery of the reconstituted
> original bundle as described in Step 1 of 5.7.
> •	The "Reassembly pending" retention constraint MUST be removed from every
> other fragment with the same source node ID and creation timestamp as this
> fragment.
> 
> Note: reassembly of application data units from fragments occurs at the nodes
> that are members of destination endpoints as necessary; an application data
> unit MAY also be reassembled at some other node on the path to the
> destination.
> 

I would like you to consider using another word than "salient". First of all I
had to look its definition up, even if I did remember one of its meanings.
Secondly, I don't know in this text if you want the "important" (adjective) or
the "pointing outwards" or protruding meaning (adjective and noun). And I would
note that pointing outwards appears to imply that it is angled in relation to a
base which makes no sense in this context where we are talking about a byte
array. 

I have trouble understanding if there are any specific aspects in BP that
require you to have more than the rule in RFC 8200 to drop the whole bunle if
any fragment overlaps with previous received fragments. There is the extra
wrinkle of handling duplication of fragments and if you should track that to
avoid a duplicated fragment as overlapping with already received. But beyond
that I don't know if you have any additional considerations here? 

Cheers

Magnus

> > 	A conformant implementation will never create such a fragment, because
> > of the definition of "fragmenting" in the second paragraph of 5.8: the
> > length of one of the fragments would be 0 and the length of the other would
> > be M, both invalid.  But we can fortify this constraint by changing "are" to
> > "MUST be".  I think the fragment acceptance procedure in 5.9 would handle
> > such a fragment correctly if a non-conformant implementation created one.
> 
> [[ comments ]]
> 
> [ section 4.2.2 ]
> 
> > 	There was a very brief discussion of this in January of 2017.  Having
> > the two fields does provide some additional information - if you only
> > decrement hop limit to zero you have no idea what value it started out with,
> > which might be important for some routers.  It wasn't a major point of
> > contention and could have gone either way.
> 
> 
>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Mon, 7 Dec 2020 14:49:22 +0000

Hi, Magnus.  The ">" problem is new to me, but I guess I can use "[SBx]" instead.  As for "salient", sure, let's substitute "material".

On reassembly: dropping the whole bundle if any fragment overlaps with previously received fragments is not at all what we want to do.  Fragment overlaps are not anomalous in any way, as it is entirely nominal for multiple copies of a bundle to be concurrently taking different paths to the destination (this is how most terrestrial DTN forwarding works) and the fragmentation that occurs on one path might be wildly different from that which occurs on another path.

The only thing we fragment is the payload, which should be immutable from source to destination, so the order of superposition of overlaps should be irrelevant.  If it is not -- that is, if you get different results from reassembling in different ways -- then one or more fragments have been corrupted (i.e., changed) and the effect is the same as if the payload had been corrupted in any other way.  The CRC or BIB on the payload block should report the transmission failure and the application should act accordingly. 

I believe that the way I wrote this up is the way we want it to work.

Scott

-----Original Message-----
From: Magnus Westerlund <magnus.westerlund=[email-masked]> 
Sent: Monday, December 7, 2020 1:48 AM
To: [email-masked]; Burleigh, Scott C (US 312B) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [EXTERNAL] Erik Kline's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)

Hi Scott,

Some comments inline

Cheers

Magnus

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Dec 2020 15:42:25 +0000

Hi Scott,

So the below indicates that you actualy want to allow something that IPv6
forbidds. And I do think you have reasons for allowing this. However, have you
read RFC 5722 and considered if there are attacks on BP nodes between source and
destination that could be fooled by manipulating the content of fragments. I
think this attack is not an issue assuming two things:

1. No on-path node will actually look into the data fragments. (This is clearly
not true on the Internet). 

2. That each on path node treat each BP fragment independently and don't create
state. Becasue if you create state from one fragment, that will affect the
processing of subsequent fragments then you could fool the network to believe
that you are doing one thing and do something else. 

So I think some more thought is needed here to ensure that no security issue is
created. 

Cheers

Magnus

On Mon, 2020-12-07 at 14:49 +0000, Burleigh, Scott C (US 312B) wrote:
> Hi, Magnus.  The ">" problem is new to me, but I guess I can use "[SBx]"
> instead.  As for "salient", sure, let's substitute "material".
> 
> On reassembly: dropping the whole bundle if any fragment overlaps with
> previously received fragments is not at all what we want to do.  Fragment
> overlaps are not anomalous in any way, as it is entirely nominal for multiple
> copies of a bundle to be concurrently taking different paths to the
> destination (this is how most terrestrial DTN forwarding works) and the
> fragmentation that occurs on one path might be wildly different from that
> which occurs on another path.
> 
> The only thing we fragment is the payload, which should be immutable from
> source to destination, so the order of superposition of overlaps should be
> irrelevant.  If it is not -- that is, if you get different results from
> reassembling in different ways -- then one or more fragments have been
> corrupted (i.e., changed) and the effect is the same as if the payload had
> been corrupted in any other way.  The CRC or BIB on the payload block should
> report the transmission failure and the application should act accordingly. 
> 
> To: [email-masked]; Burleigh, Scott C (US 312B) <
> [email-masked]>; [email-masked]

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Mon, 7 Dec 2020 19:28:15 +0000

Hi, Magnus.  The issue addressed by RFC 5722 is clearly critical in IPv6, but I don't think it argues for a prohibition on segment overlaps in BP.

The threat identified in RFC 5722 is that an attacker may alter a fragment - or create a new fragment - in such a way that a firewall inspecting the fragments will make erroneous inferences about the upper-layer (here, TCP) data being conveyed by the fragments, following which the effect of delivering the reassembled IPv6 packet to the destination will be to enact upper-layer behavior that benefits the attacker.

The prohibition on overlaps in IPv6 has two components:
1.	Overlapping fragments must not be created by the packet source.
2.	The receiver of fragments must abandon packet reassembly when fragment overlap is detected.

Since an attacker's BP node will be, by definition, non-conformant, extending prohibition component #1 to BP wouldn't improve the security of the protocol.  It will always be possible for overlapping fragments to be in circulation in the network.  The burden of securing fragment processing necessarily falls on the receiver of fragments.

When the receiver of fragmentary bundles is the destination node (the only point at which reassembly is required), including a malicious fragment in the reassembled application data unit will have the same effect as any innocent payload corruption due to link error or whatever: the payload block's CRC and/or BIB verification will fail, and the processing of the corrupt payload will then be a matter of implementation policy at the receiving node.  Fragmentation isn't really the issue: an attacker could just as easily modify the payload of an un-fragmented bundle as that of a fragment, so merely prohibiting fragment overlap is no defense.

When the receiver of fragmentary bundles is an intermediate forwarder on the end-to-end path:
-	If the forwarding node is not a firewall, then it very likely has no reason to inspect the upper-layer data being carried by the fragments; it simply forwards them.
-	If the forwarding node is a firewall that is required to do "deep bundle  inspection" then it should never forward fragments.  It needs to reassemble the original application data unit from fragmentary payloads in order to make an informed judgment about the upper-layer data (and then forward only the reassembled original bundle), and when it does so the CRC and/or BIB verification of the reassembled application data unit should detect payload corruption.  Again, that verification is needed regardless of whether or not the bundle is reassembled from fragments; merely prohibiting fragment overlap is no defense.

So I would suggest that prohibiting fragment overlap in BP (a) would offer no significant improvement in security and (b) would degrade network performance by crippling bundle forwarding in opportunistic DTN topologies.  Let's not do it.

Scott

-----Original Message-----
From: Magnus Westerlund <[email-masked]> 
Sent: Monday, December 7, 2020 7:42 AM
To: [email-masked]; scott.c.burleigh=[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [EXTERNAL] Erik Kline's No Objection on draft-ietf-dtn-bpbis-29: (with COMMENT)

Hi Scott,

So the below indicates that you actualy want to allow something that IPv6 forbidds. And I do think you have reasons for allowing this. However, have you read RFC 5722 and considered if there are attacks on BP nodes between source and destination that could be fooled by manipulating the content of fragments. I think this attack is not an issue assuming two things:

1. No on-path node will actually look into the data fragments. (This is clearly not true on the Internet). 

2. That each on path node treat each BP fragment independently and don't create state. Becasue if you create state from one fragment, that will affect the processing of subsequent fragments then you could fool the network to believe that you are doing one thing and do something else. 

So I think some more thought is needed here to ensure that no security issue is created. 

Cheers

Magnus

On Mon, 2020-12-07 at 14:49 +0000, Burleigh, Scott C (US 312B) wrote:
> previously received fragments is not at all what we want to do.  
> Fragment overlaps are not anomalous in any way, as it is entirely 
> nominal for multiple copies of a bundle to be concurrently taking 
> different paths to the destination (this is how most terrestrial DTN 
> forwarding works) and the fragmentation that occurs on one path might 
> be wildly different from that which occurs on another path.
> 
> The only thing we fragment is the payload, which should be immutable 
> from source to destination, so the order of superposition of overlaps 
> should be irrelevant.  If it is not -- that is, if you get different 
> results from reassembling in different ways -- then one or more 
> fragments have been corrupted (i.e., changed) and the effect is the 
> same as if the payload had been corrupted in any other way.  The CRC 
> or BIB on the payload block should report the transmission failure and the application should act accordingly.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 Dec 2020 08:35:00 +0000

Hi,

Yes, I agree with your conclusion. BP doesn't have the same baggage as IP has.
And clearly a BP firewall could easily encounter very large bundles and would
need to work on bundle level. And if BPSec is used, each bundle will have one
intended form the authentication will accept. And it is that form that needs to
be considered by any higher layer processing. 

So I think this provides a good answer to Erik's "discuss" why it is notapplicable. 

Cheers

Magnus

On Mon, 2020-12-07 at 19:28 +0000, Burleigh, Scott C (US 312B) wrote:
> Hi, Magnus.  The issue addressed by RFC 5722 is clearly critical in IPv6, but
> I don't think it argues for a prohibition on segment overlaps in BP.
> 
> The threat identified in RFC 5722 is that an attacker may alter a fragment -
> or create a new fragment - in such a way that a firewall inspecting the
> fragments will make erroneous inferences about the upper-layer (here, TCP)
> data being conveyed by the fragments, following which the effect of delivering
> the reassembled IPv6 packet to the destination will be to enact upper-layer
> behavior that benefits the attacker.
> 
> Since an attacker's BP node will be, by definition, non-conformant, extending
> prohibition component #1 to BP wouldn't improve the security of the
> protocol.  It will always be possible for overlapping fragments to be in
> circulation in the network.  The burden of securing fragment processing
> necessarily falls on the receiver of fragments.
> 
> When the receiver of fragmentary bundles is the destination node (the only
> point at which reassembly is required), including a malicious fragment in the
> reassembled application data unit will have the same effect as any innocent
> payload corruption due to link error or whatever: the payload block's CRC
> and/or BIB verification will fail, and the processing of the corrupt payload
> will then be a matter of implementation policy at the receiving
> node.  Fragmentation isn't really the issue: an attacker could just as easily
> modify the payload of an un-fragmented bundle as that of a fragment, so merely
> prohibiting fragment overlap is no defense.
> 
> -	If the forwarding node is not a firewall, then it very likely has no
> reason to inspect the upper-layer data being carried by the fragments; it
> simply forwards them.
> -	If the forwarding node is a firewall that is required to do "deep
> bundle  inspection" then it should never forward fragments.  It needs to
> reassemble the original application data unit from fragmentary payloads in
> order to make an informed judgment about the upper-layer data (and then
> forward only the reassembled original bundle), and when it does so the CRC
> and/or BIB verification of the reassembled application data unit should detect
> payload corruption.  Again, that verification is needed regardless of whether
> or not the bundle is reassembled from fragments; merely prohibiting fragment
> overlap is no defense.
> 
> So I would suggest that prohibiting fragment overlap in BP (a) would offer no
> significant improvement in security and (b) would degrade network performance
> by crippling bundle forwarding in opportunistic DTN topologies.  Let's not do
> it.
> 
> Scott
> 
> read RFC 5722 and considered if there are attacks on BP nodes between source
> and destination that could be fooled by manipulating the content of fragments.
> I think this attack is not an issue assuming two things:
> 
> 2. That each on path node treat each BP fragment independently and don't
> create state. Becasue if you create state from one fragment, that will affect
> the processing of subsequent fragments then you could fool the network to
> believe that you are doing one thing and do something else. 
>