Re: IKE negotiation for fragmentation controls in IPsec

[Stephen Kent <kent@bbn.com>]

Ravi,

Thanks for taking the time to restate your comments.

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

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.

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

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.

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

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

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

right, by asserting the DF bit.

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

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

>
>I think,above solution has problems:
>   - 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
>     Firewalls in between.

same solution as above.

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

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
>  and will not work.

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.

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

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