Subject: [IPsec] Motivation for ESP-null marking

From: Yaron Sheffer <[email-masked]>
Date: Wed, 06 Aug 2008 16:35:29 +0300

Hi,

Although we have a charter item on special marking of ESP packets with 
null encryption, there have been some questions raised about the 
rationale for doing this. No matter which solution we choose, this is a 
very fundamental protocol addition (layer 3, directly handled by 
hardware), so Paul and I would like to have one more round of discussion 
on whether this is really needed.

Let us ignore the details of the solution proposals for a while (1 
protocol number vs. 2, ESP wrapper vs. keeping the existing ESP header), 
and consider whether there is a need to have any solution at all for 
this problem:

    * What is the security/threat environment that we are dealing with?
      In other words, what is the security policy for which we want an
      efficient enforcement?
    * Are there alternative ways to detect unencrypted traffic in the
      existing ESP, e.g. heuristics? Are they easy to implement in
      software or in hardware? How significant is the problem of false
      positives?
    * For a "reasonable security policy" (as above) can we provide a
      hardware-only enforcement solution with current technology, or do
      we have to send every packet into software (general CPU or network
      processor)? And if software is involved, does it make the entire
      "efficient to implement in hardware" discussion irrelevant?

When you respond, please describe your personal or your company's 
experience with hardware-based packet processing, for extra points :-)

Thanks,

    Yaron

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 6 Aug 2008 11:47:04 -0500

>      In other words, what is the security policy for which we want an

Clearly the security policy would be: use confidentiality protection.

Of course, there's no way to ensure that the SAs' keys haven't be made
public or otherwise shared with interested third parties.  That's what
makes ESP-null marking seem silly -- it's like the reverse of the
"secure" bit gag, an "insecure" bit which tells you nothing about the
security of packets that don't have that bit set.

One might argue that middle box enforcement of confidentiality
protection policies adds some value where you can trust end nodes not to
reveal their secret keys.  But in such an environment you might as well
assume that end nodes have the correct policies too, and so there's no
need to enforce those policies in middle boxes.

>      software or in hardware? How significant is the problem of false

I suspect there'd be enough header content, even in transport mode ESP
payloads, that simple heuristics are workable.  Whether such heuristics
are easy to implement in hardware is another story.

Of course, this still does nothing for the case where the end nodes are
sharing their secret keys with third parties.

>      "efficient to implement in hardware" discussion irrelevant?

An "insecure" bit is trivial to check in hardware.  It's also useless
(see above).

> experience with hardware-based packet processing, for extra points :-)

Sun has quite a bit of experience with hardware-based packet processing
(think of the Neptune NIC); I don't have any direct experience with it
-- that doesn't stop me from telling you my opinion of the value of this
"insecure" bit as the hardware aspects aren't relevant to that issue.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 6 Aug 2008 11:56:51 -0500

I should add that without ESP-null middle box filtering that requires
the use of ESP is, indeed, filtering on the basis of an "insecure" bit
since there's no way for the middle box to ensure that IPsec and ESP are
actually being used correctly.  And yet I wouldn't advocate that middle
boxes don't filter on the basis of whether or not ESP is being used.

Therefore I suppose that checking for an ESP-null marker is no different
than checking for ESP in the first place.  And that if one would not
oppose the latter then one should not oppose the former.

Nico

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Aug 2008 23:07:31 +0300

On Aug 6, 2008, at 7:47 PM, Nicolas Williams wrote:

<snip>
> security of packets that don't have that bit set.

I don't think this was the author's intention. The two parties could  
of course use AES and post their secret keys to Wikipedia, but if the  
policy is to drop marked ESP-NULL packets, all the parties really have  
to do, is to negotiate ESP-NULL and use the old ESP with no markings.

I think the policy is "don't send encrypted stuff out, because I (the  
middlebox) want to deep inspect all traffic". That would translate to  
dropping all ESP-non-NULL traffic. Otherwise, I agree that an  
"insecure" bit is ridiculous. A "deep inspection welcome" bit is less  
so.

