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

[Ipsec] 2401bis fragment checking for BYPASS/DISCARD



Mark Duffy writes:
> Why stateful fragment checking for BYPASS is not sufficient:

Stateful fragment checking is sufficient if and only if it is done
for all traffic, including BYPASS and PROTECTED traffic. 

> I believe that stateful fragment checking for BYPASS does not preclude this 
> attack and in fact makes it worse.  Assume we have an SPD that says:
>    1.  SA=sa1, SP=any, prot=tcp, DA=da1, DP=25  ==> protect
>    2.  SA=sa1, SP=any, prot=tcp, DA=da1, DP=ANY  ==> bypass.
> Further, assume that stateful fragment checking is done for the bypass.

Lets also assume that the stateful fragment checking is also done for
the protected data. 

> Now, telnet user creates and sends a fragmented packet with (SA=sa1, 
       ^^^^^^
smtp :-)

> SP=2222, prot=tcp, DA=da1, DP=25)
> The fragments of this packet are protected by an SA created per rule 1.
> Attacker removes one or more of the protected non-initial fragments.
> Attacker observes (or guesses) the Ident and SP for those fragments.
> Attacker creates a new packet with (SA=sa1, SP=2222, prot=tcp, DA=da1, 
> DP=3333) and with the given Ident value.  I.e. everything is the same 
> except the dest port and the data.
> Attacker breaks that packet into fragments and sends them.
> The security gateway, with stateful fragment checking, passes all the 
> fragments pursuant to SPD rule 2.

Hmmm.. depends how the statefull fragment checking is done. If it is
done in the style where the packets are queue up until first fragment
is seen, then the first fragment is processed, and rest of the
fragments go through exactly same SA processing than the first
fragment (i.e. it will insert entry to the fragment cache pointing
from src-IP, dst-IP, frag-ID -> SAD-entry, where SAD-entry can be
protect with SPI xxxx, or bypass).

This would mean that either the attacker generated plaintext packets
are discarded as they are not protected if the real first fragment was
processed first, or the protected fragments are sent through without
decryption (bypassed) in case the attacker generated first frament was
processed. 

> Destination host might assemble the non-initial fragments onto
> either initial fragment (the legit one to port 25 or the bogus one
> to port 3333). If it assembles them onto the one with DP=25, the
> attack has succeeded.

That would require the SGW to do both BYPASS and PROTECT processing
for some of the fragments simultaneusly. If the SGW will only do one
of those at time, and its fragment cache has longer timeouts than the
end host, then the end host will be protected. 

> Stateful fragment checking for bypass actually makes this worse because 
> without it, the hostile non-initial fragments will only be bypassed if 
> there is an SPD entry for DP=ANY (or OPAQUE).  With stateful checking, the 
> hostile fragments can also be bypassed pursuant to SPD entries that have 
> non-trivial port selectors.
> 
> My recommendation:
> 
> As far as I can see the SG behavior that completely precludes this attack 
> is for the SG to disallow BYPASS forwarding of any non-initial 
> fragments.  So that should be the required default behavior.  Stateful 
> fragment checking for bypass could be a MAY but with a stern warning about 
> the possibility of this attack.

Hmmm. I can agree that disallowing BYPASS for fragments does protect
the traffic, but I think stateful fragment checking (if properly done)
for all traffic is the safest way to allow fragments and BYPASS rules.
-- 
kivinen@xxxxxxxxxxxxxxx

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