Re: IKE negotiation for fragmentation controls in IPsec

[ravivsn@roc.co.in]

Look like, as thoughts came to my mind, I have typed it.
Sorry for that..  Here it is.

You are trying to solve following problem:
    A person with malicious intention can confuse the receiver's IP
    reassembly logic by sending fragments with same IP identification field.
    IP reassembly logic can't distinguish packets coming from intended
    transmitter OR coming from hijacker and thereby IP reassembly logic
    might discard packets coming from the intended transmitter.

Certainly, this is good thing to do. Today firewalls, can detect many of
IP header integrity problems, but they can't do active hijacking as
described above.

Your suggestion to this problem is: IPSEC routers fragment the packets
before applying IPSEC security, so that there is no fragmentation required
on secured packets. On the receiving side, IPSEC router can discard
the secured packets, if there is any fragmentation on them.

Above solution works well, if intermediate routers don't fragment
the packets. This can't be guaranteed.

With existing technology, IPSEC routers can force the intermediate routers
to send ICMP PMTU message, by setting the DF bit on outgoing secured
packets.  If Intermediate router finds that the packet size is more than the
interface MTU, it sends the ICMP PMTU message with MTU size of its
interface. Then onwards, sending IPSEC router can fragment the packets
based on this.

I think,above solution has problems:
  - Routers may not generate ICMP PMTU error messages.
  - Sending IPSEC router may not get these messages either due to
    Firewalls in between.
  - Hijacker also can send ICMP PMTU messages and make the MTU to such a
   small value and it can overload the sender. Sending IPSEC router
   does not have any way to find out whether the ICMP error message is
   genuine (generated by intermediate  routers) or spoofed.

Due to above problems, depending on ICMP error message would be disastrous
 and will not work.

One solution which I could think of
    ( It is not optimum solution, but might work):
  IPSEC transmitter should find out the path MTU using Security association.
  Small lightweight protocol, that determines the Path MTU on continuous
  basis. It could be client and server protocol. Client starts sending
  message with 1500 bytes first with DF bit on. If server receives it, it
  sends ACK
  message. If Client does not receive ACK message for three attempts, then
  it should reduce the message size by 64 bytes and tries the same procedure
  again, until ACK is received. This message size can be considered as
  path MTU.

 In this, there is no assumption of intermediate routers/firewalls behavior
 and it is secured way to find out the PATH MTU.

Regards
Ravi