2401bis Issue # 81 -- Handling outbound red fragments

[Karen Seo <kseo@bbn.com>]

Folks,

Here's a description and proposed approach for:

IPsec Issue #:	81

Title:		Handling outbound red fragments


Description:
=============

     Plaintext	|---------------|   Cyphertext
      Outbound	|               |    Inbound
     ----------->|     IPsec	|<------------
                 |    entity 1   |
                 |               |
                 |---------------|


Although there is some ambiguity, 2401 generally states that SAs 
configured for transport mode operation do not accept outbound red IP 
fragments as inputs. In contrast, tunnel mode SAs are allowed to 
accept outbound red fragments as inputs for BITS, BITW, and security 
gateway implementations. Accepting outbound fragments raises the 
question of how to select an SPD entry, since a fragment may be 
missing applicable selector fields. 2401 indicates that a fragment 
can be mapped to an SA only if the SA selectors for the unavailable 
field(s) are marked as OPAQUE or ANY. Should we change how IPsec 
handles this situation?

Note: While transport mode doesn't work with outbound red IP 
fragments in IPv4, it would work for IPv6...

a. For IPv4, in each fragment, the IPsec header is inserted between 
the IPv4 header, which contans the fragmentation-related fields, and 
the payload.  The receiving system processes the fragmentation 
information before the IPsec header and does reassembly before IPsec 
processing.  It thus ends up with a re-assembled packet containing 
IPsec headers (as many as there were fragments) interspersed 
throughout the data.

b. For IPv6, in each fragment, the IPsec header is inserted before 
the fragmentation-related fields.  The receiving system processess 
the extension headers in order, doing the IPsec processing before 
reassembly.  It thus ends up with a re-assembled packet containing 
only the original payload and no IPsec headers.

Proposed approach:
==================
The current section on how to handle outbound fragments when the port 
fields may be inaccessible will be replaced by the following approach.

"Between each of pair of IPsec implementations, one or more 
tunnel-mode SA will be established that are used to carry ONLY 
non-initial red fragments, if both the source and destination end of 
the IPsec tunnel-mode SA agree to transmit/receive fragments (as 
determined via IKE negotiation or manual configuration). To provide 
this facility, the IPsec implementation MUST support the following:

The SPD entries for the fragment tunnels specify what kind of tunnel 
mode protections are required and MUST have their selectors specified 
as follows:

   WILDCARD = a single range that covers all possible values
   OPAQUE = the value is not available, e.g., it's encrypted
            or the protocol doesn't have that selector, etc.
   ANY = opaque or wildcard

Field   	SPD Entry
--------	-------------
src addr 	WILDCARD, flag set to use the packet value
dst addr	WILDCARD, flag set to use the packet value
protocol*	44
src port 	ANY
dst port	ANY
user id		ANY
sec. labels	ANY
mobil. hdr type	ANY
ICMP type	ANY

   * IPv6 non-initial fragments use 44 to indicate a fragment.

When an initial fragment is received, its selectors will be used to 
look up a matching entry (for packets) in the SPD.  If necessary, an 
SA will be created and the appropriate IPsec protection will be 
applied.  Normal SA setup procedures are followed.

When a non-initial fragment is received, the IPsec implementation 
uses protocol = 44 (fragment) plus the fragment's other selectors (at 
a minimum, IP source and destination addresses) to look up a matching 
entry in the SPD.   If necessary, an SA will be created and the 
appropriate IPsec protection will be applied. Normal SA setup 
procedures are followed.

Because all non-initial fragments will be mapped to SAs using 
protocol selector = 44, the non-initial fragments will automatically 
be placed on the SAs intended for their use.

At the receiving end of the fragment SA, the IPsec implementation 
MUST check and remove the tunnel header, check the fragment's 
selectors against the selectors of the SA, having set the fragment's 
"protocol" to 44, and verify that the fragment is a non-initial 
fragment by looking at the fragment's offset.

There MUST be a mechanism for the administrator to configure a 
minimum fragment offset value to avoid a non-initial fragment from 
overwriting selectors in the initial fragment.  This MAY be a single 
value or there MAY be separate values for IPv4 and IPv6.  The IPsec 
implementation MUST verify that the fragment offset is greater than 
or equal to the minimum offset value.

Thank you,
Karen