Subject: IKE negotiation for fragmentation controls in IPsec

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Jun 2003 18:46:06 -0400

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Jun 2003 14:33:18 +0300

> the initiator of its intent re the companion (reverse) SA, if 

Would it be enough to have
----------------------------------------------------------------------
        FRAGMENTATION_BEFORE_IPSEC		24587

            By sending this notification the sender announces that it
            can process packets which are fragmented before being
            encapsulated to the IPSec packets, i.e the recipient of
            this notification can send such packets and assume that
            the other end can process them. If this notification
            payload is sent by both ends (i.e both ends support this
            feature), then both ends MUST NOT send packets fragmented
            after the IPsec encapsulation and SHOULD (configurable by
            local policy) reject incoming packets which are fragmented
            after IPsec encapsulation (i.e as the other end must not
            send them it was either some other router which fragmented
            it or it was an attack). 
----------------------------------------------------------------------

in the section 3.10.1 Notify Message Types - STATUS TYPES?

> to pass on fragments, not reassemble them (in the case of a SG).

The normal processing of those packets on the firewalls is to put
those non-first fragments to (small) queue and when the first fragment
then arrives, then do the policy check and forward the first fragment
and all additional fragments forward (and also mark the fragment id so
that all future fragments to same packet will get through for some
time). Also care should be taken that the any fragments do not
overwrite anything from the first fragment that was used for the
policy checks (i.e the port numbers are not overwritten by later
non-first fragment).

I am not sure that we should allow sending of the non-first fragments
to IPsec SAs using the port selectors unless we have validated that
the port numbers match the policy. There is no need to do the actual
reassembly, simply queuing the non-first framents coming before the
first fragment and adding entry that will allow rest of the fragments
to the packet to get through for some time is enough. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Henry Spencer <[email-masked]>
Date: Thu, 26 Jun 2003 12:35:18 -0400 (EDT)

On Wed, 25 Jun 2003, Stephen Kent wrote:
> for this SA, because none will be sent by this transmitter...

There is a problem here, in that fragmentation is not entirely under the
control of the transmitter.  Intervening gateways may fragment the
encrypted packets.  This situation can change dynamically, as routing
changes, and the transmitter can't count on getting feedback about it,
because many firewalls apparently block ICMP Fragmentation Required
messages. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Thu, 26 Jun 2003 10:36:36 -0700

Hi,
   
Imagine this scenario:

   -----------SecurityGW1----------Router1----Router2------------SecurityGW2---

As I understand from the description, once SG1 and SG2 negotiate
and come to understanding, then SG2 can drop fragmented secured
packets. But the routers in between can fragment the packets. 
To avoid this situation, SG1 has to set the DF bit and PMTU
processing should be MUST in this case.  Is it right to assume that
all core and edge routers/firewalls in Internet and enterprise support passing
the ICMP error messages? I keep hearing that most (may be some) firewalls
can be explicitly configured to discard ICMP error messages. 

Thanks
Srini

Intoto Inc. 
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Thu, 26 Jun 2003 10:59:13 -0700

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.

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 26 Jun 2003 20:36:11 -0400

> I keep hearing that most (may be some) firewalls can be explicitly
> configured to discard ICMP error messages.

It's worse than that.  Very many firewalls in the as-built internet
are configured to drop all ICMP packets.

I recommend attempting to visit a broad sampling of web sites (using
http and https) from a client which:

 1) advertises a TCP MSS of 1460 (corresponding to a 1500 byte MTU)

 2) has a <1500-byte MTU on the path due to tunnels, PPPoE, or other
    bottleneck links.

You will most likely discover that many of these sites will not
successfully talk to you or mysteriously hang mid-transaction.

I believe there's an alternate path mtu discovery proposal in the
works (there was a "plpmtud" BOF last IETF; I haven't followed what
happened to it).

						- Bill

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Jun 2003 10:46:27 -0400

>because many firewalls apparently block ICMP Fragmentation Required

