[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