Subject: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

From: "Dragan Grebovich" <[email-masked]>
Date: Mon, 2 Feb 2009 22:01:26 -0500

Hi Tero
I reviewed your heuristics draft and I believe it is interesting and
doable, however:

1) I believe the actual implementation would require more code than
current front-end hardware allows.  The hardware we work with have a
limited space for that much heuristics code.   Our preference is to find
a quick direct match (in a few instructions max).  We would have to
respin hardware to allow your heuristics implementation.  This might not
be implementable today, as hardware respins are costly and take
relatively long.

2) On low-end products, e.g. Access (aka Edge) it is unlikely that
today's and even tomorrow's implementations will have stateful DPI
implemented; these devices have low target COGS and usually do not have
simple packet filters and stateless firewalls and signature-based DPI
and IDS/IPS.  It is unlikely that this would be the potential
implementation target for heuristics, as the cost/price would go up.

3) High-end products, e.g. Data Center front-ends, would allow a
heuristics implementation; it may have a stateful firewall and/or
IDS/IPS and other DPI capabilities, however this class of devices is
migrating towards virtualized platforms (major vendors are moving in
that direction), and they would be terminating tens or even hundreds of
thousands of SAs.  

4) Even if these high-end devices have implementations running on
multicores, everyone is struggling to provide low latency and high
throughput, squeezing the last possible bit through of the pipe.
Keeping state until one finds that there is a match or not may introduce
unwanted latency and create large memory consumption (multiply
everything by e.g. 100K Sas) which we may not be able to afford.

5) On these High-end appliances, there is a definite need for
load-balancing between flows.  That means the amount of the required
memory space will be at least 2x or 3x more, and also there is need for
additional CPU and I/O overhead to maintain two or more loanbalancers in
sync.

6) Another problem I see is that more traffic today is carried on UDP,
and those are inherently difficult to track as "flows".  One must keep a
significant portion of traffic to determine ESP vs. ESP-NULL.  Years ago
it was rare and mostly used for implementations such as SNMP, but these
days new applications ar ecoming out (e.g. Bittorrent-over-UDP).
SIP-over-UDP is another such implementation that may cause problems, if
heuristics are implemented in intermediate devices.

7) There will be stateful appliances in the future, but stateless
devices will remain in the future;  these will not be able to perform
heuristics as defined in the heuristics draft.  They may have to be
redeployed to other places in the network, causing forklift replacements

8) Even by your own conclusion, heuristics are not 100% accurate.  There
are some "false positives" and some "false negatives" situations.

In summary, I find your draft to be interesting, and I am looking
forward to seeing it progress on Informational track.  I believe also,
that a deterministic approach would be quicker and easier.  I suggest
the "visibility" draft remain on the WG Standards track as it is more
implementable.

_____________________________
Dragan Grebovich, CISSP
Nortel Networks
Enterprise Communication Solutions
Product Development Data Systems
Strategy and Architecture - Security
(978) 288-8069
Billerica, MA 01821 U.S.A

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Feb 2009 12:15:37 +0200

Dragan Grebovich wrote:

Hi Tero
I reviewed your heuristics draft and I believe it is interesting and doable, however:

1) I believe the actual implementation would require more code than current front-end hardware allows.  The hardware we work with have a limited space for that much heuristics code.   Our preference is to find a quick direct match (in a few instructions max).  We would have to respin hardware to allow your heuristics implementation.  This might not be implementable today, as hardware respins are costly and take relatively long.

2) On low-end products, e.g. Access (aka Edge) it is unlikely that today's and even tomorrow's implementations will have stateful DPI implemented; these devices have low target COGS and usually do not have simple packet filters and stateless firewalls and signature-based DPI and IDS/IPS.  It is unlikely that this would be the potential implementation target for heuristics, as the cost/price would go up.

3) High-end products, e.g. Data Center front-ends, would allow a heuristics implementation; it may have a stateful firewall and/or IDS/IPS and other DPI capabilities, however this class of devices is migrating towards virtualized platforms (major vendors are moving in that direction), and they would be terminating tens or even hundreds of thousands of SAs.

4) Even if these high-end devices have implementations running on multicores, everyone is struggling to provide low latency and high throughput, squeezing the last possible bit through of the pipe.  Keeping state until one finds that there is a match or not may introduce unwanted latency and create large memory consumption (multiply everything by e.g. 100K Sas) which we may not be able to afford.

5) On these High-end appliances, there is a definite need for load-balancing between flows.  That means the amount of the required memory space will be at least 2x or 3x more, and also there is need for additional CPU and I/O overhead to maintain two or more loanbalancers in sync.

6) Another problem I see is that more traffic today is carried on UDP, and those are inherently difficult to track as "flows".  One must keep a significant portion of traffic to determine ESP vs. ESP-NULL.  Years ago it was rare and mostly used for implementations such as SNMP, but these days new applications ar ecoming out (e.g. Bittorrent-over-UDP).  SIP-over-UDP is another such implementation that may cause problems, if heuristics are implemented in intermediate devices.

7) There will be stateful appliances in the future, but stateless devices will remain in the future;  these will not be able to perform heuristics as defined in the heuristics draft.  They may have to be redeployed to other places in the network, causing forklift replacements

8) Even by your own conclusion, heuristics are not 100% accurate.  There are some "false positives" and some "false negatives" situations.

In summary, I find your draft to be interesting, and I am looking forward to seeing it progress on Informational track.  I believe also, that a deterministic approach would be quicker and easier.  I suggest the "visibility" draft remain on the WG Standards track as it is more implementable.

In previous discussions we've reached the conclusion that traffic visibility matters only for a subset of the traffic, where your policy says two things:

 1.  You intend to do some kind of inspection on the protected payload (could be as shallow as checking ports or as deep as scanning the transported files for malware)
 2.  You don't allow any ESP that isn't NULL, because then you won't be able to inspect it. ESP non-NULL is dropped.

Given that this is the kind of policy we're enforcing, you cannot really escape doing some inspection on the payload - you intend to do this anyway. Even if the packet was "tagged" as the visibility draft suggests, you would still need to verify that the ESP is indeed NULL - you can't rely on a tag.

So IMO it doesn't really matter how weak or powerful the edge device is, it has to be powerful enough to inspect all ESP-NULL packets if it is to implement such a policy. If it's not powerful enough, then it can't enforce such a policy, and it doesn't really have to decide whether or not the ESP algorithm is NULL or not. In that case it doesn't have to implement any heuristics. Stateless devices are such a case. They shouldn't care whether or not the traffic is ESP-NULL or not.

As for heuristics not being 100% accurate, that is correct, but the chances can be made arbitrarily small, and small enough that we are willing to live with it.

Yoav

Email secured by Check Point

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Feb 2009 15:12:23 +0200

> be implementable today, as hardware respins are costly and take

In normal cases, I would expect that heuristics are not run on the
hardware, only the SPI cache is run there (i.e. the Appendix A.1 part
of the operations). This kind of processing is already run on the
firewalls, deep inspection devices and so on, usually per TCP flow
basis. Adding that to be run on per IPsec SA basis should be very
small addition to the front-end hardware.

Are you saying that even that is too complicated?

> implementation target for heuristics, as the cost/price would go up.

If they do not have "simple packet filters and stateless firewalls and
signature-based DPI and IDS/IPS", then they do not need heuristics at
all, as there is no need to differentiate the ESP vs ESP-NULL.

Heuristics solution do not require any changes to those low-end
product. On the other hand the new protocol number for ESP most likely
will require changes to those devices, as they need to be sure to pass
that protocol number also.

> that direction), and they would be terminating tens or even hundreds of

Heuristics are not needed on the devices which are terminating IPsec
SAs. Devices terminating IPsec SAs already know all IPsec SA state,
thus they do not need heuristics.

Heuristics is only needed on devices which do all the following:

1) Do want to some kind of deep inspection on the ESP-NULL packets.

2) Are on the path of the IPsec flow, but not participating in the
   IPsec SA (i.e. is not a node where IPsec SA terminates).

Note, that usually one IPsec SA has tens or hundreds of the TCP or UDP
flows inside, thus for each entry added to the SPI cache, the TCP or
UDP caches require much more. This means that high-end producsts need
to have memory for storing hundreds of thousands or even millions of
TCP/UDP flows anyways, and adding some for IPsec SA flows does not
significantly increase the number (in the worst case scenario, where
each IPsec SA has exactly one TCP flow inside, it might double the
number of flows needed to be stored). 

> everything by e.g. 100K Sas) which we may not be able to afford.

During normal operation there is no increased latency or slow
throughput, as the used IPsec SAs are already in the SPI flow cache,
and the parameters are fetched from there.

Even if there is hundreds of tousands of SAs, the rate of new IPsec
SAs created per second is very low. I.e. if IPsec SAs has lifetime of
1 hour, that means that every second we create on average of ~30 new
IPsec SA flows to keep up 100 000 IPsec SA flows running. Thus the
actual heuristics processing only requires to process around that
amount of flows.

Of course during the monday morning problem the rate will be higher,
but even so the heuristics is cheaper than the Diffie-Hellman required
to actually create those IPsec SAs, so even low powered CPU should be
able to easily to run heuristics on thousands or tens of thousands
packets per second.

After the heuristics is run then the processing is moved to the actual
fast path which only inspects the IPsec SPI flow cache and the src/dst
addresses and SPI number found from the packet.

