Re: IKE negotiation for fragmentation controls in IPsec

[Ravi <ravivsn@roc.co.in>]

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>