[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Problem about reassembly and fragmentation

Title: Re: Problem about reassembly and fragmentation
As I have understood, Outermost IP header should not have fragments for encryption or decryption.
 
While Encrypting - In transport mode - NO fragments (if fragmented drop it). In tunnel mode, inner IP header may have fragmentation but outer IP header is not. After encrypting the packet you may do fragmentation.
 
While Decrypting- If the packet is fragmented, it should be reassembled first before decryption.
 
Thanks
Rajendra Prasad
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Friday, March 08, 2002 2:49 PM
To: Scott Fluhrer
Cc: ipsec@lists.tislabs.com
Subject: Re: Problem about reassembly and fragmentation

At 2:33 PM -0800 3/8/02, Scott Fluhrer wrote:
At 11:44 AM 3/8/2002, Stephen Kent wrote:
At 10:32 AM -0800 3/8/02, Scott Fluhrer wrote:

Obnit: you can encrypt fragments in tunnel mode.  In transport mode,
you can only encrypt unfragmented packets, and so you must reassemble
(or drop) if you get fragments.  And yes, there are IPSec
implementations where you could possibly see fragments that need to be
encrypted using transport mode.

RFC 2401 states that transport mode is to be used only between endpoints, and that the next layer protocol is typically a transport layer protocol, apropos the mode name.  In what circumstances do you see fragments (hence another IP header) being encapsulated in transport mode? L2TP?

The implementation I'm thinking about acts as a BITW in front of a specific end point (IP address), and intercepts all traffic to/from the end point, and encrypts/decrypts traffic on behalf of the end point.  The BITW itself doesn't have an IP address, and so it borrows the end point's.  To anything past the BITW, the BITW and the endpoint appear to be one unit that does (among other things) IPSec.  And so, if the end point sends fragments with itself as the source IP address, then the BITW may decide to encrypt them, and if the SA it selects happens to be in transport mode, well, we're in exactly the scenario I eluded to above...
Steve

Scott,

Note the following from 2401 (Appendix B), with my application of bold text:

B.2 Fragmentation

   If required, IP fragmentation occurs after IPsec processing within an
   IPsec implementation. Thus, transport mode AH or ESP is applied only
   to whole IP datagrams (not to IP fragments).  An IP packet to which
   AH or ESP has been applied may itself be fragmented by routers en
   route, and such fragments MUST be reassembled prior to IPsec
   processing at a receiver.  In tunnel mode, AH or ESP is applied to an
   IP packet, the payload of which may be a fragmented IP packet.  For
   example, a security gateway, "bump-in-the-stack" (BITS), or "bump-
   in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to
   such fragments. Note that BITS or BITW implementations are examples
   of where a host IPsec implementation might receive fragments to which
   tunnel mode is to be applied.  However, if transport mode is to be
   applied, then these implementations MUST reassemble the fragments
   prior to applying IPsec.

I confess I am slightly confused: I thought I was saying precisely what the highlighted text says.  That is, when I said:

> In transport mode, you can only encrypt unfragmented packets, and so you must reassemble (or drop) if you get fragments.

I meant that "if transport mode is applied, then you must reassemble the fragments prior to applying IPSec".  This would appear to be precisely what the RFC says, except that the RFC specifies it only for "these implementations" (by which the RFC doesn't really mean this restriction is limited only to BITS and BITW implementations), and that I added the proviso that dropping it was possible, mostly for completeness.
Just out of curiosity, what did you think I meant?  You're not the only one who raised a question, and so I'd like to know how I was unclear.

Whoops; I overlooked that part of your comment. We are in agreement here.

I would like to push in the direction of not having to accept fragments at a BITW/BITS or SG, using ICMP PMUT message to push back at hosts, so that we could avoid the need to reassemble in any mode (tunnel or transport) and so that one can always apply full selector sets to traffic, not having to worry about the unavailability of releveant fields due to fragmentation.

Steve