> additional CPU and I/O overhead to maintain two or more loanbalancers in

Heuristics can be run separetely on each devices without any problems,
but the deep inspection usually cannot be run separetely. Thus I do
not think deep inspection engines will be load balanced so that same
flow can end up in multiple devices. Usually the load balancing there
is done based on the IP addresses or similar, where they can guarantee
that each flow ends to one specific node of the load balancing
cluster. 

> heuristics are implemented in intermediate devices.

As you said the UDP is hard to keep track, but heuristics does not
NEED to keep track of UDP flows, it just need to find enough
information in the beginning of the flow, to create the flow
information for the ESP-NULL flow. After that it does not care what
kind of UDP traffic go inside. The deep inspection device inspecting
the traffic inside ESP-NULL flow, still need to keep track of UDP
flows, but heuristics has already been done in that case.

> redeployed to other places in the network, causing forklift replacements

Normal steteless devices do not need to do heuristics, as they do not
do deep inspection or things that require looking in to the ESP-NULL
packets.

> are some "false positives" and some "false negatives" situations.

Not sure what you mean by "false positives" or "false negatives", but
as explained in the draft it can only make errors that valid ESP
packet is detected as being ESP-NULL packet. It will never detect
valid ESP-NULL packet as ESP packet.

> the "visibility" draft remain on the WG Standards track as it is more

It might be easier, but it definately will not be quickier. Heuristics
can also be implemented regardless of IKEv1 or IKEv2. Modifying the
ESP will be IKEv2 only, thus it will require end nodes to start using
that too. It seems that quite a lot of devices are still using already
obsoleted IKEv1 still, even when IKEv2 has been out for 3 years... 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dragan Grebovich" <[email-masked]>
Date: Tue, 3 Feb 2009 08:13:23 -0500

Yoav
 
I apologize for not being clearer earlier.  I was not suggesting any
new/different policy enforcement.  
 
I believe/agree that traffic visibility will matter only to a subset of
traffic, but that is enforced at each appliance level, or on a more
granular (per interface) level.  Not all devices have to be capable of
doing it, however if they are tasked to do it, they have to be able to
scale and perform transparently and quickly.  Therefore, if heuristics
are turned on, all traffic will be subject to inspection (heuristic or
deterministic), and then resource consumption matter.
 
I definitely concur that not all ESP traffic will be NULL, but I believe
your statement actually supports my point.  When a packet hits a
decision point, the following has to be determined asap:
 
   1) Is the packet terminated here or am I to forward it?  Until now,
forwarded packets were always forwarded and no action was performed on
the content.  Now we may want to turn on a policy to inspect packet
content which is not terminated here.
   2) Can I do anything with it" (has it cleartext or IPSEC payload)?
If cleartext - it is trivial ...
   3) Is it AH or ESP?  This is quick and trivial too ...
   4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I
can't do anything with it - pass (preferrably) or drop (if policy
insists, but I doubt someone would prevent IPSEC, you never know).  
 
IMHO for each packet we have to perform the four steps.  It is the
implementation-specific choice whether it is deterministic or heuristic
inspection to make a call.  I need to make a call if it would take a few
instructions or a chunk of code, potentially with some % of
false-positives or false negatives.   Again, I agree with you it may be
"tweaked" to be close to 0%, however each additional discrimination
requires more code, more cpu and more time to execute (latency).  I am
concerned that on large (high-end) devices this may take an unacceptably
large toll.
 
Dragan

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoav Nir
Sent: Tuesday, February 03, 2009 5:16 AM
To: Grebovich, Dragan (BL60:SF00); [email-masked]
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote:

	Hi Tero 
	I reviewed your heuristics draft and I believe it is interesting
and doable, however: 

	1) I believe the actual implementation would require more code
than current front-end hardware allows.  The hardware we work with have
a limited space for that much heuristics code.   Our preference is to
find a quick direct match (in a few instructions max).  We would have to
respin hardware to allow your heuristics implementation.  This might not
be implementable today, as hardware respins are costly and take
relatively long.

	2) On low-end products, e.g. Access (aka Edge) it is unlikely
that today's and even tomorrow's implementations will have stateful DPI
implemented; these devices have low target COGS and usually do not have
simple packet filters and stateless firewalls and signature-based DPI
and IDS/IPS.  It is unlikely that this would be the potential
implementation target for heuristics, as the cost/price would go up.

	4) Even if these high-end devices have implementations running
on multicores, everyone is struggling to provide low latency and high
throughput, squeezing the last possible bit through of the pipe.
Keeping state until one finds that there is a match or not may introduce
unwanted latency and create large memory consumption (multiply
everything by e.g. 100K Sas) which we may not be able to afford.

	6) Another problem I see is that more traffic today is carried
on UDP, and those are inherently difficult to track as "flows".  One
must keep a significant portion of traffic to determine ESP vs.
ESP-NULL.  Years ago it was rare and mostly used for implementations
such as SNMP, but these days new applications ar ecoming out (e.g.
Bittorrent-over-UDP).  SIP-over-UDP is another such implementation that
may cause problems, if heuristics are implemented in intermediate
devices.

	7) There will be stateful appliances in the future, but
stateless devices will remain in the future;  these will not be able to
perform heuristics as defined in the heuristics draft.  They may have to
be redeployed to other places in the network, causing forklift
replacements

	8) Even by your own conclusion, heuristics are not 100%
accurate.  There are some "false positives" and some "false negatives"
situations.

	In summary, I find your draft to be interesting, and I am
looking forward to seeing it progress on Informational track.  I believe
also, that a deterministic approach would be quicker and easier.  I
suggest the "visibility" draft remain on the WG Standards track as it is
more implementable. 

In previous discussions we've reached the conclusion that traffic
visibility matters only for a subset of the traffic, where your policy
says two things:

1.	You intend to do some kind of inspection on the protected
payload (could be as shallow as checking ports or as deep as scanning
the transported files for malware) 
2.	You don't allow any ESP that isn't NULL, because then you won't
be able to inspect it. ESP non-NULL is dropped.

Given that this is the kind of policy we're enforcing, you cannot really
escape doing some inspection on the payload - you intend to do this
anyway. Even if the packet was "tagged" as the visibility draft
suggests, you would still need to verify that the ESP is indeed NULL -
you can't rely on a tag.
 
So IMO it doesn't really matter how weak or powerful the edge device is,
it has to be powerful enough to inspect all ESP-NULL packets if it is to
implement such a policy. If it's not powerful enough, then it can't
enforce such a policy, and it doesn't really have to decide whether or
not the ESP algorithm is NULL or not. In that case it doesn't have to
implement any heuristics. Stateless devices are such a case. They
shouldn't care whether or not the traffic is ESP-NULL or not.
 
As for heuristics not being 100% accurate, that is correct, but the
chances can be made arbitrarily small, and small enough that we are
willing to live with it.
 
Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Feb 2009 10:03:32 +0200

Dragan Grebovich wrote:
Yoav

I apologize for not being clearer earlier.  I was not suggesting any new/different policy enforcement.

I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level.  Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly.  Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter.

I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point.  When a packet hits a decision point, the following has to be determined asap:

   1) Is the packet terminated here or am I to forward it?  Until now, forwarded packets were always forwarded and no action was performed on the content.  Now we may want to turn on a policy to inspect packet content which is not terminated here.
   2) Can I do anything with it" (has it cleartext or IPSEC payload)?  If cleartext - it is trivial ...
   3) Is it AH or ESP?  This is quick and trivial too ...
   4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know).

IMHO for each packet we have to perform the four steps.  It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call.  I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives.   Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency).  I am concerned that on large (high-end) devices this may take an unacceptably large toll.

Dragan
I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted.

Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL)

So for each packet, the processing is something like this:

 1.  Is the protocol non-IPsec? if so, do the regular inspection
 2.  Is the protocol AH? if so,  skip to the payload and do the regular inspection
 3.  Is the process ESP with an SPI and endpoints that have already determined to be NULL?: If so, skip to the payload and inspect. Note that this is a simple table lookup
 4.  Is this a new ESP SA? Do the heuristics, and then mark it in the table

Of course it's possible for the endpoints to cheat, start of with ESP-NULL, and then after the heuristics marked it as OK, begin encryption. This "attack" will work if all your policy says is "ESP must be NULL". But that is not an interesting policy. Real policies will require deeper inspection of the internal flows, so the cost of the heuristics becomes negligible, as it only requires looking at the first few packets of each ESP SA.

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 4 Feb 2009 10:40:48 -0700

Some comments inline...

Thanks, 
Ken
 
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Tero Kivinen
>Sent: Tuesday, February 03, 2009 5:12 AM
>To: Dragan Grebovich
>Cc: [email-masked]
>Subject: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
>
>Dragan Grebovich writes:
>> Hi Tero
Complexity is one thing, but there is a cost vector to consider too and the answer may be different based on the device being targeted. 

Some devices may be capable of doing the heuristics processing in SW as an exception case, whereas other devices (e.g. requiring high bandwidth DPI) need to do this in HW to maintain line rates. 

>From a cost perspective, If a device is stateless in nature (e.g. traffic monitoring/logging for auditing purposes), then that device will now need to be stateful to maintain all these (potentially hundreds of thousands) or 3-tuples as state, which may not be practical. 