But you can't just pass the packet marked as ESP-NULL - you need to  
really make sure they're not running encrypted stuff, and also you  
need to deep inspect. So the question is whether it really adds any  
processing time to make sure a packet is really not encrypted, given  
that you're running all kinds of other filtering.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Aug 2008 23:12:11 +0300

Thinking it over, it doesn't have to be very deep inspection. It could  
be as simple as "drop all FTP, even if it's tunneled"

On Aug 6, 2008, at 11:07 PM, Yoav Nir wrote:

> of course use AES and post their secret keys to Wikipedia, but if  
> the policy is to drop marked ESP-NULL packets, all the parties  
> really have to do, is to negotiate ESP-NULL and use the old ESP with  
> no markings.
>
> I think the policy is "don't send encrypted stuff out, because I  
> (the middlebox) want to deep inspect all traffic". That would  
> translate to dropping all ESP-non-NULL traffic. Otherwise, I agree  
> that an "insecure" bit is ridiculous. A "deep inspection welcome"  
> bit is less so.
>

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 6 Aug 2008 17:08:08 -0700

Hi Yaron, All,
Some comments inline...

Thanks, 
- Ken

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
Of
>Yaron Sheffer
>Sent: Wednesday, August 06, 2008 6:35 AM
>To: [email-masked]
>Subject: [IPsec] Motivation for ESP-null marking
>
>
>Hi,
>
>
[Ken] I am surprised that there are questions being raised about this
goal, given that its presence in the charter indicates that it's a
worthy one. Are there any strong arguments for reversing that consensus?

>      In other words, what is the security policy for which we want an
[Ken] This solution is targeting an environment where intermediary
devices would like to inspect the packet on route and optionally make
access control decisions based on local policy and the results of the
packet inspection. Some examples of policies are: Dropping packets with
certain characteristics (based on protocol / port or deeper inspection).
E.g. Do not allow any encrypted data; Allow encrypted data to only these
systems; Do not allow FTP/TFTP traffic between these endpoints, but
allow for others. The list goes on...basically any 5-tuple firewall
rules + additional enforcement based on payload examination and
intrusion prevention.
In order to make these decisions, the packets needs to be inspected and
the current IPsec ESP spec does not allow you to infer if the packet is
encrypted or in the clear (ESP-NULL).

This has been a deployment barrier to using IPsec in Enterprise
environments as IT departments would like to employ E2E security, but
not at the cost of circumventing existing network monitoring /
diagnostics tools. This charter item is looking at removing this barrier
and allowing IPsec to be employed in these environments. 

>      software or in hardware? How significant is the problem of false
[Ken] Heuristics will never be free of false positives, all we can do is
play the probability game and reduce false positives to a very small
value. False positives have a high cost as they can lead to incorrectly
applying policies (e.g. because we falsely determine that an ESP
encrypted packet is ESP-NULL) and can cause almost
impossible-to-diagnose network glitches (e.g. which packet(s) out of the
millions being processed actually generated the false positives).

Heuristics can also become very complex with numerous rules to cater for
different protocols / payloads (including catering for the protocols of
tomorrow). As for employing heuristics in SW Vs. HW, this is really
implementation dependent. Having said that, in the multi-core
environment of today, numerous vendors employ IO acceleration techniques
in HW for fast data movement between the HW (e.g. NIC) and SW
components. These techniques are needed to ensure that data is moved
directly to the correct CPU/NPU core, which is the consumer of that
data. These decisions are typically based on stream identifiers (e.g.
5-tuples in the packet) to ensure full load-balancing capabilities
between the multiple cores. In order to make these decisions, the HW
needs to extract this data and hence any heuristics would need to run in
the HW. Implementing heuristics in HW is very costly, compared with our
proposed approach of an ESP wrapper.  

>      "efficient to implement in hardware" discussion irrelevant?

[Ken] Please see above - HW demuxing is needed.

