[Swan-dev] ikev2 fragmentation code

[Paul Wouters]

On Tue, 9 Jun 2015, D. Hugh Redelmeier wrote:

> The routine that does the slicing and dicing is only called from two
> functions: ikev2_parent_inR1outI2_tail and
> ikev2_parent_inI2outR2_tail_auth_tail.  Are those the only cases where
> fragmentation makes since?

You cannot use fragments in IKE_INIT because you don't have the DH and
you cannot verify any fragments yet (or figure out which fragments are
of which new connection)

Other than that, every exchange is fair game, although most of them
won't really ever need it. We know IKE_AUTH (the ones you refer to
above) is the relaly important exchange that needs it.

But there is no real reason why we would not support fragmentation of
an Informational Exchange or CREATE_CHILD_SA. The latter _could_ at
some point need it if PFS and DH values get really big?


The RFC states:

    Since IKE Fragment messages are cryptographically protected, SK_a and
    SK_e must already be calculated.  In general, it means that the
    original message can be fragmented if and only if it contains an
    Encrypted payload.

    This implies that messages of the IKE_SA_INIT exchange cannot be
    fragmented.  In most cases, this is not a problem because IKE_SA_INIT
    messages are usually small enough to avoid IP fragmentation.  But in
    some cases (advertising a badly structured long list of algorithms,
    using large Modular Exponentiation (MODP) groups, etc.), these
    messages may become fairly large and get fragmented at the IP level.
    In this case, the solution described in this document will not help.

    Among existing IKEv2 extensions, messages of an IKE_SESSION_RESUME
    exchange, as defined in [RFC5723], cannot be fragmented either.

And it lists one more corner case:

    Currently, there are no IKEv2 exchanges that define messages,
    containing both unprotected payloads and payloads, that are protected
    by the Encrypted payload.  However, IKEv2 does not prohibit such
    construction.  If some future IKEv2 extension defines such a message
    and it needs to be fragmented, all unprotected payloads MUST be
    placed in the first fragment (with the Fragment Number field equal to
    1), along with the Encrypted Fragment payload, which MUST be present
    in every IKE Fragment message and be the last payload in it.

Paul