Cost also reflects expensive SRAM to store these cached policies, which may be pennies, but in a low end NIC can be a cost-inhibitive to implement. 

>that protocol number also.
Any addition of a new protocol will require changes to any device that does not support that protocol, so this argument is not unique to WESP, but applicable to all new protocols - e.g. how would these devices act when seeing the recently introduced HIP protocol or UDP-Lite? If we use this argument that a new protocol addition will impact legacy devices, we should not be allocating ANY new protocols - full stop!

Also see previous argument for low end devices above.
>   IPsec SA (i.e. is not a node where IPsec SA terminates).

Agreed - any device terminating the SA has all the info it needs already.

>UDP caches require much more. 

This is typically true for VPN/Tunneling, but not true for transport mode, E2E solutions, where an IPsec SA will be as granular as the traffic it is carrying (e.g. TCP port 123 to TCP port 456 between two endpoints). This will result in a 1:1 correlation between a flow and an SA, hence the number of SAs can and will be in the 10s and 100s of thousands, especially at intermediate nodes in the network. 

>This means that high-end producsts need

Agree with the last part for doubling the state, BUT this additional state may be in the HW (e.g. dedicated SRAM on the NIC, instead of DRAM accessible by the DPI inference engines), so even though the state doubles, the cost associated with where that state is kept goes up by a larger factor (cost of SRAM is many times the cost of DRAM).  

>actual heuristics processing only requires to process around that

The SA lifetimes will be dependent on policy and the type of traffic underneath. Again, we are talking transport mode and transient traffic - I connect to a server to retrieve some data and then move on with something else - the life of the connection may be a few minutes or even seconds. How about VOIP calls protected by IPsec? The usage model is securing traffic for all connection using transport more IPsec and the typical connections from the client to server are short lived, mixed in with a small percentage of long lived connections - e.g. you may be connected to a resource continuously during a given work day (check your email, Open channel IM with a colleague during a meeting, keep an eye on the every decreasing stock price in order to decide when to empty your mattress and buy!, and so on...)

Which brings up another important point...
Cache eviction - how will this work?
We can keep adding SAs (based on heuristics), but how do we decide when a given SA is no longer needed? This compounds the issues with keeping state, as in the best case, cache eviction will likely be policy based. How is the policy determined and how do we differentiate between short and long lived SAs? As the SA cache will be of a finite size, this WILL lead to a cache thrash (add SA, evict SA, ...), causing further resource consumption.

>addresses and SPI number found from the packet.

How about dynamic route changes for already established SAs? The same problem will exist as the Monday morning problem, but without the diffie-hellman overhead. Because we are caching state on one device, a change in route where the packets take a different path will force the new device to 'relearn' all the cached info. 

>that each flow ends to one specific node of the load balancing

It may also be desirable to load balance based on ports. E.g. traffic flowing between two domains with a NAT may see a lot of flows with the same src/dest IPs, so disambiguating by ports is the next step.

High availability is another one to consider, especially during maintenance periods. One device is powered down and a backup device takes over. This is similar to route changes in principle, where the backup device will need to relearn all the state. 

>flows, but heuristics has already been done in that case.

Agree, but the heuristics engine may be heavily used as VOIP becomes prevalent, especially within the Enterprise. Lots and lots of UDP traffic that is short lived, which ties back to earlier points on cache maintenance and frequency of exercising the heuristics engine. 

>do deep inspection or things that require looking in to the ESP-NULL

Auditing / logging / sniffing / sampling are some examples of stateless devices that do require to peek in the packets. Probably lots more also, so look for others to provide examples...

>It might be easier, but it definately will not be quickier. 
The speed of deployment may or may not be true. If the stars are aligned, then it could be deployed within one or two refresh cycles, which is about the same for heuristics in intermediaries devices. After all, only a handful of vendors own a large percentage of the market for OS / intermediary devices. Adoption is obviously based on customer pull/perceived usefulness.

> Heuristics

This point is somewhat moot, as we are trying to address a new use case for ubiquitous transport mode IPsec, which is not the case today. It is a new use case, so if people want it, they will use the correct version of IKE. 

In fact, the same argument is true for all the other changes we are putting into IKE under the different charter items...

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 4 Feb 2009 11:25:27 -0700

Quote ...
"Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL)
"
I do not think a typical policy will be black and white (allow ESP-NULL, drop ESP-encrypted), as traffic patterns will be mixed in reality (encrypted Vs. clear) and policy will dictate how a given traffic stream in inspected and if it is opaque then take the associated action (drop / bypass / apply QOS rules / send a different path in the network / etc...). e.g. There may be a secure channel to transfer highly sensitive data (e.g. payroll, company secrets, etc.) which should be encrypted and it may be undesirable to categorize this under a general rule - this is a simple extension of the firewall function.

The 'bait and switch' attack where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypted may also be possible unintentionally. E.g. Connection to a server (cluster / farm) to gain access to a 'normal' service uses ESP-NULL and then at a later stage, where the previous connection was torn down and a new one built, the connection is obtaining some sensitive data and is now using ESP-Encrypted. On the outside, the connection attributes look the same (same server IP, same client IP (but may be different client due to NAT), same SPI - SPIs can be reused for new connections to preserve fast lookups algorithms at recipients), but underneath the connection is to access a different resource (may be using a different port or service above the IP layer). If the intermediate device has a cached rule (based on the previous connection) indicating the traffic is clear, it will lead to falsely inferring the contents of the payload and undesirable results. This goes to my point on cache eviction policy for heuristics based intermediate devices, as highlighted in a separate thread. Reuse of the same 'tuple' with different traffic characteristics may be infrequent, but still plausible.

I agree with Yoav that this attack may also be possible intentionally between two colluding parties, where the policy indicates all traffic is ESP-NULL.

Thanks,
- Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Wednesday, February 04, 2009 12:04 AM
To: Dragan Grebovich; [email-masked]
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote:
Yoav

Dragan

---

From: "Dragan Grebovich" <[email-masked]>
Date: Wed, 4 Feb 2009 14:24:20 -0500

Hi Yoav
 
As per #4, I did not elaborate what the policy should be, because it is
network-specific, however the goal of having ESP-NULL (in this
implementation) is to have strong authentication, while enabling thirds
party (intermediate) equipment to perform DPI.  That could be integrated
in the in-line switch/router/firewall (for better performance, but more
expensive), or could be handed off to the side to an appliance (more
inspections, cheaper, but slower).  Who am I to tell a Checkpoint guy
about both implementations?  :-)
 
I also disagree that we should inspect just a first few packets (and
keep their state), and then leave it alone to be done in cache.  Besides
the scenario you outlined below, there are other applications when
inspection must be done on each packet in each flow. 
 
I am not saying that heuristics are not doable, I am just saying I know
of implementations today that require this check performed on all
packets, and I don't believe devices we are working on today or in the
future would be able to support it with heuristics turned on and meeting
scalability and performance requirements..  
 
Also, DPI can be used for more than just AV or packet content snooping.
It could be used for QoS to determine more granular traffic shaping and
application-level routing.  There is also LI/CALEA aspect but I will
leave that alone for now.

From: Yoav Nir [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2009 3:04 AM
To: Grebovich, Dragan (BL60:SF00); [email-masked]
Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote:

	Yoav
	 
	I apologize for not being clearer earlier.  I was not suggesting
any new/different policy enforcement.  
	 
	I believe/agree that traffic visibility will matter only to a
subset of traffic, but that is enforced at each appliance level, or on a
more granular (per interface) level.  Not all devices have to be capable
of doing it, however if they are tasked to do it, they have to be able
to scale and perform transparently and quickly.  Therefore, if
heuristics are turned on, all traffic will be subject to inspection
(heuristic or deterministic), and then resource consumption matter.
	 
	I definitely concur that not all ESP traffic will be NULL, but I
believe your statement actually supports my point.  When a packet hits a
decision point, the following has to be determined asap:
	 
	   1) Is the packet terminated here or am I to forward it?
Until now, forwarded packets were always forwarded and no action was
performed on the content.  Now we may want to turn on a policy to
inspect packet content which is not terminated here.
	   2) Can I do anything with it" (has it cleartext or IPSEC
payload)?  If cleartext - it is trivial ...
	   3) Is it AH or ESP?  This is quick and trivial too ...
	   4) If it is ESP, is it ESP-NULL or full-ESP? If it is
full-ESP, I can't do anything with it - pass (preferrably) or drop (if
policy insists, but I doubt someone would prevent IPSEC, you never
know).  
	 
	IMHO for each packet we have to perform the four steps.  It is
the implementation-specific choice whether it is deterministic or
heuristic inspection to make a call.  I need to make a call if it would
take a few instructions or a chunk of code, potentially with some % of
false-positives or false negatives.   Again, I agree with you it may be
"tweaked" to be close to 0%, however each additional discrimination
requires more code, more cpu and more time to execute (latency).  I am
concerned that on large (high-end) devices this may take an unacceptably
large toll.
	 
	Dragan 

I don't think the use case is to inspect every packet like that. I also
don't agree with what you wrote in #4. If the appliance is willing to
pass ESP-non-NULL, then it doesn't really care about content inspection.
That is fine, and probably the more common case, but in that case it
shouldn't care whether a packet is or is not encrypted.
 
