[Swan] ike_frag= options - what should it mean and do?

[Paul Wouters]

On Thu, 14 Feb 2013, D. Hugh Redelmeier wrote:

> | From: Paul Wouters <pwouters at redhat.com>
>
> | MAIN_I1 ->
> |         <- MAIN_R1
> | MAIN_I2 ->
> | 	<- MAIN_R2
> | fragments of MAIN_I3 ->
> |          < fragments of MAIN_R3
> | MAIN_I4
>
> Sorry, I don't remember what payloads go where.
>
> Which packets in Main Mode are likely to be fragmented?  Why (i.e. which
> payloads might get fat)?

I3 and R3 are the ones that contain the CERT payloads, which are the
prime reason for pacekts getting bigger then 1500.

> Which packets have the vendorid payloads?

I believe there are two packets that can have them I1/R1 are for the
initial ones, then later on R3 (and I4?) can contain payloads that
have been authenticated before doing Quick Mode (phase2). The latter
ones is currently used for "can do IKEv2" and is where some
implementations send "initial contact" messages.

> Where does encryption start?  (Conventionally denoted by * in these
> diagrams)?

I3 if I'm correct. The first two packet exchanges in main mode establish
the DH.

> How about Aggressive Mode?  I assume that we hope to handle fragmentation
> for Aggressive Mode.

There the first two packet exchanges get merged into one, with the loss
of secrecry for the left/right IDs. We have not yet looked at
fragmentation in aggresive mode, but I wonder if that would not already
work with the current code?

> Oh, and while I'm asking, what are the thoughts about IKEv2 and
> fragmentation.  If I remember: not an urgent requirement.

I have to read up on some of the many IKEv2 documents to see what is
defined there. A quick search seems to show:

http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00

but it looks stalled....

I also see in the updated RFC 5996 IKEv2 RFC:

http://tools.ietf.org/html/rfc5996

    The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation
    control.  See [IPSECARCH] for a fuller explanation.  Both parties
    need to agree to sending non-first fragments before either party does
    so.  It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is
    included in both the request proposing an SA and the response
    accepting it.  If the responder does not want to send or receive non-
    first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification
    from its response, but does not reject the whole Child SA creation.

Paul