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

Re: 2401bis Issue # 81 -- Handling outbound red fragments

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