Our use case is an edge device that inspects all traffic, and drops
things it doesn't understand, such as non-NULL ESP and possibly SSL
(they might make an exception for HTTPS, but do a MiTM attack against
the SSL)

1.	Is the protocol non-IPsec? if so, do the regular inspection 
2.	Is the protocol AH? if so,  skip to the payload and do the
regular inspection 
3.	Is the process ESP with an SPI and endpoints that have already
determined to be NULL?: If so, skip to the payload and inspect. Note
that this is a simple table lookup 
4.	Is this a new ESP SA? Do the heuristics, and then mark it in the
table

Of course it's possible for the endpoints to cheat, start of with
ESP-NULL, and then after the heuristics marked it as OK, begin
encryption. This "attack" will work if all your policy says is "ESP must
be NULL". But that is not an interesting policy. Real policies will
require deeper inspection of the internal flows, so the cost of the
heuristics becomes negligible, as it only requires looking at the first
few packets of each ESP SA.

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 4 Feb 2009 23:37:59 -0800 (PST)

I'd like to ask the chairs to comment further about something
they (Paul) said during the virtual interim about Tero's
heuristics draft. From the minutes:

        Paul said that we will discuss on the list before we
decide which direction we will go

What directions do you see possible? I can see the value in
publishing it as an informational draft as a separate orthogonal
effort to the deterministic approach.

It's not that heuristics are undoable, but as this
thread (and others before it) has borne: it is not a general
solution applicable in all cases. 

________________________________
From: Dragan Grebovich <[email-masked]>
To: Yoav Nir <[email-masked]>; [email-masked]
Sent: Wednesday, February 4, 2009 11:24:20 AM
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

draft-kivinen-ipsecme-esp-null-heuristics comments 
Hi Yoav
 
As per #4, I did not elaborate what the policy should 
be, because it is network-specific, however the goal of having 
ESP-NULL (in this implementation) is to have strong authentication, while 
enabling thirds party (intermediate) equipment to perform DPI.  That 
could be integrated in the in-line switch/router/firewall (for better 
performance, but more expensive), or could be handed off to the side to an 
appliance (more inspections, cheaper, but slower).  Who am I to 
tell a Checkpoint guy about both implementations?  :-)
 
I also disagree that we should inspect just a first few 
packets (and keep their state), and then leave it alone to be done in 
cache.  Besides the scenario you outlined below, there are other 
applications when inspection must be done on each packet in each 
flow. 
 
I am not saying that heuristics are not doable, I 
am just saying I know of implementations today that require this check 
performed on all packets, and I don't believe devices we are working on today or 
in the future would be able to support it with heuristics turned on and 
meeting scalability and performance requirements..  
 
Also, DPI can be used for more than just AV or 
packet content snooping.  It could be used for QoS to determine more 
granular traffic shaping and application-level routing.  There is also 
LI/CALEA aspect but I will leave that alone for now.

________________________________
 From: Yoav Nir [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2009 3:04 AM
To: Grebovich, 
Dragan (BL60:SF00); [email-masked]
Subject: RE: [IPsec] 
draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote:
Yoav

 

 
Dragan 
I don't think the use case is to inspect 
every packet like that. I also don't agree with what you wrote in #4. If 
the appliance is willing to pass ESP-non-NULL, then it doesn't really care about 
content inspection. That is fine, and probably the more common case, but in that 
case it shouldn't care whether a packet is or is not 
encrypted.
 
Our use case is an edge device that 
inspects all traffic, and drops things it doesn't understand, such as non-NULL 
ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM 
attack against the SSL)
 
So for each packet, the processing 
is something like this:
	1. Is the protocol non-IPsec? if  so, do the regular inspection 
	2. Is the protocol AH? if so,  skip to  the payload and do the regular inspection 
	3. Is the process ESP with an SPI and  endpoints that have already determined to be NULL?: If so, skip to the payload  and inspect. Note that this is a simple table  lookup 
	4. Is this a new ESP SA? Do the heuristics,  and then mark it in the table
Of course it's possible for the endpoints 
to cheat, start of with ESP-NULL, and then after the heuristics marked it as OK, 
begin encryption. This "attack" will work if all your policy says is "ESP must 
be NULL". But that is not an interesting policy. Real policies will require 
deeper inspection of the internal flows, so the cost of the heuristics becomes 
negligible, as it only requires looking at the first few packets of each ESP 
SA.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 5 Feb 2009 09:52:15 +0200

Hi Gabriel,

This thread is precisely the discussion that Paul mentions.

The two alternatives I see on the table right now (Paul might have different opinions) are:

-          Publish a modified/wrapped ESP as Standards Track, and heuristics as an extra Informational.
-          Decide that heuristics are a sufficient solution for the problem, and publish it as the only ipsecme work item related to this charter item.

Paul and I would like to see more discussion and hopefully WG consensus being formed, now that we have a real heuristics I-D for everyone to analyze.

Thanks,
            Yaron

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of gabriel montenegro
Sent: Thursday, February 05, 2009 9:38
To: Dragan Grebovich; Yoav Nir; [email-masked]; Paul Hoffman
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

        Paul said that we will discuss on the list before we decide which direction we will go

As per #4, I did not elaborate what the policy should be, because it is network-specific, however the goal of having ESP-NULL (in this implementation) is to have strong authentication, while enabling thirds party (intermediate) equipment to perform DPI.  That could be integrated in the in-line switch/router/firewall (for better performance, but more expensive), or could be handed off to the side to an appliance (more inspections, cheaper, but slower).  Who am I to tell a Checkpoint guy about both implementations?  :-)

I also disagree that we should inspect just a first few packets (and keep their state), and then leave it alone to be done in cache.  Besides the scenario you outlined below, there are other applications when inspection must be done on each packet in each flow.

I am not saying that heuristics are not doable, I am just saying I know of implementations today that require this check performed on all packets, and I don't believe devices we are working on today or in the future would be able to support it with heuristics turned on and meeting scalability and performance requirements..

Also, DPI can be used for more than just AV or packet content snooping.  It could be used for QoS to determine more granular traffic shaping and application-level routing.  There is also LI/CALEA aspect but I will leave that alone for now.

Dragan

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 5 Feb 2009 10:45:19 +0200

Hi Ken, Yoav,

I agree with Ken that the policy needs not be black and white, but for a different reason. Some people will treat deep packet inspection by middleboxes as an optional service: you want it for most traffic, but some traffic is too sensitive and you choose to prioritize confidentiality over malware protection.

This model is definitely susceptible to attacks by infected endpoints that can control the IPsec stack, and e.g. attack a server using encrypted traffic. You don't really need a "colluding" peer - most peers will probably accept either an ESP-null or an ESP-encrypted proposal. But admins may be willing to take this risk.

Thanks,
            Yaron

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Grewal, Ken
Sent: Wednesday, February 04, 2009 20:25
To: Yoav Nir; Dragan Grebovich; [email-masked]
Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Quote ...

Thanks,
- Ken

Dragan Grebovich wrote:
Yoav

Dragan

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Feb 2009 13:57:55 +0200

Grewal, Ken writes:
> We can keep adding SAs (based on heuristics), but how do we decide
> when a given SA is no longer needed? This compounds the issues with
> keeping state, as in the best case, cache eviction will likely be
> policy based. How is the policy determined and how do we
> differentiate between short and long lived SAs? As the SA cache will
> be of a finite size, this WILL lead to a cache thrash (add SA, evict
> SA, ...), causing further resource consumption.

This is actually quite good point, and it is also implementation
detail that do affect the performance.

How this can be solved depends quite heavily on the environment where
heuristics is used. If we are doing firewall that already keeps state
of all TCP/UDP flows, then it would be natural to weakly bind IPsec
SAs and TCP/UDP flows inside together. For example keep in track when
there is no more TCP/UDP flows using the IPsec SA (i.e. all the
TCP/UDP flows which used this SA before, have now been moved to new
IPsec SA), and after that you can most likely remove the IPsec SA
entry quite quickly.

Another, and probably more common implementation will be just some
simple LRU based mechanisms to reuse old IPsec SA entries. This kind
of things are usually already done for the UDP protocols. 

> How about dynamic route changes for already established SAs? The
> same problem will exist as the Monday morning problem, but without
> the diffie-hellman overhead. Because we are caching state on one
> device, a change in route where the packets take a different path
> will force the new device to 'relearn' all the cached info.

Yes, but heuristics is still fast operation, thus that should not be
problem. Bigger problem usually is that the deep inspection state is
lost too...

> High availability is another one to consider, especially during
> maintenance periods. One device is powered down and a backup device
> takes over. This is similar to route changes in principle, where the
> backup device will need to relearn all the state.

As here the heuristics is run on the same device which is running the
deep inspection, they do already require methods of transferring that
deep inspection state from one device to another, and moving the IPsec
SPI cache state at the same time should not be a problem. 

> Agree, but the heuristics engine may be heavily used as VOIP becomes
> prevalent, especially within the Enterprise. Lots and lots of UDP
> traffic that is short lived, which ties back to earlier points on
> cache maintenance and frequency of exercising the heuristics engine.

If we know anything about the contents of the UDP packet (i.e.
recognize that it is VOIP traffic), we can most likely do heuristics
based on the single packet. Even if there is only 32 bits of the known
data in the packet (lets say version number and magic cookie or
similar), then usually that is already enough for detecting the
parameters and the probability that random ESP-encrypted packet has
same content is less than 0.000000024% (1/(2^32) * 100%).