Well, I was assuming (but I should have said so explicitly) that the 
transmitter, if it negotiated this option, would set the DF bit, 
having selected a suitable PMTU. You are right that route changes can 
cause the PMTU to change, which would require adaptation by the 
transmitter.  I also acknowledge the problem posed by firewalls that 
block ICMP.  However, in many common cases, one will encounter the 
IPsec implementation at the firewall, not behind it, and thus this 
would be less of a problem.

So, given the residual problems we know about, the question still 
stands whether we want to include the option, with the understanding 
that the transmitter is the one who will ultimately have to take 
responsibility for making this work.  The receiver's job is simple, 
as all it needs to do, if it wishes, is to reject post-encapsulation 
fragments.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Jun 2003 11:31:26 -0400

>   of the peers can be exchanged using Vendor ID attributes.

One might choose to do this on an SA basis, because TCP deals well 
with PMTU-imposed packet size restrictions, but UDP does not.  So, by 
allowing per-SA negotiation for this we can accommodate different 
protocol capabilities re PMTU.

>              - Reassemble the packet (Packet coming from trusted network).

NO. there is no implied reassembly by the transmitter.

I won't comment on the rest of your message since this assumption was 
not right and it may influence later parts of your message.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Jun 2003 11:27:55 -0400

>can be explicitly configured to discard ICMP error messages.

Any statement of the form "all X in the Internet do Y" is very likely 
to be false :-)

In many (most?) current deployments, IPsec is at the perimeter of an 
organizational enclave and thus is either parallel to a firewall or 
is part of the same system as a firewall.  if an IPsec system is 
behind a firewall, then one encounters problems with getting IPsec 
traffic through, in many cases, just as one might have trouble 
getting ICMP traffic through.

Ultimately, the best solution, from a pragmatic and security 
perspective, is likely to be a means of determine PMTU that rides 
over IPsec, e.g., within a tunnel, and thus avoids the question of 
whether any intermediate routers or firewalls play the PMTU discovery 
game.  It would be possible to do that today, sending ICMP traffic 
between two IPsec implementations, encapsulated in a tunnel, if the 
SPDs at each end allow it, but we ought to consider a more formal 
specification of a mechanism going forward.

Steve

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Fri, 27 Jun 2003 15:51:15 -0700

> not right and it may influence later parts of your message.
 
I am curious on why this is not needed.
IPSEC SPD supports selector space with not only IP addresses, but also
with TCP/UDP port values. If some sort of reassembling is not done(either wait
for all fragments OR maintain reassembly state with IP ID, SIP, DIP), there
is possibility of mapping the non-first fragments of the packets to the wrong
security policy. Only first fragment has TCP/UDP information and it chooses
the correct security policy. 

Complete IP reassembling helps in finding out obvious DoS attacks and
helps in reducing  the number of encapsulated IPSEC packets.

Srini

---

From: Francis Dupont <[email-masked]>
Date: Mon, 30 Jun 2003 17:20:48 +0200

In your previous mail you wrote:

=> Two comments:
 - IPv6 fragmentation is end to end, i.e., no intervening router
   may fragment the packets. So this issue exists only for IPv4.
 - current IPv4 path MTU discovery doesn't work. I use an ESP tunnel
   between two KAME boxes (one at home, one in labs) over PPPoE and
   it was a real nightmare to fix (KAME IPsec doesn't handle MTU,
   a lot of sites are over paranoid firewalls, a router of my ISP
   drops large packets when it should fragment them, etc).
So this is a can of worms and IMHO we should test proposed solutions
in the real world before engrave something in the stone.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 30 Jun 2003 17:34:01 +0200

=> intermediate boxes should not even try to reassemble packets.
There are many reasons, for instance some fragments can follow a
different path, or this increases the latency, etc.

   IPSEC SPD supports selector space with not only IP addresses, but also
   with TCP/UDP port values.

=> a security gateway can get fragments so it doesn't support selectors
which can be in the second fragment. IMHO SPD on a SG should be constrained
to only IP addresses (IPv6 is a bit different, first the flow label is
always available, second some extension headers are on purpose
in all fragments).

   If some sort of reassembling is not done(either wait
   for all fragments OR maintain reassembly state with IP ID, SIP, DIP), there
   is possibility of mapping the non-first fragments of the packets to the
   wrong security policy. Only first fragment has TCP/UDP information

