Re: IKE negotiation for fragmentation controls in IPsec

["Srinivasa Rao Addepalli" <srao@intotoinc.com>]

Hi Steve,

  Negotiation on SA basis:
  Assuming that intermediate router fragmentation problem is solved,
  does it require negotiation on SA basis? I feel, it can be on peer basis.
  Either it can be set as local configuration on peer basis or capabilities
  of the peers can be exchanged using Vendor ID attributes.

   Port Selector information:
   I did not understand all the details you mentioned. I feel, there is no need
   for any IKE negotiation for tunnel mode sessions. I try to list down the
   steps.

      Outbound Processing steps:
             - Reassemble the packet (Packet coming from trusted network).
             - Search for outbound SPD and corresponding SA Bundle to use.
             - (New step, based on local configuration): 
                     * Determine the packet size increase (based on SAs,
                            Padding, outer IP header etc.. )
                     * Get the PMTU
                     * Fragment the packet so that there is no fragmentation is
                            required after doing ciphering and adding SA headers etc..
            - Pass the fragments through outbound SA processing.
            - Send out the secured packets.

       Inbound Processing steps:
            (Assuming that the local configuration requires that all secured packets
             from a particular peer have to be complete packets )
           - (New Step):  Check for Destination IP and Protocol field from IP header.
                If it indicates AH/ESP or Destination IP is local SG IP address and if
                  it is not full packet, discard the packet.
           - Pass the packet through the inbound SA processing.
           - Reassemble the clear packets
           - Check against the inbound policies. 

      Based on above steps, I feel there is no need for IKE negotiation for this.
      Am I missing anything?

Thanks
Srini
Intoto Inc. 
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com
----- Original Message ----- 
From: "Stephen Kent" <kent@bbn.com>
To: <ipsec@lists.tislabs.com>
Sent: Wednesday, June 25, 2003 3:46 PM
Subject: IKE negotiation for fragmentation controls in IPsec


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