So if VOIP traffic is heavily used then the heuristics most likely
will have special protocol detection code for it.

> Auditing / logging / sniffing / sampling are some examples of
> stateless devices that do require to peek in the packets. Probably
> lots more also, so look for others to provide examples...

As those do not affect the forwarding of the packet, then the
reliability requirements for them is much lower, meaning that they can
also work without storing any state, and running heuristics for per
packet basis. That of course do require implementing the heuristics on
the hardware if we are talking about gigabit links or faster. My guess
is that without any hardware support and only using software with
modern CPU you can probably process more than 100MBit/s, but most
likely not full 1GBit/s speed.

Of course if you are talking about very low cost appliances, then they
will not have modern CPUs, but on the other hand people do not
normally expect them to keep up with 1GBit/s speeds... 

> The speed of deployment may or may not be true. If the stars are
> aligned, then it could be deployed within one or two refresh cycles,
> which is about the same for heuristics in intermediaries devices.
> After all, only a handful of vendors own a large percentage of the
> market for OS / intermediary devices. Adoption is obviously based on
> customer pull/perceived usefulness.

The difference is that heuristics can be deployed within one or two
refresh cycles of the intermediate devices after customers start to
ask for it.

Modified ESP can be deployed within one or two refresh cycles of the
slowest vendor whose devices are used in the network.

Meaning that if the printer vendor used in the network does not update
their IPsec to support that modified ESP, then that modified ESP
cannot be used by intermediate devices.

> >Heuristics can also be implemented regardless of IKEv1 or IKEv2.
> >Modifying the ESP will be IKEv2 only, thus it will require end
> >nodes to start using that too. It seems that quite a lot of devices
> >are still using already obsoleted IKEv1 still, even when IKEv2 has
> >been out for 3 years...
> 
> This point is somewhat moot, as we are trying to address a new use
> case for ubiquitous transport mode IPsec, which is not the case
> today. It is a new use case, so if people want it, they will use the
> correct version of IKE.

To use correct version of IKE, in these use cases, do still require
ALL vendors used in the network to support IKEv2 in ALL of their
devices and in ALL of their operating systems before the modified ESP
can be assumed by the intermediate devices.

I.e. it for example requires that every single Windows Vista and Windows
XP (and of course older versions) machine to be updated to Windows 7
so they get IKEv2 support. 

> In fact, the same argument is true for all the other changes we are
> putting into IKE under the different charter items...

Nope. None of the other modifications we are doing is something that
requires every single IPsec implementation to be modified. You only
need resumption support if you are ever going to use it. If you do not
use it you do not need to know anything about it.

On the other hand the modified ESP support is required by all devices
talking IPsec in the enterprice network before the middle boxes can be
used. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Feb 2009 14:03:15 +0200

Grewal, Ken writes:
> The 'bait and switch' attack where a connection uses ESP-NULL and
> then at a later stage uses ESP-Encrypted may also be possible
> unintentionally. E.g. Connection to a server (cluster / farm) to
> gain access to a 'normal' service uses ESP-NULL and then at a later
> stage, where the previous connection was torn down and a new one
> built, the connection is obtaining some sensitive data and is now
> using ESP-Encrypted. On the outside, the connection attributes look
> the same (same server IP, same client IP (but may be different
> client due to NAT), same SPI - SPIs can be reused for new
> connections to preserve fast lookups algorithms at recipients), but
> underneath the connection is to access a different resource (may be
> using a different port or service above the IP layer). If the
> intermediate device has a cached rule (based on the previous
> connection) indicating the traffic is clear, it will lead to falsely
> inferring the contents of the payload and undesirable results.

This was covered in the draft section 7, where it said that if deep
inspection engine suddenly starts getting lots of garbage then it
should rerun the heuristics.

> I agree with Yoav that this attack may also be possible
> intentionally between two colluding parties, where the policy
> indicates all traffic is ESP-NULL. 

It is much easier to use ESP-NULL wrapped TLS, or SSH in those cases.
If both ends want to use encryption then the middle boxes cannot
really prevent it very easily. If TLS and SSH and blocked then use
IP(sec) over DNS, or IP(sec) over HTTP, and if even those fail then
use IP(sec) over mail :-)
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Feb 2009 08:00:20 -0500

>Paul and I would like to see more discussion and hopefully WG consensus being formed, now that we have a real heuristics I-D for everyone to analyze.

I fully agree with Yaron on all counts. If the WG thinks that heuristics is sufficient, we should not publish a protocol change. If the WG doesn't think heuristics are sufficient, the authors can publish it as an individual submission or an independent submission.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Grewal, Ken" <[email-masked]>
Date: Thu, 5 Feb 2009 09:37:00 -0700

By a 'colluding peer', I meant that both sides need to negotiate the same policy (e.g. this is sensitive data, so only allow encrypted traffic or vice versa).
I think this boils down to how tight the admin policy is and also whether it is desirable to allow encrypted/clear policies for different services to the same server/cluster, which could result in the unintentionally attack I described below.

Thanks,
- Ken

________________________________
From: Yaron Sheffer [mailto:[email-masked]]
Sent: Thursday, February 05, 2009 12:45 AM
To: Grewal, Ken; Yoav Nir; Dragan Grebovich; [email-masked]
Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Hi Ken, Yoav,

Thanks,
            Yaron

Quote ...

Thanks,
- Ken

Dragan Grebovich wrote:
Yoav

Dragan

---

From: "Dragan Grebovich" <[email-masked]>
Date: Thu, 5 Feb 2009 12:45:08 -0500

I looked for some traffic stats in a real, large enterprise network and
I found that UDP comprises 25-30% vs. TCP 70-75% of all traffic.  The
stats were measured on multiple places in the network, and multiple
samples were taken over the past 6 weeks.  Also, there is a slow but
consistent growth of UDP traffic over the past couple of years, pointing
to a long term trend.
 
IMHO heuristics would require more frequent inspections than just the
first few packets in a flow, and would require more heuristics rules on
a per app basis, instead of relying on fixed TCP immutable fields.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 6 Feb 2009 13:19:17 +0200

> consistent growth of UDP traffic over the past couple of years, pointing

Can you provide information what kind of UDP traffic that was? I would
except DNS, and different voip protocols, but what else? 

> a per app basis, instead of relying on fixed TCP immutable fields.

For heuristics it is enough to do just to inspect first few packets.
After we have found out the parameters, then we just use them. The
deep inspection that is using the results of the heuristics (i.e. to
find the actual protocol data) will of course need to inspect every
packet.
-- 
[email-masked]

---

From: "Grewal, Ken" <[email-masked]>
Date: Fri, 6 Feb 2009 15:54:20 -0700

Additional comment below...

...Snip...

>IPsec SA), and after that you can most likely remove the IPsec SA

[Ken] This may be feasible for stateful devices, but does not work for stateless devices (QOS/Statistics/auditing functions). Even in stateful devices, it requires coupling between observation on flows and the associated heuristics cache engine, which creates an additional overhead. 
>of things are usually already done for the UDP protocols.

[Ken] These require timestamps (or other ordering / metric based approaches) and monitoring to ensure the cache is up to date. Furthermore, it may also provide opportunities for adversaries to use periodic replays to provide cache thrash and associated overhead in re-executing heuristics engines. 

I am not convinced that SW based solutions will scale 10Gbps solutions, let alone future 40/100Gbps bandwidth requirements, especially at these network 'choke' points, so a HW orientated solution may be desirable...which brings us back to cost/complexity...

>problem. Bigger problem usually is that the deep inspection state is

[Ken] But not for stateless devices, which will carry the 'resync/Monday morning problem' each time.

>SPI cache state at the same time should not be a problem.

[Ken] But again, this is additional work, which can be avoided if we have no state.
>will have special protocol detection code for it.

[Ken] The point being that this traffic may be short lived, smaller packet, hence more packet per bandwidth, which will exercise the heuristics engine / cache issues much more then, say long lived TCP sessions (which are rare). 

>likely not full 1GBit/s speed.

[Ken] Agreed on the need to implementing heuristics in HW, but this contradicts the original 'benefit' of heuristics, where heuristics engine can be run in SW and a resultant cache entry stored in HW. Adding an ever changing set of rules + heuristics engine is a non-starter - at least that is the feedback I am getting from the HW engineers I have spoken with - mucho complexity + cost!

>cannot be used by intermediate devices.

[Ken] There will always be a migration path, as well as exception cases. It is much easier to add a static rule for a fixed printer, then to have dynamic rules to allowing encrypted data to pass through the network. Additionally, some of the legacy devices may not even support a secure connection, so the traffic will be in the clear anyway. E.g. How many printers support IPsec today? If they need to support this in the future, then it is just as easy for them to support WESP, instead of ESP-NULL...
...snip...

[Ken] I think we need to consider all these issues in determining if a heuristics solution will work and scale under ALL circumstances. By contrast, WESP does not have any of these issues (bar adoption), as it is being designed for efficiency, cost effectiveness and scalability.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 7 Feb 2009 20:56:50 +0200

Hi Gabriel,

Since we are still in the midst of technical discussion, I am perfectly willing to wait a few more days and then directly ask Tero and Dan, as well as other supporters of the heuristics approach, for their opinion in the matter. I believe this would be more fruitful than interpreting the wording of their draft. In the meantime, I'd like to focus on this technical discussion and ensure that we've explored as many issues as we can.