=> this is not true, the TCP/UDP information can be in the second fragment.

   and it chooses the correct security policy. 

=> this is the job of a firewall, not the job of a SG.

Regards

PS: it seems I have some trouble with the list server: I apologize
if you mbox has already blown with messages developing these arguments.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 30 Jun 2003 19:25:40 +0300

Stephen Kent writes:
> This does not really convey the right semantics.  What we want is for 
> the sender of the payload to say "I will NOT send any post-IPsec 
> encapsulation fragments." Any receiver MUST be able to accommodate 
> fragments that occur prior to IPsec encapsulation, because these 
> fragments could have been generated by a host before arriving at the 
> IPsec device. The goal of the proposed payload is to inform the 
> receiver so that the receiver can mark an SAD entry to reject all 
> fragments that arrive (prior to IPsec encalsulation).

Ok, so:

----------------------------------------------------------------------
         NO_FRAGMENTED_IPSEC_PACKETS		24587

             By sending this notification the sender announces that it
	     will always fragment packets before encapsulating them to
	     the IPsec packets, i.e the recipient of this notification
	     MAY drop all fragmented IPSec packets, as they are not
	     generated by the other end.
----------------------------------------------------------------------

would be better?

> We agree that there is no need for a receiver to reassemble. However, 
> so long as we prevent fragments with too-short offsets from 
> traversing an SA, I'm not sure much damage (other than a form of DoS 
> on an SA where the Source and Dest IP addresses are already 
> acceptable) will be done if we allow fragments to pass before we see 
> the initial fragment at the receiver.  That avoids the need for any 
> buffering at the receiver, which it self might create DoS concerns.

The most common fragmented packets that can cause damage is when the
attacker attacks the reassembly code of the final recipient, i.e send
packets whose offset + size > 65536, or suitable packets filling up
the reassembly queue in the receipient and causing denial of service
attack.

There are some attacks where you generate for example fragments each
having 8 bytes of data, and leave gap between each of those. This
means that the recipient might have 4000 of those in its reassembly
queue. If this queue is linear sorted list, and every time you send
the fragment the code searches the suitable place where to insert the
fragment it means 4000/2 list operations per fragment, which will take
considerable cpu-time (yes, I have seen this attack to work, and the
machine was completely trashed by just very few such packets).

This does not need the first fragment at all.

Also another attacks are done by sending lots of non-first fragments
to the recipient and again filling up the queues.

I think the reason than most of the firewalls (and I assume also
security gateways) want to check the fragments is that they want to do
some sanity check them before letting them through, i.e some of them
simply drop all fragments that are too small (unless they are the last
ones) and also they might even check that there is no overlapping
areas in the fragments (might be attack, and should not happen in
normal case) etc. Making sure that the reassembly code in the sgw can
handle all attack cases is easier than trying to fix all the hosts
behind them.

I agree, that we propably could also allow letting the non-first
fragments through, but I think we need also some text of possible
attacks and checks that should be done in those cases. And of course a
good explanation about the risks of letting fragments with too small
offsets through.

I.e I want to see the final text before I can say more about this
issue...
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Markku Savela <[email-masked]>
Date: Mon, 30 Jun 2003 22:13:08 +0300

> From: Tero Kivinen <[email-masked]>

Sorry about butting in. I have been on vacation and a bit of lost
here. Are we now planning on MAJOR change in IPSEC, where you APPLY
IPSEC to fragments?

Otherwise above change makes no sense at all.

