Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis(section 7)

[Tero Kivinen <kivinen@iki.fi>]

Satoshi Inoue writes:
> BTW, is fragmented user traffic (i.e. forwarding packets that are
> already fragmented, not the ones that are fragmented by IPsec tunnel
> I/F MTU size) affected by this?

We are only talking about those packets. I.e packets that are already
fragmented when the arrive the SGW, and which should be put to the
tunnel, and the tunnel SAs have port selectors. 

> or is it out of scope in this section?

No it is the whole scope of the section.

> How about fragmented user traffic that is too big for an outgoing
> IPsec tunnel's MTU size?

There is who issues combined there. If user sends 3000 byte UDP packet
to port 1234, which is fragmented to two 1500 byte packets. The SGW
will get those two. It now needs to find the proper SA to send them.
If SGW have IPsec SA (SA1) with port selectors matching the packet to
port 1234, he will send the first of those fragments to that SA. The
question is what to do the second fragment. It does not have port
numbers, thus he cannot select the SA for it. The proposal #3 says,
that ok, we have seen the first fragment, thus we can put up
information that if we see other fragments to that packet, send them
to same SA1. The proposal #2 says that we need to have specific SA2
for non-first fragments, and we send all non-first fragments to there
regardless of their port numbers.

So if user then send another 3000 byte UDP packet to port 2345, then
the #3 system will drop both fragments, as they do not match the
policy. The #2 system will drop the first fragment, as it does not
match the policy, but it will pass the second fragment as it matches
the policy of the non-first fragment SA (SA2).

Now, when we have the SA selected, we can do the actual encryption. If
that cause the packet to be too big for the MTU, the resulting
encrypted IPsec packet can be then fragmented again. This
fragmentation is removed in the other ends SGW, when it needs to
reassemble the packet before it can decrypt the packet. This section
is NOT covering that at all, it is completely outside the of this
section. This is covered elsewhere in the architecture document. 

> > Another point which has been discussed is how difficult it is to
> > implement stateful fragment inspection.  Tero has pointed out that his
> > implementation has supported this for quite some time, and it isn't
> > particularly difficult.
> 
> Just one clarification, could this implementation work out re-ordered/
> non-ordered fragments OK?

Yes.

If the non-first fragment arrives first, then it is queued in separate
fixed length queue for waiting the first-fragment to arrive. When it
arrives and the SA is selected, an entry is put to the stateful
fragmentation code which will know that rest of the fragments to the
same packets should be sent to the same SA. After that entry is put to
the cache, the queue of non-first fragments is checked, and if there
are any fragments which are part of that pakcet, they are also sent
forward. 
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec