Subject: [Ipsec] Fragment handling in IPv6 based IPsec

From: Surya Batchu <[email-masked]>
Date: Sun, 9 Jan 2005 09:35:49 -0800 (PST)

Please validate my understanding.
 
Assumption: Security policy is configured with transport selectors.
 
IPv6:
 
Case1:  IPsec device is deployed in an environment, where all IP packets (all fragments) will go through the device.
 
All fragments of a packet can be gathered together (Some sort of Pseudo reassembly) , SPD policy is checked. 
 
Case A: 'fragCheck' is TRUE in the policy.  If the peer does not support 'stateful fragment check',   SAs will not be established and thereby no traffic would pass through. User of the device can be informed through auditable event indicating that peer does not support 'stateful fragment checking'.  If the peer supports it, SA establishment goes through and traffic will pass through the tunnel.
 
Case B:  fragCheck is FALSE in the policy. In this case, if there is no policy with transport selector values set to OPAQUE, then there is a possibility that, the non-initial fragments would not be secured and most probably would be discarded (if there is no BYPASS policy). 
Also, based on rfc2401-bis, this case is not preferable for IPv6.

Case 2: IPsec device is deployed in an environment where all outbound fragments may not come to same IPsec device.
 
In case of pseudo reassembly fragments is not possible. 
 
In this case, even 'fragCheck' is set to TRUE in the policy, device should not negotiate 'stateful fragment related IKV2 notify message'.   It should fallback onto 'separate tunnel SA for non-initial fragments'.  If this is not desirable (as per RFC2401-bis, this is not desirable for IPv6), then the only option is to disallow user to configure any security policies with transport selectors ie all policies should have IPv6 address selectors only.

In summary:
In case1, all security policies with transport selectors must have 'fragCheck' set to TRUE.
In case2, security policies must not be configured with transport selectors.

Surya

 

---------------------------------
Do you Yahoo!?
 All your favorites on one personal page – Try My Yahoo!

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Jan 2005 14:12:57 -0500

At 9:35 AM -0800 1/9/05, Surya Batchu wrote:
>Content-Type: text/html; charset=us-ascii
>X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA25887
>

I assume you mean non-trivial port selectors (the phrase defined in 
240abis), and the reference is to an SPD policy entry, which is the 
subject of the discussion below, right?

>IPv6:
>
>Case1:  IPsec device is deployed in an environment, where all IP 
>packets (all fragments) will go through the device.
>
>All fragments of a packet can be gathered together (Some sort of 
>Pseudo reassembly) , SPD policy is checked.

it looks like you talking about an IPsec device as a sender, but it 
would be nice to say so explicitly. also, you have not clearly stated 
the context the discussion, e.g., arrival of an outbound packet at a 
sender with no extant, matching SA in place to carry the packet, and 
a resulting search of the SPD to locate a policy and establish an SA 
with a peer. is the packet that triggers the SA creation a 
non-initial fragment?

>  Case A: 'fragCheck' is TRUE in the policy.  If the peer does not 
>support 'stateful fragment check',   SAs will not be established and 
>thereby no traffic would pass through. User of the device can be 
>informed through auditable event indicating that peer does not 
>support 'stateful fragment checking'.  If the peer supports it, SA 
>establishment goes through and traffic will pass through the tunnel.

right, assuming all of the context info I added above.

>  Case B:  fragCheck is FALSE in the policy. In this case, if there 
>is no policy with transport selector values set to OPAQUE, then 
>there is a possibility that, the non-initial fragments would not be 
>secured and most probably would be discarded (if there is no BYPASS 
>policy).

This is basically true, if I interpret you comments to refer to 
non-initial fragments being compared to the SPD and the SAD based on 
address and protocol matching, so that the ambiguity is just in terms 
of the port fields. Having a BYPASS entry that would allow 
non-initial fragments to be bypassed, when initial ones would be 
protected, would be a bad idea. 2401bis does not say this case is 
bad, per se, for IPv6. It is a problem for v4 as well, since the 
conditions you cite rule out all three of the options described in 
section 7 for accommodating fragments.

>Case 2: IPsec device is deployed in an environment where all 
>outbound fragments may not come to same IPsec device.

you mean inbound fragments, not outbound fragments.

>  In case of pseudo reassembly fragments is not possible.

2401bis says stateful fragment checking may fail in such contexts.

>  In this case, even 'fragCheck' is set to TRUE in the policy, device 
>should not negotiate 'stateful fragment related IKV2 notify 
>message'.   It should fallback onto 'separate tunnel SA for 
>non-initial fragments'.  If this is not desirable (as per 
>RFC2401-bis, this is not desirable for IPv6), then the only option 
>is to disallow user to configure any security policies with 
>transport selectors ie all policies should have IPv6 address 
>selectors only.

A local admin may choose to try stateful fragment checking even under 
these circumstances, since it may work most of the time anyway, 
depending on a variety of factors. For example, how often fragments 
arise, whether the multiple paths permitted by the multiple SGs are 
invoked for load sharing in a way that makes it likely that fragments 
of a single packet are sent to different destination SGs, etc.

>In case2, security policies must not be configured with transport selectors.

This summary seems a bit oversimplified, perhaps because I had to try 
to fill in a lot of missing context for your questions/statements.

It is fair to say that IF one chooses to accommodate fragments over 
tunnels (many enterprise environments do not) and IF your security 
policy makes use of port-field selectors (not all enterprises do), 
THEN use of stateful fragment checking is a good idea for IPv6, since 
the separate tunnel option defined in section 7.2 is not advisable 
for IPv6.  In contexts where there are multiple security gateways 
serving an enclave, it may or may not be OK to use port selectors. In 
practice, the existence of multiple security gateways does not always 
mean that fragments of a single packet will often arrive at different 
gateways, although this is possible.  In many contexts the fragments 
for a given packet will likely traverse the same gateway, making 
stateful checking feasible.

Steve

---

From: Surya Batchu <[email-masked]>
Date: Wed, 12 Jan 2005 07:57:26 -0800 (PST)

Hi Steve,

Yes. Context of original email is in re: outbound
packets, ie packets going from protected and
unprotected. Your concluding comments indeed clear up
lot of things for me.

Thanks
Surya

--- Stephen Kent <[email-masked]> wrote:

> >In case1, all security policies with transport
> selectors must have 
> >'fragCheck' set to TRUE.

__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com