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

[Magnus Westerlund <[e-mail]>]

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