Subject: Re: IPsec issue #49 -- red-side fragmentation option

From: Mark Duffy <[email-masked]>
Date: Thu, 02 Oct 2003 01:03:28 -0400

When an IPsec device sending an outbound packet does red side fragmentation 
there are at least two possible ways to select SAs for the fragments.

One way is to use the SPD entry selected for the initial packet to process 
all the created fragments.  This has some appeal because the initial packet 
is more likely to contain the port numbers (i.e. if it was not itself 
already a fragment).

The other is to create all the fragments first, then search the SPD 
independently for each fragment.  They would then be processed as per Issue 
#81 "Handling outbound red fragments".

The second way seems correct to me because it puts the sender and receiver 
on an equal footing for selecting an SPD entry.  The receiver of the 
IPsec-protected fragments is not going to reassemble them, so it will not 
know which ones came from what initial packet.  Therefore I  think the 
sender should not take advantage of the additional information it has.

In any event, shouldn't the discussion of red side fragmentation in 2401bis 
make a statement on this issue?

--Mark

---

From: Mark Duffy <[email-masked]>
Date: Thu, 02 Oct 2003 00:43:12 -0400

Hi, I have a few questions on this proposal, inline below.  --Thanks, Mark

At 01:49 AM 9/30/2003 -0400, Karen Seo wrote:
>Folks,
>
>Here's a description and proposed approach for:
>
>IPsec Issue #:  81
>
>Title:          Handling outbound red fragments

[snip]

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

Does that mean this approach would be used only if so negotiated in 
IKE?  How does this relate to the "MUST" in the next line below?  How 
should red fragments be processed in the event that it is not negotiated in 
IKE?

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

Do you really mean that the device must have exactly that entry?  The below 
SPD entry looks like it is intended to create exactly 1 SA pair for each 
pair of communicating hosts.  Why should 2401bis be so rigid to require the 
SPD to be set up exactly this way?  That could present a significant 
scalability problem if the number of source-dest pairs is large.  Also, 
what is it that *prevents* non-fragments or initial fragments from matching 
that SPD entry?  I surmise that for v6 the protocol:44 selector 
accomplishes  this.  How about v4?  It seems another selector type such as 
"is non initial fragment" would be needed.

>   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

---

From: Mark Duffy <[email-masked]>
Date: Thu, 02 Oct 2003 00:43:12 -0400

[snip]