Subject: [IPsec] Pre-fragmentation of IPsec tunneled packets

From: Gandhar Gokhale <[email-masked]>
Date: Thu, 30 Aug 2012 16:10:03 +0530

Hi,
RFC 4301, section 5.1 says that if pre-fragmentation is to be supported
then the policy lookup has to happen on fragmented packets and the
non-initial fragments will not match any policy with non-trivial ports.
I've a doubt in this. After searching on the Internet for earlier results I
could not find if it was discussed previously on this list nor did I find
it in the RFC 4301 errata.
Here's the relevant excerpt:
*"Note: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or
BITW implementation MAY fragment packets before applying IPsec. (This
applies only to IPv4. For IPv6 packets, only the originator is allowed to
fragment them.) The device SHOULD have a configuration setting to disable
this.  The resulting fragments are evaluated against the SPD in the normal
manner. Thus, fragments not containing port numbers (or ICMP message type
and code, or Mobility Header type) will only match rules having port (or
ICMP message type and code, or MH type) selectors of OPAQUE or ANY. (See
Section 7 for more details.)"*

For deciding whether to fragment a packet we need to know the packet's
length and MTU (or PMTU but to k) ofthe interface. IPsec tunnel alters
length of the packet and possibly outgoing interface as well. It means the
policy affects the decision of whether a packet would get frameneted or
not. However, RFC section 5.1 requires implementation to perform policy
lookup on the fragmented packet. How can the implementation decide if the a
packet should be fragmented before knowing what policy (and SA) will match?
Moreover, the section 7.3 (reassembly for policy verification) becomes
redundant if implementation has conformed to section 5.1 since the
non-initial fragments are required to match only 3-tuple policy at sender.
That means, at the receiver non-initial fragements must be matched only to
policy rules without non-trivial ports.

Can someone please help me understand what I'm missing here?

Thanks and regards,
Gandhar Gokhale
Networking Components Group
LSI

---

From: Gandhar Gokhale <[email-masked]>
Date: Thu, 30 Aug 2012 18:54:09 +0530

Hi Michael,

Thanks for sharing your thoughts. If the IPsec "implementation" receives a
fragmented plain text packet for encrypting and sending out then it is not
really a pre-fragmentation. Pre-fragmentation requires the IPsec itself
needs to decide whether to fragment an incoming plain text fragment before
encrypting it. The question is, how to make that decision if MTU & packet
size is decided by policy and SA. RFC asks us to use a policy with layer 3
selectors only for the non initial fragments. However, the decision to
fragment can not be made without doing policy lookup. This is a circular
dependancy.
My suspicion is that RFC expects us to look the full L4 policy for the full
packet and a subsequent policy lookup for each individual (non-initial)
fragment though it does not explictly state so. This is not quite obvious
from the description of the outbound processing in the RFC though and
therefore my suspicion may be invalid.

Thanks and regards,
Gandhar Gokhale
Networking Components Group
LSI
On Thu, Aug 30, 2012 at 5:41 PM, Michael Richardson
<[email-masked]>wrote:

>
> >>>>> "Gandhar" == Gandhar Gokhale <[email-masked]> writes:
>     Gandhar> relevant excerpt: *"Note: With the exception of IPv4 and
>     Gandhar> IPv6 transport mode, an SG, BITS, or BITW implementation
>     Gandhar> MAY fragment packets before applying IPsec. (This applies
>     Gandhar> only to IPv4. For IPv6 packets, only the originator is
>     Gandhar> allowed to fragment them.) The device SHOULD have a
>
> So, it's important to realize the "SG", "BITS" and "BITW" parts all put
> the IPsec at a distance from the IP layer.  So the fragmentation already
> occurred before (and maybe some distance) from the IPsec policy layer.
>
>     Gandhar> For deciding whether to fragment a packet we need to know
>     Gandhar> the packet's length and MTU (or PMTU but to k) ofthe
>     Gandhar> interface. IPsec tunnel alters length of the packet and
>     Gandhar> possibly outgoing interface as well. It means the policy
>     Gandhar> affects the decision of whether a packet would get
>     Gandhar> frameneted or not. However, RFC section 5.1 requires
>
> What we decided that we would not require, was for the SG/BITS/BITW to
> assemble the fragmented packet before applying the policy.  For *many*
> (95%) site-to-site policies, we never need to look beyong layer-3 anyway,
> so let's not make reassembly a requirement.
>
>     Gandhar> implementation to perform policy lookup on the fragmented
>     Gandhar> packet. How can the implementation decide if the a packet
>     Gandhar> should be fragmented before knowing what policy (and SA)
>     Gandhar> will match?  Moreover, the section 7.3 (reassembly for
>     Gandhar> policy verification) becomes redundant if implementation
>
> 7.3 is a MAY, and it's use is signaled.
> If your system (because it's built into the stack) can do policy based
> upon non-trivial port information, and will then fragment the packet
> before tunnelling, it will therefore put packets in the tunnel which
> the other end point will be unable to verify properly.
>
>     Gandhar> Can someone please help me understand what I'm missing
>     Gandhar> here?
>
>     Gandhar> Thanks and regards, Gandhar Gokhale Networking Components
>     Gandhar> Group LSI
>
> My guess is that you are building hardware, and you are trying to fit
> all of the IPsec stack into your BITS hardware, not realizing that parts
> can simply not be done unless the host stack is aware of your BITS.
>
> --
> ]       He who is tired of Weird Al is tired of life!           |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] [email-masked] http://www.sandelman.ottawa.on.ca/ |device
> driver[
>    Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE
> >
>                        then sign the petition.
>
>
>