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

From: Tero Kivinen <[email-masked]>
Date: Tue, 24 Feb 2004 21:02:56 +0200

There has been some discussion in the IPsec list about how the
fragments should be handled when the port selectors are in use. The
problem is not only fragments but also ICMP, or actually any packet
related to the data going through the SA using port selectors.

Lets take example. The security policy of the company is:

	- Encrypt all SMTP traffic with AES

	- Use only SHA1-AH for web traffic (encryption of web traffic is
	  forbidden, so goverment / company can see what pages you
	  read :-)

If fragments and ICMP messages are put on the separate SA there is no
way to enforce that kind of policy. If you create 2 SAs:

	port 25 => ESP(AES)
	port 80 => AH(SHA1)

all non-first fragments and ICMP messages are dropped, causing
problems. If you add any or opaque rule:

	opaque (or any) => AH(SHA1)

you are not folling the company rule that all SMTP traffic must be
encrypted as non-first fragments will be sent out in clear text. Also
any ICMP message received for the SMTP traffic (packet too big)
contains parts of the SMTP traffic and they will also be sent in clear
text.

If you on the other hand change the AH(SHA1) to ESP(AES) then you will
be encrypting web traffic against the policy. There is no way to
express that kind of setup with current RFC2401bis document. This
means that port selectors cannot really be used before this problem is
solved. The fragmentation issue is solved when using transport mode,
as there cannot be any fragments there. The ICMP issue is not solved
there, as ICMPs might still get wrong protection.

The vendors have solved this problem differently. As I explained
earlier for example our implementation will do partial-reassembly
(i.e. wait for the first-fragment and then forward all fragments to
same SA) to handle fragments. This will put all fragments to the same
SA, providing them the same protection.

For ICMPs you can check the original packet part of the ICMP message
and see if it contains enough information so you can select the proper
SA for it (i.e. if the port numbers are available use them and select
SA based on them). If the ICMP does not have enough data (possible in
IPv4) to contain selectors, then it propably will not have any real
policy sensitive data anyways, thus sending it using any SA is
propably ok.

I think we should add text to rfc2401bis saying that

If port selectors are used then all data associated with data flow
MUST be sent to the SA associated with that stream. This all data
includes normal packets, ICMP messages related to the data flow and
fragments (first and non-first) of packets. Responder MUST accept all
data stream related data from SA associated with that stream."
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Feb 2004 15:00:38 -0500

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

Tero Kivinen <[email-masked]> wrote:
    Tero> solved. The fragmentation issue is solved when using transport mode,
    Tero> as there cannot be any fragments there. The ICMP issue is not solved
    Tero> there, as ICMPs might still get wrong protection.

  Actually, I don't agree.

  There can be fragments there (consider 8K NFS over UDP), but one can 
assume that the transport layer is sufficiently clued in to the IPsec
layer so that the right SA is "cached". 
  In the case of BITS implementation, the BITS can claim a very large
MTU and do fragmentation itself (either before or after ESP/AH).

    Tero> The vendors have solved this problem differently. As I explained
    Tero> earlier for example our implementation will do partial-reassembly
    Tero> (i.e. wait for the first-fragment and then forward all fragments to
    Tero> same SA) to handle fragments. This will put all fragments to the same
    Tero> SA, providing them the same protection.

  Yes, at great cost to queueing buffers, and if a fragment is lost, or
goes via another path, you loose.

    Tero> For ICMPs you can check the original packet part of the ICMP message
    Tero> and see if it contains enough information so you can select
    Tero> the proper SA for it (i.e. if the port numbers are available
    Tero> use them and select SA based on them). If the ICMP does not
    Tero> have enough data (possible in IPv4) to contain selectors, then
    Tero> it propably will not have any real 
    Tero> policy sensitive data anyways, thus sending it using any SA is
    Tero> propably ok.

  I can agree to this.
  It does have profound effects upon tunnel exit policy!

    Tero> I think we should add text to rfc2401bis saying that

    Tero> If port selectors are used then all data associated with data flow
    Tero> MUST be sent to the SA associated with that stream. This all data
    Tero> includes normal packets, ICMP messages related to the data flow and
    Tero> fragments (first and non-first) of packets. Responder MUST accept all
    Tero> data stream related data from SA associated with that stream."

  That's sufficient text for me to understand, but maybe more text is
necessary to properly explain the situation. Perhaps your entire message
provides a good basis.

]       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: Mark Duffy <[email-masked]>
Date: Tue, 24 Feb 2004 17:44:50 -0500

At 09:02 PM 2/24/2004 +0200, Tero Kivinen wrote:
...
>data stream related data from SA associated with that stream."

IMO mandating such behavior, with the implied buffering and state-saving it 
requires, would place a substantial obstacle to the availability of high 
speed, high capacity implementations.

--Mark

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Feb 2004 13:47:24 -0500

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

    >> data stream related data from SA associated with that stream."

    Mark> IMO mandating such behavior, with the implied buffering and
    Mark> state-saving it requires, would place a substantial obstacle
    Mark> to the availability of high speed, high capacity implementations.

  To date, the only significant deployment that I know of that would
even use port-selectors is securing L2TP traffic - and that traffic,
being ultimately a tunnelling protocol which terminates the *UDP* on
two hosts, should not have a problem.
  
  Can you name a situation or application that requires high speed, high
capacity offloading of *per-port* selector granularity?

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Feb 2004 23:04:29 +0200

> layer so that the right SA is "cached". 

The rfc2401bis says that "AH and ESP cannot be applied using transport
mode to IPv4 packets that are fragments.". I.e. in transport mode the
IPsec is applied to full packets, and then the ESP packet is
fragmented. This will solve the problem as while we are doing the SA
selection based on selectors, we always have full packet, not
fragments, thus we can always see the port numbers. 

> MTU and do fragmentation itself (either before or after ESP/AH).

No, all implementations using transport mode MUST do framentation
after ESP/AH. They cannot do it before. 
-- 
[email-masked]

---

From: Mark Duffy <[email-masked]>
Date: Wed, 25 Feb 2004 16:51:33 -0500

At 01:47 PM 2/25/2004 -0500, Michael Richardson wrote:
>   Tero>

IPsec incorporates port selectors and the market looks to IPsec equipment 
vendors to support them.  As a vendor, when I ship a box with support for 
port selectors I have to assume my customers will use them.  It has to work 
and it has to perform.

To respond more directly to your question, any situation that requires 
per-port selector granularity at low speed/capacity may require the same 
selector granularity at high speed/capacity if the data rate grows or if 
IPsec is provided at a place in the network where traffic is more highly 
aggregated.  If no one needs per port granularity, let's remove it from 
2401bis; if it is needed, then in some cases it will be needed with high 
performance.

One reason someone might want to encrypt only certain applications would be 
if IPsec implementations that do not run at wire rate are present in the 
network and therefore encryption has to be rationed to the most sensitive apps.

--Mark

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Feb 2004 19:19:35 -0500

>fragments, thus we can always see the port numbers.

right.

>after ESP/AH. They cannot do it before.

yes, the intent is to fragment after applying IPsec, not before.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Feb 2004 19:25:42 -0500

I'll mention my example, again, as to why port fields are 
appropriate, and add a n ote on performance:

	- by restricting access via an SA to a well known set of 
ports, relative to a specific address or set of addresses, one can 
reduce opportunities for attacks against the hosts or servers. think 
of this as a way to close off access to inappropriate ports, and to 
prevent malicious software that may have taken over a machine from 
being able to use that machine to launch attacks against other 
machines, at least for some classes of attacks. the worm that 
attacked IIS and spear via e-mail from web servers was the example I 
cited earlier.

As for high speed, I concur with Mark.  For my DoD clients, the 
intent is to be able to take advantage of these access control 
facilities over a wide performance range, not to have to tradeoff 
access control features vs. interface speeds.

Steve

---

From: Thor Lancelot Simon <[email-masked]>
Date: Wed, 25 Feb 2004 20:33:59 -0500

> two hosts, should not have a problem.

I use port selectors quite regularly.  I use them, for instance, for
preserving confidentality of syslog logs without encrypting all traffic
between the log source and sink.  Why do I do this?  I do it because
the performance impact of encrypting all the traffic would be unacceptable;
so this is not a "high speed, high capacity" application, perhaps, but it
is not one in which arbitrarily poor performance is acceptable.

Thor

---

From: "Bora Akyol" <[email-masked]>
Date: Wed, 25 Feb 2004 19:00:09 -0800

> attacked IIS and spear via e-mail from web servers was the example I 

It is hard to speak without knowing the complete network architecture
and application, but for what is described here, a firewall
may be more appropriate. 
Much easier on the server since it offloads
filtering from the server to the firewall and current
breed of firewalls are capable of multi gigabit speeds 
for doing access control and filtering and stateful inspection.

Also, the worms and the general classes of zombies want to speak to
the server on a legitimate well-known port. 

If the network architecture
is such that the server wants to talk a subset of the intranet/Internet,
then it is easier to put the server behind a firewall/IDS system. If 
it is intranet alone, and switches are involved, VLANs can also be used,
provided that the routing is set-up correctly.

> access control features vs. interface speeds.

Agreed as long as the features are not frivilous.

--
Bora

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Feb 2004 09:03:20 +0200

Firewalls have their place, but often administrators like to allow all 
decrypted traffic in, believing that because it was encrypted, it is 
more secure.

A very common policy, especially when the firewall and VPN are 
collocated is something like this:
- Allow HTTP and HTTPS to web server + outgoing
- Allow SMTP to SMTP server
- Allow all VPN traffic
- Block everything else

When they're not collocated, you put the firewall closer to the 
Internet than the VPN, because it can filter all those gigabits.  Such 
a firewall can't know what's in the VPN.

This makes sense because VPN traffic is considered "internal" and 
therefore can be anything.  We want someone in the Paris office to be 
able to access all the network resources as if she were in the main 
office.  Of course, now we know better, and would not like to encrypt 
the attacks that the worm that infected her computer is sending out.

This is why VPN has to have its own access control regardless of the 
firewall.  A case could be made for a pure VPN with no port selectors, 
collocated with a dedicated firewall, and that works as long as both 
ends are managed by the same administrator.  If, however, your policy 
is to block NFS, it's a shame that the other side would keep encrypting 
and your side would keep decrypting.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Feb 2004 11:36:55 +0200

> network and therefore encryption has to be rationed to the most

Which means that you really would not like the case where the
non-first fragments of that sensitive apps receive no protection at
all are sent out in clear? Or all ICMP messages sent back quoting the
packet are also sent in clear.

If we ever are going to use tunnel mode IPsec with port selectors in
the cases where different protocols gets different level of encryption
we MUST put all the traffic associated with the flow (normal packets,
first fragments, non-first fragments and ICMP messages) to SA having
at least similar protection.

In your case you propably wouldn't have resources to encrypt all
non-first fragments, thus creating SA for non-first fragments isn't
a solution for you?
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Feb 2004 11:40:03 +0200

> attacked IIS and spear via e-mail from web servers was the example I 

For that kind of cases the separate non-first fragment SA is ok, as
your different policies are either encrypt with XXX or drop, i.e. you
do not have pass through in clear rule.

Immediately when you have pass through in clear rule which sents some
traffic in clear, then you needs to select whether the non-first
fragments are going to use the encrypt with XXX rule or pass through
in clear rule, and if the reason for pass through in clear was
performance issues, then you propably cannot encrypt the non-first
fragments. 

-- 
[email-masked]

---

From: Paul Koning <[email-masked]>
Date: Thu, 26 Feb 2004 09:19:41 -0500

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

 Stephen> I'll mention my example, again, as to why port fields are
 Stephen> appropriate, and add a n ote on performance:

 Stephen> - by restricting access via an SA to a well known set of
 Stephen> ports, relative to a specific address or set of addresses,
 Stephen> one can reduce opportunities for attacks against the hosts
 Stephen> or servers. think of this as a way to close off access to
 Stephen> inappropriate ports, and to prevent malicious software that
 Stephen> may have taken over a machine from being able to use that
 Stephen> machine to launch attacks against other machines, at least
 Stephen> for some classes of attacks. the worm that attacked IIS and
 Stephen> spear via e-mail from web servers was the example I cited
 Stephen> earlier.

 Stephen> As for high speed, I concur with Mark.  For my DoD clients,
 Stephen> the intent is to be able to take advantage of these access
 Stephen> control facilities over a wide performance range, not to
 Stephen> have to tradeoff access control features vs. interface
 Stephen> speeds.

I think Mark argued some in both direction (i.e., port selection as a
workaround for poor crypto performance), but I agree with your view.
If a feature is useful, it should be implementable at good
performance.

My suspicion is that some of the argument is coming from the
commercial marketplace.  IPSec is hard enough to manage that the added
complexity of port selector setup is going to be adopted only when
there is a strong need for it.  In environments where I have worked
(which were commercial networks), that wasn't the case, but I can see
your argument that there are others (such as DoD) where it definitely
is.

So where are we with Tero's previous analysis, which shows that port
selection in the presence of fragmentation can only be done correctly
if you keep cross-fragment state in the SG, i.e., it is expensive at
high speed?

It sounds to me like we have a case of (a) fast and efficient, (b)
support fragments, (c) support port selectors -- pick any TWO.

	paul

---

From: Mark Duffy <[email-masked]>
Date: Thu, 26 Feb 2004 10:20:45 -0500

>If a feature is useful, it should be implementable at good

Sorry, I fear that my earlier statement was unclear.  My concern is mainly 
that the standard be conducive to high-performance implementations.

I raised the notion of a high-speed implementation, some of whose peers are 
low speed implementations, as an example of a case where the low speed 
device could not handle encrypting all the traffic, forcing both the hi and 
low speed devices to go to port selectors in order to apply encryption more 
selectively.

--Mark

---

From: Mark Duffy <[email-masked]>
Date: Thu, 26 Feb 2004 10:13:37 -0500

>packet are also sent in clear.

agreed

>at least similar protection.

