Subject: Re: IKE negotiation for fragmentation controls in IPsec

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Jul 2003 10:56:40 -0400

At 1:16 AM +0300 7/1/03, Markku Savela wrote:
>  > From: Stephen Kent <[email-masked]>
>>
>>  if we fragment after IPsec encapsulation, then ANYONE can send
>>  fragments that could cause the IPsec implementation trouble,
>
>You probably don't mean "trouble", such as crashing. Injecting a fake
>"fragment" would just make IPsec on the assembled packet fail the
>checks. This is the trouble you mean?

yes, I do mean trouble as in running out of buffer space due to 
getting lots of bogus, non-initial fragments, and behaving badly as a 
result :-)

>Yes, that is a danger, fragmenting after IPsec makes it easier for the
>attacker to cause packets to be lost (dropped by IPsec).

I Not just lost, but to deluge the receiver with bogus, non-initial fragments

>
>>  if we fragment before encapsulation (but after doing the SPD checks),
>>  then we expose the stack behind the implementation to attacks, but
>
>Ugh.. fragmenting before IPsec would be somewhat akward with "bump in
>stack" implementation (at least for me it would be rather major
>architectural change). However, as implementation never fragments TCP
>packets, only issue is with large UDP packets. Oh well..

Yes, we have to live with the potential for large UDP packets too. 
Even IPv6 does not preclude a host from sending fragments "natively" 
so we have to deal with this issue in some way.

Steve

---

From: Ravi <[email-masked]>
Date: Thu, 03 Jul 2003 10:44:18 +0530

Umm... The routers in between Security gateways can fragment
         the packets and how does the receiving SG behave? One way
         to ensure that the routers in between don't fragment is by 
attaching
         DF bit by transmitting SG and handling of ICMP PMTU messages.

         You seem to be suggesting that there could be active IP ID 
hijacking
          and confuse the receiving router and make SG to discard valid
         packets. Isn't this problem such a big problem? If so, majority of
         applications should fail.

         Also, if a hijacker can do this, why can't he/she spoof ICMP
         PMTU message to confuse the sender.

         Only other solution I could think of: Send the IP packet of length
         which is acceptable by  all routers, I think it is around 570 
bytes or so.
         But performance is going to be very bad and I don't think it is 
acceptable.

         If this feature to be implemented, there should be a way to 
find out
         the maximum path MTU using some other method. One way I could
         think on top of my head is:
         Sending SG finds out the path MTU periodically by starting with
         1500 byte packet and reducing the packet size until the receiver
          receives it successfully. Receiver once receives the packet should
         ACK it. Sender should wait for some time before it reduces the 
packet
         size. Even this protocol also should be protected from hijacker 
in the middle.

         Thanks
          Ravi

Stephen Kent wrote:
> 
> A few folks have observed that the current processing requirements for 
> AH and ESP mandate ciphertext (post IPsec encapsulation) fragmentation 
> and that this poses DoS vulnerabilities for receivers. (An attacker can 
> create what appear to be legitimate, non-initial fragments and cause 
> reassembly problems for the receiver).
> 
> As we revise 2401, we may choose to allow (or even recommend) plaintext 
> (pre-IPsec encapsulation) fragmentation. If so, we need to be able to 
> negotiate use of this capability on a per-SA basis, and to notify the 
> receiver that NO ciphertext fragments should be accepted 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.
> 
> 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).
> 
> 
> Steve
> 

-- 

The views presented in this mail are completely mine. The company is not
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Jul 2003 08:08:47 -0400

At 10:44 +0530 7/3/03, Ravi wrote:
>         to ensure that the routers in between don't fragment is by attaching
>         You seem to be suggesting that there could be active IP ID hijacking
>         which is acceptable by  all routers, I think it is around 
>570 bytes or so.
>         But performance is going to be very bad and I don't think it 
>is acceptable.
>
>         If this feature to be implemented, there should be a way to find out
>         ACK it. Sender should wait for some time before it reduces the packet
>         size. Even this protocol also should be protected from 
>hijacker in the middle.
>
>         Thanks
>          Ravi
>

Ravi,

I can't understand what you are trying to say above.  the wording is 
just too confusing.  try again.

Steve