Previously SG had to assemble the packets before doing IPSEC. So, I
take above is to make SG's job easier? (Or IPSEC below IP-stack
implementations). But, then it should limit selectors only to
addresses, to keep things simple (e.g. if you allow IPSEC on
fragments, don't even think of making it mandatory to support port
selectors -- that's same as requiring reassembly anyway).

For bump in the stack implementations, there should be no need for
IPSEC:ing fragments, ever.

Previously, fragmentation DOS attacks had no relevance to the
IPSEC. Now, if fragments can be IPSEC:ed, there might be some consern.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2003 15:32:10 -0400

>Otherwise above change makes no sense at all.

IPsec has always been applied to fragments that arrive at an SG, or 
in the case of IPv6, that are emitted by a host internally.

>Previously SG had to assemble the packets before doing IPSEC.

could you remind me of where we said that in 2401?

>So, I

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2003 15:52:36 -0400

>>  fragments that arrive (prior to IPsec encalsulation).

"... encapsulating them with IPsec ..." and fix the spelling of IPsec :-)

>the reassembly queue in the receipient and causing denial of service

like I said, DoS concerns.

>This does not need the first fragment at all.

agreed

>to the recipient and again filling up the queues.

remember, we have this problem already if the SA does not use port 
field selectors. the relaxation I suggested merely allows the sender 
to say that they want to send fragments despite the presence of the 
port field selectors.

>handle all attack cases is easier than trying to fix all the hosts

I agree in principle.  But, unlike the generic firewall case, here we 
know the source of the traffic and we do have some recourse for the 
DoS attacks, i.e., shutting down the SA and having a chat with the 
admin at the other end, if we are willing to accept that sort of 
remedial action.

>I.e I want to see the final text before I can say more about this

Fair.

Steve

---

From: Markku Savela <[email-masked]>
Date: Tue, 1 Jul 2003 00:39:39 +0300

> From: Stephen Kent <[email-masked]>

> could you remind me of where we said that in 2401?

Hmm.. I could have sworn it was said somewhere. But, I guess my mind
is just playing tricks, by deducing that by implication: if you must
implement port (or transport protocol in Ipv6) selector, you must
assemble full packet anyway (at at least potentially buffer all
fragments, because there have been systems that send fragments in
reverse order even!)

Concerning the change text...

>   generated by the other end.

The last sentence may cause black hole. The sender cannot guarantee
that some router on the way does not fragment IPSec packet, unless the
above also implies that sender must set DF bit on IPv4 header? Right?

Naturally, for IPv6 this is not the issue.

As for DOS attacks with fragments, I don't see anything that relates
directly to IPsec. All fragmentation attacks are just fragmentation
attacts, regardless whether IPsec is present or not.

The only issue that could be mentioned is: if framents are IPseced, a
firewall doing something with fragments doesn't see them as fragments
(both IPv4 and IPv6).

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2003 17:51:25 -0400

>fragments, because there have been systems that send fragments in

In fairness, there are several cases.  For transport mode, yes, we do 
require a BITS or BITW implementation to do reassembly. But for 
tunnel mode we don't, hence it is not a requirement for SGs.  I 
should have been more precise in my comments.

>above also implies that sender must set DF bit on IPv4 header? Right?

right. that is part of what the sender must do too.

>Naturally, for IPv6 this is not the issue.

right again.

>attacts, regardless whether IPsec is present or not.

if we fragment after IPsec encapsulation, then ANYONE can send 
fragments that could cause the IPsec implementation trouble, and 
maybe adversely affect all subscribers behind the implementation. 
This is especially bad for an SG.

if we fragment before encapsulation (but after doing the SPD checks), 
then we expose the stack behind the implementation to attacks, but 
only from the authorized peers they have elected to communicate with, 
as per the SPD entry for S/D IP addresses and protocol.

Steve

---

From: Markku Savela <[email-masked]>
Date: Tue, 1 Jul 2003 01:16:32 +0300

> fragments that could cause the IPsec implementation trouble,

You probably don't mean "trouble", such as crashing. Injecting a fake
"fragment" would just make IPsec on the assembled packet fail the
checks. This is the trouble you mean?

Yes, that is a danger, fragmenting after IPsec makes it easier for the
attacker to cause packets to be lost (dropped by IPsec).

> then we expose the stack behind the implementation to attacks, but

Ugh.. fragmenting before IPsec would be somewhat akward with "bump in
stack" implementation (at least for me it would be rather major
architectural change). However, as implementation never fragments TCP
packets, only issue is with large UDP packets. Oh well..