[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IKE negotiation for fragmentation controls in IPsec



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). 
----------------------------------------------------------------------

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. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/