Thanks,
        Yaron

> From: gabriel montenegro [mailto:[email-masked]]
> Sent: Saturday, February 07, 2009 1:53
> To: Paul Hoffman; Yaron Sheffer; Dragan Grebovich; Yoav Nir;
> [email-masked]
> Thanks for the clarification. If I could ask for further clarification
> here: is there much support
> for the claim that heuristics is sufficient for ALL scenarios now and in
> the future
> (approach #2 as noted by the chairs below)?
>
> The reason I ask is that Tero/Dan themselves don't seem to espouse this
> view.
> At least that is what their draft says in the introduction:
>
>    To make sure that any solution does not break in the
>    future it would be best if such heuristics are documented, i.e. we
>    need to publish an RFC for what to do now even when there might be a
>    new protocol coming in the future that will solve the same problem
>    better.
> This talks about co-existence of heuristics with another approach
> (presumably deterministic),
> which is the approach #1 as noted by the chairs below.
>
> I agree with approach #1, of course, so was glad to see that in Tero's
> draft, but
> would like to be corrected if somehow I'm misreading the above text.
>
> thanks,
>
> Gabriel
>
>
>
> ----- Original Message ----
> > From: Paul Hoffman <[email-masked]>
> > To: Yaron Sheffer <[email-masked]>; gabriel montenegro
> <[email-masked]>; Dragan Grebovich <[email-masked]>; Yoav Nir
> <[email-masked]>; "[email-masked]" <[email-masked]>
> > Sent: Thursday, February 5, 2009 5:00:20 AM
> > >The two alternatives I see on the table right now (Paul might have
> different
> > opinions) are:
> > >
> > >-          Publish a modified/wrapped ESP as Standards Track, and
> heuristics as
> > an extra Informational.
> > >-          Decide that heuristics are a sufficient solution for the
> problem,
> > and publish it as the only ipsecme work item related to this charter
> item.
> > >
> > >Paul and I would like to see more discussion and hopefully WG consensus
> being
> > formed, now that we have a real heuristics I-D for everyone to analyze.
> >
> > I fully agree with Yaron on all counts. If the WG thinks that heuristics
> is
> > sufficient, we should not publish a protocol change. If the WG doesn't
> think
> > heuristics are sufficient, the authors can publish it as an individual
> > submission or an independent submission.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
> Scanned by Check Point Total Security Gateway.
>
> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 9 Feb 2009 16:19:54 +0200

Grewal, Ken writes:
> [Ken] This may be feasible for stateful devices, but does not work
> for stateless devices (QOS/Statistics/auditing functions). Even in
> stateful devices, it requires coupling between observation on flows
> and the associated heuristics cache engine, which creates an
> additional overhead.

As the draft says this is mostly meant for stateful devices, and that
has been the main goal for the document. The charter says:

"A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system ..."

I.e. the main goal was set to be on the devices doing deeper
inspection i.e. firewalls and intrusion detection systems.

At least my conclusion on the list when we discussed on the usage
cases were for that kind of stateful devices.

Are QOS and auditing devices really stateless?

I would expect QOS devices to have all kind of reservation systems and
so on and for those I would expect them to be keeping state?

For the auditing I have been using I have usually enabled auditing of
new connections, not all packets, thus all my auditing systems I have
set up have been keeping state. What kind of usage is completely
stateless auditing devices used for your example of 10Gbps links?

Statistics devices could even be stateless, but is that really
something we should aim for? I.e. to wait for 5-10 years before we can
use our stateless statistics devices, compared to use stateful
statistics devices for doing the thing this or next year. 

> [Ken] These require timestamps (or other ordering / metric based
> approaches) and monitoring to ensure the cache is up to date.

Stateful devices do already have all that.

> Furthermore, it may also provide opportunities for adversaries to
> use periodic replays to provide cache thrash and associated overhead
> in re-executing heuristics engines.

As far as I have understood we are still talking about the inside one
enterprice network, not internet as whole. If they do have untrusted
users inside (i.e. attackers), they should enable encryption, thus all
this is not really a point.

As ESP-NULL does not offer confidentiality it can only be used in
trusted environments, where the denial-of-service attacks against the
device in the middle should not be big problem. 

> I am not convinced that SW based solutions will scale 10Gbps
> solutions, let alone future 40/100Gbps bandwidth requirements,
> especially at these network 'choke' points, so a HW orientated
> solution may be desirable...which brings us back to
> cost/complexity...

Limits for software based heuristics are not really related to the
line speed, but number of new IPsec connections per second going
through the device.

The line speed do affect the HW based flow cache lookup (i.e. the
appendix A.1 fastpath part of the processing), but that is doable even
at 10Gbps speed, as it basically does same thing as normal stateful
firewall rules (i.e. fetch flow information based on IP address pair,
protocol and in this SPI number instead of port numbers).

> [Ken] But again, this is additional work, which can be avoided if we have no state.

Yes, it is additional data. You need to transfer 6 bytes (SPI + ICV
len and IV len) per flow more when you transfer the whole deep
inspection state from device to other (which might include whole TCP
transmission window, which is around 64kB or so), so the increase of
additional work is about 0.009% (actually it is normally even less, as
TCP state is per TCP flow, and usually one IPsec flow has multiple TCP
flows inside, but in this case I took the worst case scenario, where
each IPsec flow have exactly one TCP flow inside).

I do not really consider that to really be matter.

(Doing deep inspection on TCP streams usually do require
reconstructing TCP stream in fully including dropped and retransmitted
packets. Otherwise there are attacks where you only inspect packet
which never reaches the end node (attacker causes it to be dropped),
and the retransmission packet is different than the first packet and
if you let that pass to the end node, attacker managed to get
uninspected packet through. Solution is that you either do the
retransmissions from your internal data or you verify that
retransmissions sent by the original node contains same data than
original packet, both of them do require you keep the TCP transmission
window data. This text is here just to explain that doing deep
inspection (for IDS or IPS) on TCP stream is very costly operation and
heuristics do have minimal cost compared to them.)

> [Ken] Agreed on the need to implementing heuristics in HW, but this
> contradicts the original 'benefit' of heuristics, where heuristics
> engine can be run in SW and a resultant cache entry stored in HW.
> Adding an ever changing set of rules + heuristics engine is a
> non-starter - at least that is the feedback I am getting from the HW
> engineers I have spoken with - mucho complexity + cost!

I explained that IF you REQUIRE heuristics to run without state, then
you most likely need to implement them on hardware if you need high
speeds. I didn't mean to say anybody should try that, because I think
it is cheaper to do it by adding state.

I think doing heuristics on the software is completely ok and doable,
for even very high speeds, when you do it in the smart way, i.e. use
state. I would expect following implementations to be usable:

1) Keep state of the SPI information, doing slowpath heuristics on SW,
   and doing fastpath part on HW (any speed).

2) Keep state of the SPI information, doing slowpath heuristics on SW,
   and doing fastpath part on SW (most likely up to 1 GBit/s).

If you insist on not using state, then you can most likely do full
slowpath and fastpath on SW up to 100MBit/s speeds, and I do not
really see any point of doing any hardware version as making versions
1 or 2 above make much more sense.

If you really require very high new connection rate, i.e. for example
you have 10Gbit/s link and it consists fully at IKEv2 creation (4
packets), TCP session creation (3 packets), 2 data packets, TCP
session finish (4 packets), IKEv2 SA delete (2 packets), i.e. each
IPsec SA only contains one TCP session, which only exchange one data
packet. This means there is 15 packets in total 8 in one direction 7
in other. IKE packets around 236 + 236 + 208 + 208 (with minimal
packet sizes for AES-SHA1, 1024 bit MODP, pre shared key) and 100
bytes for IKEv2 deletes, TCP SYN/FIN packets are 40 bytes, and data
packets 40+64 bytes of data. So in total that means 1576 bytes and
using ethernet framing that makes 2146 octets -> 17168 bits.

Using 10Gbit/s link that means we can do 582479 such exchanges per
second. For software implementation using 2GHz CPU that gives about
3400 cycles for doing the heuristics for the packet. That should be
plenty for doing heuristics, as they do not really have any loops or
other complicated operations. The one packet verification is around 10
loads from packet, and around 15-20 compares, and we might need to do
that 6 times (for differet ICV/IV lengths), so in total we have at
about max 60 loads and 90-120 compares plus some basic arithmetics.

I would expect that 2GHz CPU should keep up to that speed. 2GHz CPU
cannot keep up to the 10GBit/s line speed or do routing lookups for
that speeds, but if routing and non-heuristics packets are processed
by other hardware, one cpu should take care of the worst case
heuristics.

So even at 10Gbit/s line speeds I do not think you need hardware
implementation of the slowpath heuristics part.

> [Ken] There will always be a migration path, as well as exception
> cases. It is much easier to add a static rule for a fixed printer,
> then to have dynamic rules to allowing encrypted data to pass
> through the network. Additionally, some of the legacy devices may
> not even support a secure connection, so the traffic will be in the
> clear anyway.

All of the traffic is in the clear, as we are talking about ESP-NULL
here.

