Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems

From: Markku Savela <[email-masked]>
Date: Fri, 5 Mar 2004 13:31:03 +0200

I've been thinking about this a bit more, and my conclusion is:

If
	you want to apply IPSEC on fragments,
and
	you want to use port selectors
then
	There is no way out of it: then at least one of the IPSEC
	implementations MUST buffer ALL fragments before it can
	release any packets to the stacks fragment assembly.

Consider mobile node M communicating with server S behing the security
gateway SG. Assume S fragments some data going towards M, and assume
there is a port specific policy:

  PORT=A, send in clear
  PORT=B, use ESP
  PORT=C, use AH

 M <==== IPSEC ====> SG <---> S

First SG: It has been said it is not acceptable to require SG to do
packet assembly before the IPSEC. If so, then NONE of the selectors
affecting the M <-> SG traffic can have port selectors.

If you have port selectors, you cannot let the packets through until
you see the first fragment. (You don't know whether port is A or
B).

- one argument against SG doing the assembly has been: not all
  fragments may arrive to the same SG. Only one of the SG's sees the
  first fragment. => The other can never do the correct thing and
  fragments are dropped after some timeout or until buffer space runs
  out. Communication fails randomly, exactly the same way as if SG's
  were required to assemble packets.

- because there is no ordering requirements for fragments, the SG must
  be prepared to buffer all fragments. It might as well do packet
  assembly. (Linux sends the first fragment as last!)

Second M: When receiving fragments protected with ESP from SG, the
IPSEC MUST buffer and hold all fragments until it receives the first
fragment. Only then it can check whether the port was A (if port is
not A, the packet must be dropped, even if the ESP transformation
succeeded).

After receiving the first fragment, IPSEC can release the buffered
fragments to the fragment assebly of the IP stack. However, it needs
to remember the port state to be able to check any remaining
fragments. How long it needs to keep this state? Might be just easier
to do the assembly in IPSEC, to be sure.

IPSEC on M must also hold all clear fragments in similar way, until it
knows what IPSEC was to be applied.

Additional consideration: the fragments will have SRC=S, DST=M. IPSEC
must buffer those too, until it knows the port. It cannot let them
through, because someone could send fake fragments to poison the
stacks fragment assembly (and place some attack data into supposedly
secured communication using port B or C).

So, if SG allows IPSEC on fragments, then IPSEC on M needs to be
prepared to buffer full packet. It has to implement same safeguards
against dos attacks as the standard fragment assembly. An attacker may
find some holes by forcing IPSEC to forget some state, and then
sending some tailored fake fragments?

I guess, supporting port selectors and IPSEC on fragments is possible,
but it's lot of work and requires almost full replication of the
fragment assemble within IPSEC. It might be hard to make the thing
actually secure against attacks.

Conclusion: Do not allow port selectors and IPSEC on fragments at same
time. Then, the buffering requirements disappear and it is possible to
check security of each packet and fragment alone.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Mar 2004 12:41:15 -0500

>  M <==== IPSEC ====> SG <---> S

I assume an unstated part of this policy is that the S/D IP addresses 
are all the same, e.g.,  M and S and that the protocol is ANY or the 
same. also, only one port is cited above, so let's assume it is the 
destination port, since that is likely to be well known, whereas the 
source port is likely to be ANY. it's not clear why one would 
construct this policy, in practice, but it is legitimate in the 
abstract.

>affecting the M <-> SG traffic can have port selectors.

more precisely, all of the traffic between M and SG must be treated 
uniformly wrt ports, otherwise non-initial fragments cannot be 
assured the intended treatment. of course, one could also state that 
IF there were a total ordering on security, then affording 
non-initial fragments the most secure treatment would not "under 
protect" any traffic, although it might "over protect" it. so, the 
characterization above is not quite right.

