Subject: Re: IKE negotiation for fragmentation controls in IPsec

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2003 11:19:08 -0400

Date: Mon, 30 Jun 2003 09:19:33 -0400
To: "Srinivasa Rao Addepalli" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: IKE negotiation for fragmentation controls in IPsec
Cc: <[email-masked]>

At 3:51 PM -0700 6/27/03, Srinivasa Rao Addepalli wrote:
>  > >       Outbound Processing steps:
>>  >              - Reassemble the packet (Packet coming from trusted network).
>>
>>  NO. there is no implied reassembly by the transmitter.
>>
>>  I won't comment on the rest of your message since this assumption was
>>  not right and it may influence later parts of your message.
>>
>
>I am curious on why this is not needed.
>IPSEC SPD supports selector space with not only IP addresses, but also
>with TCP/UDP port values. If some sort of reassembling is not done(either wait
>for all fragments OR maintain reassembly state with IP ID, SIP, DIP), there
>is possibility of mapping the non-first fragments of the packets to the wrong
>security policy. Only first fragment has TCP/UDP information and it chooses
>the correct security policy.
>
>Complete IP reassembling helps in finding out obvious DoS attacks and
>helps in reducing  the number of encapsulated IPSEC packets.

Each inbound IPsec datagram carries and SPI and that maps uniquely to 
an SA. If one links selector info with each SAD entry (part of the 
simplified processing model I'll bee explaining as we progress), then 
there is no ambiguity about which selectors to match against an 
inbound packet.

If the SA calls for examination of port fields, then yes, non-initial 
fragments cannot be examined, but so long as we make sure the offsets 
are large enough to avoid overwriting these fields, then letting such 
fragments through does not seem like a serious problem. Also, as Tero 
noted in his message, at worst one might buffer, but not reassemble, 
non-initial fragments for an SA under such circumstances.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2003 11:19:55 -0400

Date: Mon, 30 Jun 2003 09:14:20 -0400
To: Tero Kivinen <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: IKE negotiation for fragmentation controls in IPsec
Cc: [email-masked]

At 2:33 PM +0300 6/26/03, Tero Kivinen wrote:
>Stephen Kent writes:
>>  for this SA, because none will be sent by this transmitter. So, I
>>  suggest that we add a paylod to IKE to allow an initiator to indicate
>>  the intent to never send ciphertext fragments. The responder can take
>>  advantage of this info to better protect itself, or it can ignore the
>>  info, but it needs to be told to be able to take advantage of the
>>  capability. I would also like to see the responder be able to notify
>>  the initiator of its intent re the companion (reverse) SA, if
>>  appropriate.
>
>Would it be enough to have
>----------------------------------------------------------------------
>         FRAGMENTATION_BEFORE_IPSEC		24587
>
>             By sending this notification the sender announces that it
>             can process packets which are fragmented before being
>             encapsulated to the IPSec packets, i.e the recipient of
>             this notification can send such packets and assume that
>             the other end can process them. If this notification
>             payload is sent by both ends (i.e both ends support this
>             feature), then both ends MUST NOT send packets fragmented
>             after the IPsec encapsulation and SHOULD (configurable by
>             local policy) reject incoming packets which are fragmented
>             after IPsec encapsulation (i.e as the other end must not
>             send them it was either some other router which fragmented
>             it or it was an attack).
>----------------------------------------------------------------------

This does not really convey the right semantics.  What we want is for 
the sender of the payload to say "I will NOT send any post-IPsec 
encapsulation fragments." Any receiver MUST be able to accommodate 
fragments that occur prior to IPsec encapsulation, because these 
fragments could have been generated by a host before arriving at the 
IPsec device. The goal of the proposed payload is to inform the 
receiver so that the receiver can mark an SAD entry to reject all 
fragments that arrive (prior to IPsec encalsulation).

>
>in the section 3.10.1 Notify Message Types - STATUS TYPES?
>
>>  A logical (but admittedly separable) companion to this feature is to
>>  allow the initiator to request the responder to accept fragments on
>>  an SA where port fields are used as selectors. The issue here is that
>>  a host may send fragments to an IPsec device that requires port field
>>  examination for the SA to which the fragments will be mapped. It
>>  seems reasonably safe to allow fragments (with a suitable, minimum
>>  offset) to pass through such as SA, with only the initial fragment
>>  having the port fields examined. This is a separate negotiation
>>  because the fragments arise from hosts behind the IPsec device, but
>>  it is related, because if one fragments at the sending IPsec device,
>>  it would be nice to be able to use this feature to allow the receiver
>>  to pass on fragments, not reassemble them (in the case of a SG).
>
>The normal processing of those packets on the firewalls is to put
>those non-first fragments to (small) queue and when the first fragment
>then arrives, then do the policy check and forward the first fragment
>and all additional fragments forward (and also mark the fragment id so
>that all future fragments to same packet will get through for some
>time). Also care should be taken that the any fragments do not
>overwrite anything from the first fragment that was used for the
>policy checks (i.e the port numbers are not overwritten by later
>non-first fragment).
>
>I am not sure that we should allow sending of the non-first fragments
>to IPsec SAs using the port selectors unless we have validated that
>the port numbers match the policy. There is no need to do the actual
>reassembly, simply queuing the non-first framents coming before the
>first fragment and adding entry that will allow rest of the fragments
>to the packet to get through for some time is enough.

We agree that there is no need for a receiver to reassemble. However, 
so long as we prevent fragments with too-short offsets from 
traversing an SA, I'm not sure much damage (other than a form of DoS 
on an SA where the Source and Dest IP addresses are already 
acceptable) will be done if we allow fragments to pass before we see 
the initial fragment at the receiver.  That avoids the need for any 
buffering at the receiver, which it self might create DoS concerns.

Steve