My draft offers even simplier solution if you are accepting that kind
of solutions. It is mandated by policy option, then you do not need to
run heuristics at all, you simply assume all packets are ESP-NULL, as
that is mandated by policy, and those exception cases where this is
not true, you handle by adding rules...

> E.g. How many printers support IPsec today?

Not sure, but I do know there are such out there, and even more will
be (at least kyocera has announced their printers supporting IPsec and
IPv6 http://www.fishers-boise.com/Information_Vault/Blogs/e_2496/News/2009/1/New_Kyocera_Printers_Combine_Quality__Low_Cost__and_Environmentally_Friendly_Design.htm).

> If they need to support this in the future, then it is just as easy
> for them to support WESP, instead of ESP-NULL...

Might be but for PCs you normally do this by updating the operating
system, how often have you updated the OS of your printer? And note
that they already support ESP-NULL and with heuristics they do not
need to update anything. With WESP they need to update their software.

Most of those vendors do not have their own IPsec, but it might either
come with the embedded operating system or it might be OEM toolkit,
which requires them to get new version of that, and new features
usually only comes with new versions (i.e. they are not part of the
bug fixes provided for old versions), thus they would need to update
to newer version of operating system or toolkit.

As we do make IPsec OEM toolkit I can say that our customers have been
very reluctant to update to latest versions after they get their
pruducts out. there are still customers using 4 years old version.
Some of them are luckily now looking for updating to latest versions
for new products. I do not expect them to ever update their old
devices for new versions.

So if we make WESP it will come out most likely during 2010 (and we
most likely do not make it unless there is customer demand for it (or
for heuristics), which mean that it might get pushed forward by year
or two), which will mean that some of our customers might delay up to
2015 before they update to that version, and after that it takes year
or so before they get their devices out.

> [Ken] I think we need to consider all these issues in determining if
> a heuristics solution will work and scale under ALL circumstances.

I do not think heuristics need to work in ALL circumstances. I think
it needs to work in the circumstances we are aiming for, and by
charter that is "an intermediary device, such as a firewall or
intrusion detection system".

Do you really consider stateless versions of those intermediary
devices something that will be common in the future?

> By contrast, WESP does not have any of these issues (bar adoption),
> as it is being designed for efficiency, cost effectiveness and
> scalability. 

The adoptation is big issue there.

As my draft says even if we go for WESP, I think the intermediary
device vendors still want to have some solution they can use now, thus
they will still need to implement heuristics.
-- 
[email-masked]

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 10 Feb 2009 11:16:18 -0800 (PST)

> inspection i.e. firewalls and intrusion detection systems.

Disagree completely. The charter item is a general one for intermediary devices
(some of which are and are expected to continue being stateless). 

The above was just an example.

Gabriel

----- Original Message ----
> From: Tero Kivinen <[email-masked]>
> To: "Grewal, Ken" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; Dragan Grebovich <[email-masked]>
> Sent: Monday, February 9, 2009 6:19:54 AM
> IPv6 
> http://www.fishers-boise.com/Information_Vault/Blogs/e_2496/News/2009/1/New_Kyocera_Printers_Combine_Quality__Low_Cost__and_Environmentally_Friendly_Design.htm).
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Feb 2009 21:51:31 +0200

>The above was just an example.

OK, so give us a counter-example. Why would a stateless device want to be able to tell the difference between ESP-AES-CBC and ESP-NULL.  What policy is it trying to enforce?

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 10 Feb 2009 14:33:35 -0700

Stateless firewalls are commonly employed for efficiency and as a crude method for cutting off access to certain services - these are useful for basic access control in cost effective, high bandwidth, network scenarios. E.g. Corporations may not want to allow various P2P protocols, discovery of resources, access to certain services (especially if using UDP as the underlying protocol), remote access/management to certain resources from outside well established network boundaries, etc., etc.. There are thousands of well defined ports providing different services from legacy, experimental, to the 'latest, greatest, service of the day' - and someone just found an exploit for and there is no fix available! How do you ensure that your network doesn't get inundated with unwanted traffic or exploited? Block that port!!

Stateless firewalls can and do provide the fundamental building blocks for basic access control. In these scenarios, the need to differentiate between encrypted / NULL ESP traffic is required to enforce these policies, without the need or burden of keeping state on 'connections' or 'security sessions'.

Thanks, 
- Ken

>Yoav Nir
>Sent: Tuesday, February 10, 2009 11:52 AM
>To: gabriel montenegro; Tero Kivinen; Grewal, Ken
>Cc: [email-masked]; Dragan Grebovich
>OK, so give us a counter-example. Why would a stateless device want to be
>able to tell the difference between ESP-AES-CBC and ESP-NULL.  What policy
>is it trying to enforce?
>
>
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Feb 2009 14:36:19 -0800

>Stateless firewalls can and do provide the fundamental building blocks for basic access control. In these scenarios, the need to differentiate between encrypted / NULL ESP traffic is required to enf…

(Not wearing any hat)

What level of assuredness do stateless firewalls need? That is, a stateless firewall can easily look inside what it is passing to get a simple guess about what is in the packet; this happens all the time on port 80. There are well known but imperfect heuristics for inspecting content on port 80; some of those could be used on ESP as well.

People commenting on this thread should state what level of certainty they think the middleboxes need to have, in addition to saying what properties they think those middleboxes have (such as ability to retain state, how much state, how long, and so on).

--Paul Hoffman, Director
--VPN Consortium

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 10 Feb 2009 16:00:35 -0700

>>Stateless firewalls are commonly employed for efficiency and as a crude
>method for cutting off access to certain services - these are useful for
>basic access control in cost effective, high bandwidth, network scenarios.
>E.g. Corporations may not want to allow various P2P protocols, discovery of
>resources, access to certain services (especially if using UDP as the
>underlying protocol), remote access/management to certain resources from
>outside well established network boundaries, etc., etc.. There are
>thousands of well defined ports providing different services from legacy,
>experimental, to the 'latest, greatest, service of the day' - and someone
>just found an exploit for and there is no fix available! How do you ensure
>that your network doesn't get inundated with unwanted traffic or exploited?
>Block that port!!
>>
>>Stateless firewalls can and do provide the fundamental building blocks for
>basic access control. In these scenarios, the need to differentiate between
>encrypted / NULL ESP traffic is required to enforce these policies, without
>the need or burden of keeping state on 'connections' or 'security
>sessions'.
>
>(Not wearing any hat)

[Ken] Wearing a basketball hat - 'go blazers!' :-)

>
>What level of assuredness do stateless firewalls need? That is, a stateless
>firewall can easily look inside what it is passing to get a simple guess
>about what is in the packet; this happens all the time on port 80. There
>are well known but imperfect heuristics for inspecting content on port 80;
>some of those could be used on ESP as well.
>
>People commenting on this thread should state what level of certainty they
>think the middleboxes need to have, in addition to saying what properties
>they think those middleboxes have (such as ability to retain state, how
>much state, how long, and so on).

[Ken] In some cases, the certainty must be 100%, otherwise there is no control. E.g. A new exploit has just been published for certain types of traffic - published vulnerability where a virus/worm can exploit a 'buffer overrun/stack overflow' condition for a given piece of software providing a given service, which subsequently allows a hijacker to take control of the machine/server. That service MUST be shut down to ensure that the vulnerability cannot be exploited and spread. This may or may not result in shut down of the server hosting the service, as you may want to allow remote patching, etc. Easiest way to do this is to block the port over which the vulnerability is being exploited. 

Just one example and I am sure there are numerous others...

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 10 Feb 2009 18:36:34 -0700

>cases were for that kind of stateful devices.

[Ken] I think the charter is device independent and needs to accommodate any type of device that requires access to the data - stateless or stateful. Otherwise, we have a partial solution. I was under the impression that this charter was to provide intermediate device traffic visibility, irrespective of the type of device that needs this visibility - or am I missing something?

>so on and for those I would expect them to be keeping state?

[Ken] QoS may be applied on the need of the underlying service. E.g. A static rule that indicates that I place voice traffic in a priority queue over data traffic may be sufficient as a basic stateless rule.

Auditing (logging) is another example where you may want to capture all TCP or UDP traffic - e.g. for diagnostics or other analysis. There is no need for any state correlation between connections / flows - this is just a dumb filter based on protocols / ports.

>stateless auditing devices used for your example of 10Gbps links?

[Ken] Stateless firewall is one example to filter unwanted network traffic. Please see separate message on this topic on the ML.

>statistics devices for doing the thing this or next year.

[Ken] We have been through the deployment timeframe arguments before and it looks like we are going in circles here. It is speculative to say how long one solution will take to be adopted instead of another. This depends on a number of factors - e.g. some network appliance vendors have indicated that they will not employ heuristics in their network devices due the cost / complexity, but prefer a more deterministic approach, whereas others may be more willing to add this support and charge a premium for the appliances.

>Stateful devices do already have all that.

[Ken] Stateless devices may not!

>device in the middle should not be big problem.

[Ken] Why is DoS not a big problem, especially if we generate a new DoS opportunity on a new 'cache' in the network device?

BTW, insider threats are on the rise according to various public reports, so should not be discounted. This is one of the motivations of employing security, even within the Enterprise.

>line speed, but number of new IPsec connections per second going

[Ken] My point was that based on a large # of connections (and potentially cache thrashing, resulting in cache evictions), the SW burden for executing the heuristics engines may still be large. Also, cache will be of a finite size and will not scale to larger and larger connections / loads.

>each IPsec flow have exactly one TCP flow inside).

[Ken] This may be acceptable on some stateful devices, especially those that maintain TCP based flows, but may not be acceptable for stateless or UDP based flows.

>it is cheaper to do it by adding state.

[Ken] This choice is vendor/device/architecture dependent and one approach may not fit all models.

>1 or 2 above make much more sense.

[Ken] If you are implementing all (or even part of the solution) in software, then I agree that this will not scale beyond a few 100Mbps - hence a HW approach is needed to support larger bandwidths. So, it depends on your HW architecture, what services are being supported by the device and the perceived cost/complexity/value in adding support for additional capabilities (e.g. Heuristics Vs. WESP).

>by other hardware, one cpu should take care of the worst case

[Ken] Are you saying that a 2GHz CPU is needed to run a heuristics engine? If so, then the question begs - is an intermediate device vendor willing to allocate a whole CPU for this task, or would this be better utilized for processing the packet payloads? If we can do this in a deterministic manner in HW, then the CPU cycles can be 'recovered' and better utilized for other tasks.
>All of the traffic is in the clear, as we are talking about ESP-NULL

[Ken] By 'in the clear', I meant non-IPsec/ESP (traditional clear text) traffic; By encrypted, I meant 'wrapped in ESP' - i.e. ESP-NULL traffic - apologies for any confusion.

>not true, you handle by adding rules...

[Ken] I agree with this for 'fixed' devices such as printers, where it can have a well defined/known IP and there can be an 'exception rule' to accommodate these devices (e.g. allow traffic to/from this IP, irrespective of traffic type). Obviously these types of rules cannot be employed for other devices containing dynamic addresses.

>IPv6 http://www.fishers-
>boise.com/Information_Vault/Blogs/e_2496/News/2009/1/New_Kyocera_Printers_C
>ombine_Quality__Low_Cost__and_Environmentally_Friendly_Design.htm).
>
[Ken] Thanks - this is good to know and I was not aware of it.

>need to update anything. With WESP they need to update their software.

[Ken] Again, thanks - I was not aware that printers already support ESP-NULL. My comment was specifically for these devices that do not support ANY IPsec and future iterations can support the appropriate protocol, as needed. Having said that, as you indicated above, these type of devices are more amenable to exception rules, as they are fixed function and can have fixed addresses and are typically not expected to be the source / destination of threats, so in these cases, static rules will work just fine.

>or so before they get their devices out.

[Ken] Again, if we are talking about 'fixed function/fixed OS' devices, then these are static in nature and can be catered for as exceptions. IT departments are not too concerned with running Intrusion detection algorithms on data going to a printer, although it may end up being the norm at some time in the future.

>intrusion detection system".

[Ken] I think we need to consider ALL devices that currently operate within the network and perform any data examination. A Firewall and an IDS are but two examples of such devices.
>devices something that will be common in the future?

[Ken] No - I think they are common today!
>they will still need to implement heuristics.
[Ken] Perhaps there is a migration path consideration, where heuristics can offer interim benefits until a more deterministic solution is adopted. Adoption of either / both / neither will be ultimately based on numerous factors, including value, customer demand, etc.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 11 Feb 2009 13:34:25 +0200

Grewal, Ken writes:
> [Ken] In some cases, the certainty must be 100%, otherwise there is
> no control. E.g. A new exploit has just been published for certain
> types of traffic - published vulnerability where a virus/worm can
> exploit a 'buffer overrun/stack overflow' condition for a given
> piece of software providing a given service, which subsequently
> allows a hijacker to take control of the machine/server. That
> service MUST be shut down to ensure that the vulnerability cannot be
> exploited and spread. This may or may not result in shut down of the
> server hosting the service, as you may want to allow remote
> patching, etc. Easiest way to do this is to block the port over
> which the vulnerability is being exploited.  

Which does not help if you allow any encrypted ESP traffic to the
host, as the attacker will then just use encrypted ESP to make the
attack. On the other hand if you do not allow any encrypted ESP
packets, you KNOW that all packets are ESP-NULL, which makes the
packet checks much easier even for stateless devices.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 11 Feb 2009 14:06:18 +0200

Grewal, Ken writes:
> [Ken] QoS may be applied on the need of the underlying service. E.g.
> A static rule that indicates that I place voice traffic in a
> priority queue over data traffic may be sufficient as a basic
> stateless rule.

Note that you cannot do QoS without the co-operation of the sending
IPsec site. The sending IPsec node needs to put packets getting
separate QoS handling to separate SAs as otherwise the receiving IPsec
node will drop packets if they get out of the replay window.

Because of this there is no need to inspect the content of the ESP
packet, QoS must be done based on the IPsec SA, i.e. IP-addresses and
SPI number.

So for QoS there is no need to inspect the data inside the ESP-NULL
packet, as you cannot give different handling to different packets, as
if you do so, then those ESP-NULL packets getting slower path might
get dropped by the receiving IPsec node, as those packets getting
faster path have already moved replay window so that those slower
packets do not fit in to it anymore.

> [Ken] We have been through the deployment timeframe arguments before
> and it looks like we are going in circles here. It is speculative to
> say how long one solution will take to be adopted instead of
> another. This depends on a number of factors - e.g. some network
> appliance vendors have indicated that they will not employ
> heuristics in their network devices due the cost / complexity, but
> prefer a more deterministic approach, whereas others may be more
> willing to add this support and charge a premium for the appliances.

My guess is that regardless what we do, at least some middle box
vendors will implement heuristics in their high-end boxes, and after
one vendor supports it, others need to support it too to be able to
offer similar features than their competitors do. After a while even
more low-end devices will support it and soon most middle boxes do
support it. After that the requirements for supporting WESP will drop,
as middle-boxes work without it, so general support for it will stay
even lower.

But that is just my guess...

> [Ken] Why is DoS not a big problem, especially if we generate a new
> DoS opportunity on a new 'cache' in the network device?

DoS opportunities is a problem, but I do not think SPI cache will
create that much new opportunities. I.e. I claim that the SPI cache
can be implemented in such way that it does not offer any major DoS
opportunity. 

> BTW, insider threats are on the rise according to various public
> reports, so should not be discounted. This is one of the motivations
> of employing security, even within the Enterprise.

Yes, but I do not really think people are going to solve those using
ESP-NULL. I think they must move to encrypted ESP to provide
confidentiality also, and that makes the need for ESP-NULL visibility
even less.

For example most of the insider information (insider trading, leaking
trade secrets, espionage) problems cannot be solved by using ESP-NULL.

> [Ken] Perhaps there is a migration path consideration, where
> heuristics can offer interim benefits until a more deterministic
> solution is adopted. Adoption of either / both / neither will be
> ultimately based on numerous factors, including value, customer
> demand, etc.

This I agree and I have even tried to bring this up in my draft (see
last paragraph in the introduction section).
-- 
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 13 Feb 2009 12:30:59 +0530

> confidentiality also, and that makes the need for ESP-NULL visibility

I disagree. With AH as a MAY and ESP as MUST in IPSec, most vendors will implement ESP (besides the problem of AH being NAT unfriendly). All applications (OSPFv3, RIPng, etc), and there are many, which don't care about confidentiality, but are only concerned with authentication and integrity assurance, will continue using ESP-NULL. 

Thus there is a need for ESP-NULL visibility. 

Cheers, Manav

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 Feb 2009 14:05:30 +0200

Bhatia, Manav (Manav) writes:
> I disagree. With AH as a MAY and ESP as MUST in IPSec, most vendors
> will implement ESP (besides the problem of AH being NAT unfriendly).
> All applications (OSPFv3, RIPng, etc), and there are many, which
> don't care about confidentiality, but are only concerned with
> authentication and integrity assurance, will continue using
> ESP-NULL.  
> 

What kind of deep inspection you are doing on the OSPFv3 and RIPng in
the middle boxes? I.e. why does middle boxes need to know anything
about the actual data contents of those protocols?

You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility
is needed. 
-- 
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 13 Feb 2009 18:52:04 +0530

> You gave reasons why ESP-NULL is needed, not why ESP-NULL visibility

One might want to filter OSPFv3 packets coming from outside the domain.

Then when you're the end node, you might want to prioritize some OSPF packets over the others. I understand that the latter is an implementation specific issue, but it helps if the underlying protocol is amenable for deep inspection.

Cheers, Manav

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 Feb 2009 15:41:18 +0200

> One might want to filter OSPFv3 packets coming from outside the domain.

It is much better to do that check on the OSPFv3 receiver end where
the packet is actually authenticated by ESP-NULL, and which has much
better knowledge who is authorized to send what.

I do not know OSPFv3 that well, so I do not know how you tell which
packets are coiming outside of domain (as IP-addresses are not
authenticated in ESP-NULL, so those cannot be checked), so I cannot
really tell whether that check is doable or not.

So what are the exact checks you are doing and where inside the OSFPv3
packet content are those fields, and what do they gain compared of
doing the same checks on the final OSPFv3 receiver?

> Then when you're the end node, you might want to prioritize some
> OSPF packets over the others. I understand that the latter is an
> implementation specific issue, but it helps if the underlying
> protocol is amenable for deep inspection. 

End node already has all ESP-NULL related information, there is no
need for ESP-NULL visibility there.
-- 
[email-masked]