>you see the first fragment. (You don't know whether port is A or

but, as noted above, I could choose to map non-initial fragments to 
the ESP SA, if my concern were to not under protect any traffic.

>   were required to assemble packets.

this paragraph sounded OK until the last sentence, which then seems 
to be comparing the strategy to itself?

>not A, the packet must be dropped, even if the ESP transformation

not clear that this is true.  there is a fragment reassembly overlap 
attack to worry about, but that could be addressed separately. if so, 
then it's not clear that allowing fragments through on an SA is bad, 
if they pass the non-port field selector checks, and if the initial 
fragment, when it arrives, passes all the selector checks.

>to do the assembly in IPSEC, to be sure.

see comment above.

>knows what IPSEC was to be applied.

each IPsec packet carries an SPI that maps it to an indicated SA, and 
the crypto checks will fail if it is mapped to the wrong SA. so the 
statement above is not correct.

>secured communication using port B or C).

see earlier comment.

>sending some tailored fake fragments?

see earlier comment.

>check security of each packet and fragment alone.

I'm almost ready to send my analysis of the various issues, which 
hopefully will help clarify the arguments you have made above, as 
well as others. I agree that there is no magic bullet, but some 
details of your arguments here are not quite right.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Mar 2004 17:59:37 -0500

At 12:16 AM +0200 3/13/04, Markku Savela wrote:
>  > From: Stephen Kent <[email-masked]>
>>From a set of ESP and AH choices, how do you order them? Which ESP is
>better protection over another ESP? Is AH better than ESP without
>authentication?

didn't you note my comment above re IF you could totally order? 
Frankly, I think that in practise this is possible, even though it is 
not in principle.

>Yes, but at least my current implementation rejects packets that are
>protected validly with ESP or AH, but policy calls for no protection
>(or if policy calls for different protection).

that's an interesting "feature." I can understand why you might 
choose to do that, e.g., for fault detection and isolation, but I'm 
not sure it is needed from a security perspective.

>Yes, but it must hold clear packets, until it knows their ports. If it
>lets a non initial clear packets (no SPI, just plain data, it might be
>port=A), through to packet assembly, an attacker can create the
>following assembled packet:
>
>     ================== attack data from clear packets
>   **                   data from real ESP protected packet
>
>If the attack data comes before the ESP packet(s), only the still
>missing parts in the assembly are filled from the protected data (and
>this could be as little as the TCP header -- the first attack content
>can begin at the payload offset 8).
>

in the case of v4, it is possible for a receiver to perform a simple 
sanity check on offset values to reject this sort of attack. since 
the PMTU min for v4 is 576, and since the max header size is 60 
bytes, one could adopt a conservative value such as 128 for the 
offset in a non-initial fragment, and prevent reassembly attacks. 
this check can be applied to all non-initial fragments, whether they 
arrive via an SA or as bypass traffic.

Steve

---

From: Markku Savela <[email-masked]>
Date: Sun, 14 Mar 2004 15:40:40 +0200

Before going into details, just to restate my view of how dealing with
fragments should be stated in the RFC:

1. The IPSEC that is applied to all fragments must be exactly the same
   that would be applied to the same packet when fully assembled.

2. Implementaion can limit support for IPSEC on fragments to policies
   that don't use port selectors.

Above simple and clear, and does not lead to very convoluted
additional specifications.

> Frankly, I think that in practise this is possible, even though it is 

We are supposed to define RFC. There is no room for hand wawing. For
interoperability, you would need write RFC that exactly spells out the
ordering rules, so that each implementation ends up picking the same
one.

> arrive via an SA or as bypass traffic.

This is not acceptable for security. Whatever you choose 60, 128 or
more, it still leaves the hole open. And, eventually, if the payback
is large enough, someone will invent a way to utilize it.

---

From: Markku Savela <[email-masked]>
Date: Sun, 14 Mar 2004 16:01:27 +0200

> not sure it is needed from a security perspective.

This "feature" may have real uses. The following example is a bit
artificial, but it may serve for now:

 A mobile node M is talking to a server S, hosting some database
 application. S is behind a normal Firewall (FW), which the admins
 configure to pass IPSEC traffic to S, knowing it only *accepts* and
 requires the database traffic to be protected.

 M <============ FW ====== DataBaseAccess ===> S

 S is also hosting other services (WEB, SMTP, etc), which are used in
 clear and it is assumed that the FW filters dangerous stuff from
 clear traffic.

 If M gets infected with something, M could quite easily send some
 harmful stuff using the Database IPSEC connection, if S accepts
 anything else that just happens to be validly protected by the IPSEC.

---

From: Markku Savela <[email-masked]>
Date: Sat, 13 Mar 2004 00:16:15 +0200

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Mar 2004 12:10:52 +0200

> arrive via an SA or as bypass traffic.

How about the following attack. The A is the sender behind SGW1, The B
is the receiver behind SGW2. The connection between SGW1 and SGW2 is
protected by the ESP for port 25 and all other traffic is sent in
clear. This means SGW1 and SGW2 will accept non-first fragments in
clear:

A ----- SGW1 <====== M ====> SGW2 ---- B

A sends 2000 byte packet fragmented to 2 pieces p1 and p2, each 1000
bytes.

	A -> B (first fragment, bytes 0-1000)
	A -> B (non-first fragment, bytes 1001-2000)

The SGW1 will encrypt the packets (lets say it uses the rule that all
non-first fragments are sent using the ESP, i.e. receiving identical
protection than the first-fragments).

	SGW1 -> SGW2 (ESP Tunnel A->B, first fragment, bytes 0-1000)
	SGW1 -> SGW2 (ESP Tunnel A->B, non-first fragment, bytes 1001-2000)

Attacker M deletes the second packet from the wire, and replaces it
with clear text packet:

	A -> B (different non-first fragment, bytes 1001-2000)

SGW2 will decrypt the first fragment, and let the second packet go
through in clear (the policy said that there is only ESP protection
for port 25, so the non-first framgment is not against the policy).

B will receive 2 fragments

	A -> B (first fragment, bytes 0-1000)
	A -> B (different non-first fragment, bytes 1001-2000)

where the first one is really from the other end the second one was
inserted in by the attacker. There are 2 ways for the SGW2 to protect
against this attack:

	1) Require ESP protection for all non-first fragment
	2) Do partial or full reassembly for all fragments going
	   through (not only those protected by ESP) and verify that
	   the packets match the policy.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Mar 2004 12:42:10 +0200

> additional specifications.

I agree. The above is simple and it covers the most common cases (i.e.
if you do not want to do the first option, then simply do not support
fragments and port selectors). Also if your setup is such that option
1 is not possible (for example load balancing between multiple
security gateways) do not allow port selectors or do not allow
fragments. 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Mar 2004 11:36:06 -0500

>	   the packets match the policy.

the proposal to carry all non-initial fragments on an SA between two 
sites would require that a receiver reject all plaintext fragments 
that appear to be from a site with which IPsec protection was 
employed. that seems to be consistent with #1 above.  #2 would work, 
in the contexts where there is only one SG serving a site.

Steve

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Mar 2004 11:04:07 -0500

>  M <============ FW ====== DataBaseAccess ===> S

the diagram is missing a SG, between the FW and S, right?

>  anything else that just happens to be validly protected by the IPSEC.

OK, this is a better explanation. the concern is that if we carry 
traffic other than what was intended to travel via the SA, then even 
if we are offering it better protection en route, we may violate the 
access control scheme at the receiver, if the receiver is configured 
to pass non-IPsec traffic via one path, and IPsec via another.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Mar 2004 11:30:07 -0500

>    that would be applied to the same packet when fully assembled.

I agree that this would be ideal, but it would not be awful, from a 
communication security perspective, if we applied "better" protection 
to fragments. Yes, I realize that the protection suites might be a 
lattice vs. totally ordered, in principle, but in practice I think 
this is not like to be true.

>    that don't use port selectors.

We are in complete agreement on this point.

>ordering rules, so that each implementation ends up picking the same