>experience with hardware-based packet processing, for extra points :-)

How many points and what is the value? :-)
Perhaps we can discuss this offline...

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 6 Aug 2008 17:13:13 -0700

Thanks Yoav - you hit the nail on the head and I do like the 'deep
inspection welcome' bit instead of the 'insecure bit', as the packet is
still integrity protected.

As for the processing time overhead, please see my other response on
this thread where the proposed solution is deterministic and 'HW
friendly', as well as motivation for doing this in HW.

Thanks, 
- Ken

Of
>Yoav Nir
>Sent: Wednesday, August 06, 2008 1:08 PM
>To: Nicolas Williams
>Cc: [email-masked]
>Subject: Re: [IPsec] Motivation for ESP-null marking
>
>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 6 Aug 2008 21:20:50 -0500

> still integrity protected.

Yes, that makes more sense.  Middle boxes will still need to apply some
heuristics to decide whether such packets are indeed in the clear, but
that will be easy if the policies it applies require inspecting tunneled
next protocol headers.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Aug 2008 14:52:59 +0300

> worthy one. Are there any strong arguments for reversing that consensus?

Standard track mechanism does not need to be protocol change, it can
be also documentation of how to do the thing with heuristic checks.

I think there is no point of doing this on the protocol level as to
deploy it requires changes to ALL IPsec endpoints. If we document and
implement heuristic checks those can be done directly on the
middleboxes, thus requiring only upgrading those small amount of
boxes, not all the network endnodes. This means that the heuristic
methods are deployable within one year from now or even faster
(especially as they do not require interoperability testing or actual
protocol specifications, thus vendors can start implementing them
NOW).

If we now define extension for IKEv2 to allow this (and I hope nobody
is even going to suggest implementing anything to the now already
obsoleted IKEv1 protocol), it will most likely take about year to
finish the protocol document, and then vendors will start implementing
it thus first implementations would most likely be end of 2009 or
beginning of 2010, and then you need to wait for couple of more years
before most of the operating systems support that new extension (i.e.
around 2012-2014). After most of the operating systems start
supporting it, then you still need to wait 3-5 years to make sure all
of the old devices in the network has been updated to support that
latest operating system, before you can make sure that all network
endnodes support this. So in best you could be able to use it in 2012
or so and in reality you would have to wait until 2015-2018...

In the mean time you most likely still want to have solution that will
work NOW, not in 10 years time, thus middle box vendors will implement
the heuristic methods anyways regardless whether we define protocol
for it or not.

This protocol change is again something that will disrupt deployment
of IPsec, i.e. there will always be implementations which do not
support it, and which then cannot be used in some environments. It can
also cause delays in deployment, when enterprices decide that they
wait until they have this protocol ready for all platforms before even
starting to use IPsec.

I would much more like to see IPsec to spread out as fast as possible,
and not waste time for something that can be done in the middle boxes
quite easily with just heuristic checks. 

> encrypted or in the clear (ESP-NULL).

I do not see any reason why both ESP-NULL and encrypted ESP shuld be
allowed between 2 end nodes, i.e. I see only reason where there is
either only ESP-NULL allowed or only any type of ESP allowed (i.e.
encrypted or not, but not inspected at all).

If both ESP-NULL and encrypted ESP is allowed between pair of end
nodes, then anybody who wants to bybass middlebox checks will simply
use encrypted ESP. If someone disagrees with this, I would like him to
explain me why this is needed, and what kind of policy is used for
that.

Using that premisis, that means that for every single ESP packet
coming in to the device, we know immediately after matching the
IP-addresses in the header to the policy whether ESP-NULL is mandated,
or not. If it is not mandated, then packet is passed forward, as there
is no point of inspecting encrypted packets.

If ESP-NULL is mandated, then you simply assume packet is ESP-NULL and
inspect the packet, and if it looks like encrypted ESP (or garbage)
then you do the normal thing firewalls do, i.e drop it. 

> and allowing IPsec to be employed in these environments. 