I'm not convinced that is a MUST.  One alternative is to leave this choice 
to the administrators.  I.e. if they want to protect the non-initial 
fragments, they do so via SPD rules that match them based on port selectors 
of "any" or "opaque".

>non-first fragments, thus creating SA for non-first fragments isn't

Not so.  I do not see encrypting all fragments as a problem at all.  I see 
mandating that security gateways buffer fragments until such time as they 
can associate them with the initial fragment as a problem (for high 
speed/capacity implementations).  Creating a separate SA for non-initial 
fragments is acceptable to me, but I believe the wg has rejected this.

Like almost everything, this is a compromise between cost, performance, and 
protection.  IMO the status quo from 2401 is ok for fragment 
processing.  AFAIK there have not been widespread complaints about it, 
although others on this list would know much better than I.

Regards,
Mark

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Feb 2004 17:58:07 +0200

> Not so.  I do not see encrypting all fragments as a problem at all.  I see 

I was thinking like the environment like syslog and NFS (both using
UDP), where almost all fragmented packets are NFS, and also causing
most of the traffic, but the sensetive packets are syslog, which might
also get fragmented in some cases. 

> speed/capacity implementations).

The firewalls etc are already doing that on high-speed/capacity
implementations, so it is not impossible. The actual processing power
needed for the processing is low (one hash-table lookup per fragment
per fragmented packet). For non-fragmented packets it does not cause
any performance penalty.

For most of the fragmented packets do come in order, thus the extra
storage requirements can also kept quite low.

> Creating a separate SA for non-initial 

Yes.

> processing.

I think 2401 is silent about the issue, meaning that there will be
non-interoperable implementations, and I do not think that is
acceptable.

> AFAIK there have not been widespread complaints about it, 

I think the port selectors with tunnel mode are not used that much
that people would have noticed. 
-- 
[email-masked]

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 26 Feb 2004 07:54:02 -0800

The point that I was trying to make is that you can offload
filtering on a per port basis from the end node (server in this case)
to the network element that it is connected to. For example,
if the server is connected to a switch or router, you can
install a filter on that port so that the server 
never even sees the traffic. Of course this only works in 
a well-controlled environment where we know precisely
the network information for the nodes in the network
that will communicate with each other. This also allows more
legitimate traffic to utilize the link since the filtered traffic
never even gets on the link to the server.

I do agree with your statements about the other uses
of the firewall.

Thanks

Bora

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Feb 2004 12:35:28 -0500

Paul,

	<SNIP>

>if you keep cross-fragment state in the SG, i.e., it is expensive at

I think I disagreed with that argument in a previous message. I have 
started to write an analysis of these issues, to try to put things in 
better perspective, since our discussion of this topic has gotten 
very detailed and hard to follow at times.
>support fragments, (c) support port selectors -- pick any TWO.

Maybe, but I don't think this is an intrinsic tradeoff.

Steve

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Feb 2004 12:58:04 -0500

Steve and Thor post about situations where there are per-port selectors
between two hosts. That does not present a fragmentation problem - you
do not need to accumulate fragments to make the decision.

The situation where this is necessary is BITS, BITW.

---

From: Thor Lancelot Simon <[email-masked]>
Date: Thu, 26 Feb 2004 13:26:01 -0500

> fragments, they do so via SPD rules that match them based on port selectors 

Please, consider the human-factors issues here!  I think that this is a
terrible idea; inevitably, administrators (who may not reasonably be
expected to even truly grasp the concept of IP fragmentation, nor to know
what information appears in initial and subsequent fragments!) will be 
confused by this concept and will inadvertently fail to secure their
systems, while believing that they have, in fact, secured them.

If we make the rule a MUST, we can emphasize that an implementation MAY
implement it by generating and applying additional "any" or "opaque"
port selectors to catch fragments.  But expecting anyone who wishes to
use IPsec and port selectors to understand such protocol details seems
an incredibly poor choice.

All too often, I think, we design systems by the criterion "Can it be
used in a secure fashion" when what we actually care about, in practice,
is "*Will* it be used in a secure fashion".  Then we go away happy with
ourselves for getting the "technical details" right -- except that we've
done so only by declaring the difficult issue of whether users of only
middling intelligence and knowledge will actually be able to correctly
use what we've specified to be out-of-scope.

This would be a particularly bad place to make that mistake.

---

From: Thor Lancelot Simon <[email-masked]>
Date: Thu, 26 Feb 2004 18:48:46 -0500

> between two hosts. That does not present a fragmentation problem - you

Not necessarily; one end may be a gateway for the ultimate destination of
the traffic.  Think "offload box in front of logging applicance that 
doesn't have IPsec".

I have run into a situation analogous to this, that I can't really describe
in detail, that did in fact require both fragmentation and per-port 
selectors.  Strange but true.

Thor