Well, since fragment reassembly will not always be possible at an 
intermediate point, and that was your proposal, I don't think it is 
"hand waving" to suggest an artificially imposed total ordering vs. 
assuming that all fragments will arrive at a specific SG.

>is large enough, someone will invent a way to utilize it.

What hole? if I choose 128 bytes that I know definitively that no 
non-initial fragment can overwrite port fields, because the max IP 
header length is bounded and well short of this size.

Steve

---

From: Paul Koning <[email-masked]>
Date: Mon, 15 Mar 2004 13:38:28 -0500

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> At 3:40 PM +0200 3/14/04, Markku Savela wrote:
 >> Before going into details, just to restate my view of how dealing
 >> with fragments should be stated in the RFC:
 >> 
 >> 1. The IPSEC that is applied to all fragments must be exactly the
 >> same that would be applied to the same packet when fully
 >> assembled.

 Stephen> I agree that this would be ideal, but it would not be awful,
 Stephen> from a communication security perspective, if we applied
 Stephen> "better" protection to fragments.

True from a comsec point of view.  Not necessarily true from a legal
compliance point of view, if you're subject to regulations that
restrict the use of certain algorithms for certain traffic.  I believe
Tero made that point some time ago.

     paul

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Mar 2004 15:05:05 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:
    >> 2. Implementaion can limit support for IPSEC on fragments to
    >> policies that don't use port selectors.
    >> 

    Tero> I agree. The above is simple and it covers the most common
    Tero> cases (i.e.  if you do not want to do the first option, then
    Tero> simply do not support fragments and port selectors). Also if
    Tero> your setup is such that option 1 is not possible (for example
    Tero> load balancing between multiple security gateways) do not
    Tero> allow port selectors or do not allow fragments. --

  I concur.

  The requirements:
      1) port-selectors
      2) support fragments
      3) do gateway or BITW

  are conflicting. Pick two.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Mar 2004 12:25:18 +0200

>   are conflicting. Pick two.

Actually no. Change the 3rd requirement to:

	3) do multipath gateway or BITW solution, where fragments of a
           packet can go out from different SGW.

You can do gateways and BITWs without problems, but you cannot do that
if you want to support cases where you have multiple SGWs and
fragments of the packet can be split between those SGWs.

How often have you seen that scenario?

There are ways to get even that working, either make sure the all
fragments end up to the same SGW (easy in the load-balancing case,
simply make sure the balancer uses algorithm that will put all
fragments to the same SGW every time, as there are other benefits for
that those boxes usually try to do that anyways (i.e. they try to keep
one TCP/IP stream to use the same path to get TCP/IP work better).

If you cannot have that, then you would need communication between the
boxes about the initial fragments. Again I think that we are now
talking about the 0.01% case thus we can safely ignore it, and say
that do whatever you like.

So to rephrase that statement:

If IPSEC policy decision (AH, ESP, bypass, drop) is applied to
fragments where policy has tunnel mode port selectors, then all
fragments must have exactly the same processing that would be applied
to the same packet when fully assembled. 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Mar 2004 18:16:46 -0500

-----BEGIN PGP SIGNED MESSAGE-----

    >> are conflicting. Pick two.

    Tero> Actually no. Change the 3rd requirement to:

    Tero> 3) do multipath gateway or BITW solution, where fragments of a
    Tero> packet can go out from different SGW.

  I'm assuming that assembling fragments at either end for checking is
too expensive for high speed boxes that won't wish to queue.
  That's what we were told on the list.

    Tero> You can do gateways and BITWs without problems, but you cannot
    Tero> do that if you want to support cases where you have multiple
    Tero> SGWs and fragments of the packet can be split between those SGWs.

  Right, I agree. But aren't the gateways/BITWs going to assemble the
fragments in this case?

    Tero> How often have you seen that scenario?

  I have yet to see it. All redundant situations I've seen have a warm
spare, ready to take over. No load balancing.

    Tero> So to rephrase that statement:

    Tero> If IPSEC policy decision (AH, ESP, bypass, drop) is applied to
    Tero> fragments where policy has tunnel mode port selectors, then all
    Tero> fragments must have exactly the same processing that would be applied
    Tero> to the same packet when fully assembled. 

  I agree.

- --

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 17 Mar 2004 12:12:08 +0200

> too expensive for high speed boxes that won't wish to queue.

I don't really belive that. I think there are boxes out there that can
handle 100 MBit/s or even 1 Gbit/s NFS traffic without problems. All
the packets there are fragments (8kB or similar UDP packets), thus
they can reassembly there without problems, and propably even without
any hardware help.

I do not belive it is that hard to do the partial reassembly even in
faster links, especially as it will need special hardware to do the
IPsec encryption at those speeds, and adding partial reassembly for
those few packets that really are fragmented shouldn't be problem. 

>   That's what we were told on the list.

Ok, I will tell you otherwise, do you belive me :-)

Anyways, if your box is too slow to handle the traffic at full speed,
when there are couple of fragments around, then you either advertise
it with lower speed (not very likely), or you simply ignore the
problem, and say that we do not support fragments with port selectors. 

>   Right, I agree. But aren't the gateways/BITWs going to assemble the

They need to do partial reassembly, meaning that in normal case
(fragments in order, no dropped packets), the cost is 4+4+2+4 (src ip,
dst ip, id, used spi) bytes per fragment for few seconds. If you are
using 1GBit/s link and sending 8 kB packets fragmented to 6 pieces,
that will mean 16k packet/s. If we assume the total memory needed per
fragment is 32 bytes, and you want to keep them full ttl seconds (say
64 seconds), then you will need 32 MB of buffers to store that
information.

If only 1% of packets are fragments, and they all miss first fragment
for some reason, then you need 66 MB of buffer space to store the
non-first fragments for 64 seconds.

Does anybody have any statistics how much of the packets in the net
are fragmented?

-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Mar 2004 11:37:34 -0500

-----BEGIN PGP SIGNED MESSAGE-----

    Tero> Michael Richardson writes:
    >> I'm assuming that assembling fragments at either end for checking
    >> is too expensive for high speed boxes that won't wish to queue.

    Tero> I don't really belive that. I think there are boxes out there

  At 1Gb/s, I believe it.
  At 10Gb/s, it is presently hard. Not impossible, but hard.
  Once 10Gb/s is solved, it will be hard at 40Gb/s (assuming OC768 is
the next step). 

  But, if in the functional design specification, we say:

    1) cope with fragments
    2) have port-selectors
    3) be BITW/gateway

  pick two, is the *requirement*, then vendors can build the 40Gb/s box
tomorrow that can't do port-selectors, and the one that can, the
following week.

    Tero> that can handle 100 MBit/s or even 1 Gbit/s NFS traffic
    Tero> without problems. All the packets there are fragments (8kB or

  There is a reason that NFS appliance want to move to TCP rather than
UDP (and NFSv4 supports that). There are lots of TCP offload engines out
there, and probably some that can do IPsec as well. With PMTU they can
optimize the packet size, and they don't have to deal with fragments.

  Further, if they in-board IPsec, then they aren't a gateway/BITW, so
they can make sure that every fragment gets the same treatment.

    Tero> Does anybody have any statistics how much of the packets in
    Tero> the net are fragmented?

  It varries by which part of the network you look at.
  (And I recall a discussion like this at my desk with you, TMO, TATU in
fall of 1997...)

  The backbone doesn't have a lot of UDP traffic, except for DNS, which
is kept artificially below the fragmentation limit. Enterprise networks
that might be extended over IPsec VPNs are a different matter. SANs that
get extended might have further different properties.

- --

---

From: Mark Duffy <[email-masked]>
Date: Wed, 17 Mar 2004 11:10:13 -0500

>64 seconds), then you will need 32 MB of buffers to store that

Ah, but if the fragments do not arrive in order, or some are missing, the 
situation is different, much different.  Even though this might not be 
naturally common, it happens sometimes.  And, it might be common as a 
malicious attack.  Devices would have to be built to handle it.

>Does anybody have any statistics how much of the packets in the net

I believe the 1% number is very low for IPsec packets, due to the frequency 
of adding ESP to 1500 byte cleartext packets and then transmitting the ESP 
packets over ethernet.  And, the typical % of fragmented packets is 
probably irrelevant anyway; malicious attacks are a more serious consideration.

I stand by the statement that requiring logical "reassembly" is anathema to 
high-speed implementations.

--Mark

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Mar 2004 14:26:24 -0500

You may be able to find some data at http://www.caida.org.

Steve Bellovin and I are not convinced that general numbers are really 
going to provide much insight.  NFS, for example, is a prime user of 
fragments, but one will not see much NFS traffic on the wide-area 
Internet.  However, a VPN might be a very different story.

Russ

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Mar 2004 22:43:53 +0200

Mark Duffy writes:
> At 11:44 AM 3/18/2004 +0200, Tero Kivinen wrote:
> > > packets over ethernet.
> >That fragmentation happens after IPsec, thus it not concern here. We
> >are now talking about the packets arriving to the SGW which are
> >already fragmented at that point. If PMTU etc works perfectly there
> >should not ever be any TCP packets that are fragmented, and most of
> >the UDP traffic is for small packets, with only exception of the NFS
> >etc.
> 
> That fragmentation can happen before IPsec, and is highly likely to in 

I do not think ESP inside ESP it that common case, even in high-speed
implementations. If the fragmentation is because of the ESP header
being added, then it happens INSIDE SGW, thus the SGW will have the
complete packet to base the policy decisions on. Actually SGW has
already done the policy decision because it knows it is going to apply
ESP on the packet.

I repeat, that fragmentation is not in question here.

> And PMTU discovery does not work perfectly.

I read one of those articles
(http://www.caida.org/outreach/papers/2002/Frag/) found from the
http://www.caida.org/, and it said the fragmentation is about 0.2-0.8
% of the packets and around 0.6%-1.6% of bytes in the core network.

89% of the fragmented packets arrived in order and ware complete. 7.8%
arrived in the reverse order, and 1.6% had some out of order
fragments. That leaves 1.6% of fragmented packets in state which could
not be reassembled (and which might be missing the first fragment).

They also assumed 15 seconds for reassembly timeout, I used 64 seconds
in my previous calculations, thus my calculations ware 4 times too
big. 

There was also very little TCP fragmentation (1.6% of bytes in
fragmented packets, meaning around 0.03% of total traffic), most of
the fragments was because UDP (72% of fragmented bytes), ICMP (12% of
fragmented bytes) etc.

Those numbers will be different when checking the traffic inside the
VPN, but I do not think the number of fragments are going to change
that much, unless you run NFS over UDP over the VPN.

Those numbers can be used to calculate the good sizes for the
reassembly queues etc, so that it works fine under normal load.

> I agree with your statement here in a general sense and indeed that is how 
> many things work.  But here there are several options on the table that 
> would allow the protocol to be *more* resistant to attack, such that 
> legitimate fragments do not suffer as a result of such an attack.  (The 
> options I mean are the approaches that do not call for an IPsec 
> implementation to "reassemble" fragmented packets.)

Yes, if we drop all fragments, then legitimate fragments does not even
notice if there is attack going on or not :-)

Note, that if there is any attacks using fragments, then that attack
is coming from the inside of the VPN, thus you might have other
problems in that case too.

> I can accept an approach where a SG can do either port-selectors or 
> fragments.

I agree that. We shouldn't make the fragmentation processing with port
selectors MUST, you can simply not support port-selectors or not
support fragments, but if you implement then both, I think we want it
to have identical security properties than normal traffic. 

> However, I would prefer to do both, without reassembly.  This 
> could be accomplished by several means that have been discussed on this 
> list including having a separate SA for fragments, or allowing non-initial 
> fragments to be sent under a different policy entry than other packets 
> (e.g. one with port selectors of "opaque".)

I.e. you propose using different policy for parts of the traffic. I
consider that a security hole. 
-- 
[email-masked]

---

From: Mark Duffy <[email-masked]>
Date: Thu, 18 Mar 2004 17:59:52 -0500

>already done the policy decision because it knows it is going to apply

I was not talking about ESP in ESP.  I was talking about this:

. SG receives large (e.g. 1500 B) plaintext packet.
. SG policy says encrypt.
. Path MTU from SG to remote SG is known to be 1500 B.
. SG does "red-side" fragmentation (of plaintext pkt) to avoid need to 
reassemble at remote SG
. SG encrypts each fragment.

. Yes, SG has the complete packet and *could* use the port selectors to 
find the policy to use for all fragments.  But since the receiver (assuming 
it does not do the pseudo-reassemble) will evaluate the SPD for non-initial 
fragments with opaque ports, the sender should do so too.  That way the 
sender and receiver are treating the non-initial fragments the same.  I 
believe this is the behavior RFC 2401 calls for in sect. 4.4.2.

My point here is still that the percentage of packets at the receiving SG 
that are fragments may be substantial, since the fragmentation is a direct 
result of the IPsec overhead.

--Mark

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Mar 2004 01:54:57 +0200

> . SG policy says encrypt.

And at that point SG policy also says, that use this SA for the
traffic I assume?

> . SG encrypts each fragment.

using the SA selected earlier, which means that each fragment will be
sent inside the same SA as I proposed.

Do you propose that SG should do second policy lookup at that point,
to find out how to send the fragments?

> believe this is the behavior RFC 2401 calls for in sect. 4.4.2.

Wasn't the red-side fragmentation forbidden in the RFC2401? I think it
was added only in rfc2401bis, or do I remember incorrectly? At least
we have issue 88 that seems to change the rfc2401bis so that it allows
red-side fragmentation.

Actually red-side fragmentation seems to be only usefull if the
responder does not care about checking the non-first fragments. If the
responder still wants to verify that all fragments match the policy,
then red-side fragmentation does not help. 

> result of the IPsec overhead.

The better option would be implement proper path MTU discovery in the
SG, i.e. send packet too big with suitable smaller mtu to the sender. 
-- 
[email-masked]

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 18 Mar 2004 17:30:37 -0800

Mark

Can you please qualify what you mean by high speed and also how many
tunnels at that speed?

Do you mean 1Gbps, 10 Gbps or 100 Gbps? How many tunnels at that speed
and packet size.

Once we define what "high speed" means, hopefully we can get a good
understanding of
what are the issues that are detrimental to the high speed
implementation.

Thanks

Bora

---

From: Mark Duffy <[email-masked]>
Date: Thu, 18 Mar 2004 10:00:15 -0500

That fragmentation can happen before IPsec, and is highly likely to in 
high-speed implementations.  And PMTU discovery does not work perfectly.

> > And, the typical % of fragmented packets is
>The typical % of fragmented packets is important, as we need to make
>sure the protocol works fine in normal case. If there is an attacker,
>we simply need to make sure the protocol can still work, and it does
>not crash or run out of memory, but the performance does not have to
>be optimal (i.e. we might want to drop some of the non-first fragments
>in those cases, just like the normal host reassembly will do
>currently).

>And you still claim that we do need port-selectors and fragments in
>those high-speed implementations?

fragments.  However, I would prefer to do both, without reassembly.  This 

--Mark

---

From: Mark Duffy <[email-masked]>
Date: Fri, 19 Mar 2004 00:35:52 -0500

Hi Bora,

I don't want to put numbers to it because I don't think they matter.  I 
would simply characterize a "high speed" implementation as one pushing the 
current limits of the technology at any point in time.

For any speed and price range, it will always be "easier" (more feasible, 
cheaper, faster for the price, shorter time to market, etc. -- pick your 
metric) to build a device that treats each packet (or fragment) on its own 
than to build a device that treats packets based on other packets that have 
been or will be seen.

A requirement to collect fragments in order to evaluate port selector 
policy will serve to reduce the availabilty of high speed implementations.

Mark

---

From: Mark Duffy <[email-masked]>
Date: Fri, 19 Mar 2004 00:16:11 -0500

>sent inside the same SA as I proposed.

not necessarily the same SA, see below ("Yes, SG has...")

>to find out how to send the fragments?

it could do another policy lookup for non-initial fragments.  That depends 
on how we (2401bis) end up deciding that fragments are to be handled.

>we have issue 88 that seems to change the rfc2401bis so that it allows

I believe 2401 prohibited red-side fragmentation.  But the prohibition was 
a bit vacuous in the sense that from further downstream, red-side 
fragmentation by a SG is indistinguishable from fragmentation of the 
plaintext packets upstream of the SG.  2401bis serves to legitimize the 
practice.

>then red-side fragmentation does not help.

I disagree.  Red side frag by the sender helps if the receiver checks the 
subsequent fragments on their own individual merits (with opaque port 
selectors).  And it even helps if the receiver will "reassemble" the 
fragments so it can determine the port selectors to use for non-initial 
fragments -- because as you yourself pointed out earlier in this thread for 
in-order fragments the receiver would only need to save the (src addr, dest 
addr, ident, SPI), not buffer nor actually reassemble the fragments.

>SG, i.e. send packet too big with suitable smaller mtu to the sender.

That's great when it works, but often it doesn't e.g. ICMPs are dropped by 
firewalls, hosts don't do it right, etc.  Also AFAIK if the originator of 
the datagrams does not set the DF bit, the network is obliged to fragment, 
not discard and send icmp dest unreachable.

Tero, we've gotten a bit sidetracked today but I think we are basically 
coming from different positions on the fundamental question of whether a SG 
that wants to support fragments must either disallow port selectors or do 
reassembly, or is there a 3rd option to give the non-initial fragments 
different protection than the initial one.  I'd like to wait and see 
Steve's memo on this which it sounds like we will see soon.

--Mark

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 18 Mar 2004 22:19:02 -0800

Hi

While I agree with your general statement, if the question is whether
the RFC2401
(bis) is implementable at "very high speed" then the answer is yes. I
was in a development team for such a high speed implementation during
the last couple of years (this stated here not to claim knowledge over
ALL implementations but
as to describe my personal experience).

Can we build even faster hardware and cheaper with a basic subset of
traffic selectors then don't require 5 tuple lookups. My answer
to that is also yes again based on my experience. Heck even if we
allowed port ranges but limited them to masks, this would still result
in efficiencies in hardware based lookups, but will not solve the hw
problem.

While adding port ranges, etc is great and is applicable in 
a percentage of applications (example. secure only logging traffic
between two hosts, thanks to someone on this list for bringing this up),
if one can build 10 Gbps hardware with this specification, it is likely
possible to build 40 Gbps hardware with a much concise set of features.

With Ipv6 only hosts are allowed to fragment and PMTU is required so
this issue is unique to IPv4, and if all 2401bis hosts+SGs are required
to be compliant with path MTU discovery, then 
is there still a problem?  In your example, PMTU discovery should take
care of the reception of a 1500 byte ethernet frame and then running out
of space. Instead, the SG should sent the correct ICMP message which
should make the host reduce the MTU automatically (at least in this
ideal world :-) 

I guess we almost need a "capability negotiation" as part of IKE
and then define subset of capabilities for different types of
hosts/gateways.
This way, you can do both. Kind of like BGP capabilities.

Regards,

Bora

> -----Original Message-----
> From: Mark Duffy [mailto:[email-masked]] 
> Sent: Thursday, March 18, 2004 9:36 PM
> To: Bora Akyol; 'Tero Kivinen'
> Cc: 'Michael Richardson'; [email-masked]
> Subject: RE: Traffic selectors, fragments, ICMP messages and 
> security policy problems 
> 
> 
> Hi Bora,
> 
> >understanding of what are the issues that are detrimental to 
> the high 
> >speed implementation.
> >
> >Thanks
> >
> >Bora
>