It will be really, really expensive and time consuming to update all
end nodes in the network to allow them to use this new protocol
extension. It is much faster and cheaper to update those network
monitoring / diagnostic tools with ones that support heuristic checks.

Also if IT department has full control of the end node
configurations (which they must have if they assume they can update
all end node implementations at will) they can simply mandate them to
use one specific ESP-NULL algorithim, i.e. simply say that no other
ESP-NULL algoritm is allowed except AUTH_HMAC_SHA1_96, and that will
remove all heuristic checks needed. This kind of solution is
implementatable in extremely fast timeframe.

> value.

Depends what you mean with false positives.

If you mean that encrypted ESP packet will pass the ESP-NULL
heuristics and pass the firewall, then the probability of that will go
very quickly way below the 96 bits offered by the AUTH_HMAC_SHA1_96 if
you do any kind of deep inspection. Also as there should not be any
encrypted ESP packets between the nodes who by policy should use
ESP-NULL, if they happen to negotiate encrypted ESP for some reason,
they might get 15 packets through for every million packets they try
to send, even when if you only check TCP checksum (16 bits). If yo do
TCP flow checking (source and destination ports, sequence number,
acknowledgement number) you do check close to the 96 bits worth of
data already. For that to match from the random encrypted packet to
some ESP-NULL flow is about the same probability that the randomly
generated packet will pass your AUTH_HMAC_SHA1_96 check.

> False positives have a high cost as they can lead to incorrectly

No. For the end nodes point of view the encrypted ESP connection
between the nodes is broken regardless whether there is one packet
every 2^16 or 2^96 going through it. They will see that as broken link
and user who misconfigured boths ends (note, that it is not enough for
one user to misconfigure his node, but both ends must be misconfigured
to allow enctypted ESP) to allow encrypted ESP will notice this and
fix his configuration.

For attacker doing the same thing, he can continue using encrypted
packets but as 99.99999999999999999999999999% of his packets will get
dropped by simple tcp flow checking his attacks will be detected very
quickly.

Note, that there cannot be valid encrypted ESP packet dropped because
of these heuristic checks, as encrypted ESP packets are not inspected,
but they are passed by (when allowed by policy). 

> proposed approach of an ESP wrapper.  

No. None of those heuristics needs to really run on the HW. Only the
SPI checking needs to run on the HW. I.e. the hardware must understand
that it is matching six tuple if IP header protocol is ESP, i.e.
source ip/destination ip/spi/protocol number inside ESP-NULL/source
port inside ESP-NULL/destination port inside ESP-NULL. Immediately
when it sees the SPI it will know where the protocol number and actual
header information is. If the SPI is uknown, then HW throws the packet
to slowpath, which will do the heuristics, calculate the offsets for
the actual protocol information and for the protocol number, and store
that information along with the 6-tuple to the packet matching
hardware and resume the packet.

In almost all the hardware I have seen (our own SafeXcel-5160, Octeon)
the flow creation is always done on the softpath anyways. For Intel
Tolapai chips can do it both ways (i.e. either from the microcode
controlled fastpath, or from the softpath).

Doing flow creation on the fastpath is so complicated, that I expect
all chips doing so are running some kind of microcode inside the chip
doing the actual flow creation, thus chip vendors can most likely add
support for IPsec SPI flow creation there in firmware updates when it
is widely requested.

Note, that if we change the ESP any way (i.e. define new protocol
number, or add new bytes or whatever), all the existing hardware will
need at minimum firmare updates anyways. In some cases like in Octeon
it would be just writing new code, in some cases like in SafeXcel-5160
or Tolapai chips it would require the chip vendor to update the
microcode.

So from hardware point of view it does not really matter what we do
(i.e. heuristics or ESP-NULL marker) the firmware needs to be updated.

In some chip architectures firmware require smaller updates for the
heuristics method, as heuristics can be done on the softpath, as the
full ESP-NULL marker processing needs to be done on the firmware (none
of that processing can be pushed to the showpath). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec