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

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

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 <[e-mail]> 
Sent: Monday, December 7, 2020 7:42 AM
To: [e-mail]; scott.c.burleigh=[e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
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:
> 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