Subject: Re: IKE negotiation for fragmentation controls in IPsec

From: [email-masked]
Date: Thu, 3 Jul 2003 20:23:39 +0530 (IST)

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Jul 2003 11:19:14 -0400

Ravi,

Thanks for taking the time to restate your comments.

>     might discard packets coming from the intended transmitter.

Almost a correct description. the attacker can flood the receiver 
with non-initial fragments. whether they have the the same IP ID or 
not merely determines how they may be linked together by the 
receiver. also, the attacker is not a "hijacker" per se.

>IP header integrity problems, but they can't do active hijacking as

When you say "can't do active hijacking" do you mean cannot protect 
against this sort of attack? It is not a connection hijacking attack, 
since it does not require access to connection state data.

>the secured packets, if there is any fragmentation on them.

Right, except that this can be done by IPsec end systems as well as 
security gateways.

>the packets. This can't be guaranteed.

right, by asserting the DF bit.

>interface. Then onwards, sending IPSEC router can fragment the packets

yes, if the intermediate systems behave as the RFcs say, this would work.

>   - Routers may not generate ICMP PMTU error messages.

true, which is why I suggested that we might want the IPsec peers to 
engage in a PMTU discovery within a tunnel.

>   - Sending IPSEC router may not get these messages either due to

same solution as above.

>    genuine (generated by intermediate  routers) or spoofed.

irrespective of the proposed fragmentation approach, this attack 
could occur. again, engaging in PMTU discovery within the tunnel 
avoids this problem.

>Due to above problems, depending on ICMP error message would be disastrous

in some instances yes, but not not in all. and, as I noted above 3 
times, use of  PMTU discovery ( within the tunnel) between the IPsec 
peers avoids these concerns.

>  and it is secured way to find out the PATH MTU.

Your solution appears to be an example of what I referred to earlier, 
and reiterated above. I leave it to others to suggest the specific 
mans of doing PMTU discovery, within a tunnel, between two IPsec 
peers. I disagree that the potential problems you cite above make the 
notion infeasible in the absence of such a facility, but I agree that 
it would be preferable to have a form of IPsec-to-IPsec PMTU 
discovery.

Steve