[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE negotiation for fragmentation controls in IPsec
At 12:39 AM +0300 7/1/03, Markku Savela wrote:
> > From: Stephen Kent <firstname.lastname@example.org>
>> IPsec has always been applied to fragments that arrive at an SG, or
>> in the case of IPv6, that are emitted by a host internally.
>> >Previously SG had to assemble the packets before doing IPSEC.
>> could you remind me of where we said that in 2401?
>Hmm.. I could have sworn it was said somewhere. But, I guess my mind
>is just playing tricks, by deducing that by implication: if you must
>implement port (or transport protocol in Ipv6) selector, you must
>assemble full packet anyway (at at least potentially buffer all
>fragments, because there have been systems that send fragments in
>reverse order even!)
In fairness, there are several cases. For transport mode, yes, we do
require a BITS or BITW implementation to do reassembly. But for
tunnel mode we don't, hence it is not a requirement for SGs. I
should have been more precise in my comments.
>Concerning the change text...
>> By sending this notification the sender announces that it
>> will always fragment packets before encapsulating them to
>> the IPsec packets, i.e the recipient of this notification
>> MAY drop all fragmented IPSec packets, as they are not
>> generated by the other end.
>The last sentence may cause black hole. The sender cannot guarantee
>that some router on the way does not fragment IPSec packet, unless the
>above also implies that sender must set DF bit on IPv4 header? Right?
right. that is part of what the sender must do too.
>Naturally, for IPv6 this is not the issue.
>As for DOS attacks with fragments, I don't see anything that relates
>directly to IPsec. All fragmentation attacks are just fragmentation
>attacts, regardless whether IPsec is present or not.
if we fragment after IPsec encapsulation, then ANYONE can send
fragments that could cause the IPsec implementation trouble, and
maybe adversely affect all subscribers behind the implementation.
This is especially bad for an SG.
if we fragment before encapsulation (but after doing the SPD checks),
then we expose the stack behind the implementation to attacks, but
only from the authorized peers they have elected to communicate with,
as per the SPD entry for S/D IP addresses and protocol.