Subject: Re: [Ipsec] Fwd: I-D Action:draft-hoffman-esp-null-protocol-00.txt

From: David McGrew <[email-masked]>
Date: Thu, 6 Sep 2007 08:39:24 -0700

Hi All,

I wanted to follow up on some of the comments raised about draft- 
hoffman-esp-null-protocol-00.

Paul and I did consider the use of a SPI range to indicate which  
packets are NULL encrypted, but we rejected this method because there  
are existing ESP implementations, some of which are in silicon, that  
choose their own SPI values.  These implementations could not easily  
support the use of a SPI range.  Also, if we relied on SPI semantics  
to tell which ESP packets were using NULL encryption, then there  
would be a large number of false positives due to the fact that all  
of the ESP implementations currently fielded are not selecting their  
SPIs to conform to some classification scheme.

As Steve points out, the use of an IPv4 Option is not tenable because  
the majority of routers will use "slow path" processing on packets  
with such an option, i.e. they would handle it at a software process  
level rather than at the hardware interrupt level.    Unfortunately,  
this perception is not out of date ;-)

It is a valid question whether or not it is worth two IP protocol  
numbers to solve the problem that we need to indicate when an IV is  
present.  I am not the best person to judge the cost of assigning a  
second protocol number.  However, I can't see any robust solution  
without a second number.  There isn't a way to explicitly indicate  
that an IV is present in the ESP packet without adding another field  
(or overloading the semantics of an existing field, like the SPI).   
It's highly desirable to not add or overload a field, so that we  
retain compatibility with all of the existing implementations.   
Without an explicit indication, we're back to guessing.  It *might*  
be possible to make recommendations that would make this guessing  
more robust (i.e. an IV should only take certain values), but Paul  
and I looked at this possibility and we did not see anything that  
looked good.

David

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Sep 2007 15:28:49 -0700

>and I looked at this possibility and we did not see anything that 

David and I are in agreement on this.

At 2:05 PM -0400 8/27/07, Russ Housley wrote:
>I am still opposed to assigning a protocol number for each crytpo 
>variable size.  Since the proposal is to use a protocol number, that 
>could define a protocol that is comprised of the offset and the 
>payload.  There may be other alternative that do not consume 
>multiple protocol numbers.

We are trying to make this as easy for implementers to add to their 
current software so that we get the most benefit to the 
packet-inspecting firewalls. We are open to all suggestions, of 
course. However, given that at the current depletion rate, IPv4 
protocol numbers won't run out for over *50 years* (and that is not 
considering reusing ones that are clearly dead today, much less 50 
years from now), it seems a bit silly to block a proposal based on 
this.

--Paul Hoffman, Director
--VPN Consortium

IPsec mailing list
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Sep 2007 15:53:16 -0400

Dave:

Thanks for the summary.

It occurs to me that the use of a new IP protocol number gives us the 
opportunity to define an encapsulation of the authenticated-with-ESP 
datagram.  I have not thought this out all of the way, so I am 
offering this up for discussion with no ego.

Say the new protocol number is associated with a very simple syntax, 
as follows:

    - OFFSET
    - ESP

The first field tells the number of octets that need to be skipped to 
avoid the IV.  For many ciphersuites it will be zero.  It seems to me 
that carrying this extra word of zeros is a small price to pay for 
consistent processing of all ciphersuites.  It also has the benefit 
that only one port is used.

The second field is the ESP packet.  Of course, this encapsulation 
should only be used when authentication without encryption is used.

Russ

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 13 Sep 2007 17:17:40 +0300

> hoffman-esp-null-protocol-00.

Here is some comments:

Section 2.2 needs to be splitted to handle IKEv1 (or skip the IKEv1,
as it is already obsoleted) and IKEv2 separately.

Note, also that IKEv2 do not use protocol number 50 or similar
directly at all. It has separate IANA handled registry with the
protocol IDs:

RFC4306, section 3.3.1
----------------------------------------------------------------------
      o  Protocol ID (1 octet) - Specifies the IPsec protocol identifier
         for the current negotiation.  The defined values are:

          Protocol               Protocol ID
          RESERVED                0
          IKE                     1
          AH                      2
          ESP                     3
          RESERVED TO IANA        4-200
          PRIVATE USE             201-255
----------------------------------------------------------------------

Also it is not good idea to put the protocol id negotiation in that
place, as it doubles the SA payload data structure, which might cause
IKE packet fragmentation.

For IKEv2 it would be much more inline with rest of the IKEv2 to add
new notify like USE_ESP_NULL_PROTOCOL_ID, which would have similar
processing than what USE_TRANSPORT_MODE already has (i.e. both
initiator and responder include it and if included in both then it is
enabled, if not then we use default ID). 

> support the use of a SPI range.

Can those already existing silicon support new protocol number without
modifications? I would guess not directly, but it might be possible to
update them by updating the firmware of the chip. On the other hand
SPI number allocation can also probably be updated by updating the
firmware.

> Also, if we relied on SPI semantics to tell which ESP packets were
> using NULL encryption, then there would be a large number of false
> positives due to the fact that all of the ESP implementations
> currently fielded are not selecting their SPIs to conform to some
> classification scheme.

That is valid concern, and the only reason for this draft seems to be
to reduce the number of errors happening in the classification. 

> this perception is not out of date ;-)

I would guess that all the current ipsec hardware implementations
would process unknown protocol numbers in the slowpath anyways, so
before the hardware is updated the new protocol number will cause the
same problem. 

Also the security considerations sections should note that attacker
why wants to by pass the inspection hardware will of course use the
encrypted ESP packets if those packets are allowed to go through the
firewall, and if only ESP-NULL is ever allowed to go throught the
firewall, then the doing heuristic checks that will check all ESP
packets as they would be ESP-NULL is good enough, and if those packets
fails the IDS / IDP checking then they will be dropped, as will all
encrypted ESP packets too.

I think the introduction would require real use case scenario
explainign where this would be useful. I have not seen anybody to
explain me such use case.

This is often claimed (from the draft):

	Heuristic methods to parse ESP packets can be used, but these
	methods are not robust and they fail when their assumptions
	about ESP parameters and algorithms are wrong."

but I do not really belive that is true. If we are talking about the
CIF / IDS / IPS systems they will do deep inspection anyways, i.e.
make sure the TCP sessions are really established, and sequence
numbers are right etc, which means that getting random encrypted
packet to match those checks is smaller than getting the
random authentication data to match without knowing the key. Thus we
are able to drop all encrypted ESP packets which try to pass the
system, as they do not match te content inspection states of the real
plain text flows. 

Also, I do not really see point where firewall would allow ANY
encrypted traffic through if it wants to do inspection for ESP-NULL
packets, as why would attacker use ESP-NULL packets if it can use real
encrypted packets instead (for attacks using ESP-NULL and real
encrypted ESP packets you need to be able to create SA with the
intended destination host, so attacker must be able to authenticate
himself there for any case).

So I would like to see better real world rationale for the draft
first. 
-- 
[email-masked]

---

From: mcgrew <[email-masked]>
Date: Thu, 13 Sep 2007 09:08:22 -0700

Hi Tero,

>> hoffman-esp-null-protocol-00.

Thanks!

> directly at all. It has separate IANA handled registry with the

That's a good point.

> enabled, if not then we use default ID).

Good suggestion, thanks.

> SPI number allocation can also probably be updated by updating the

In many systems, it would be easy to support a new protocol number by using
the trick of leaving the existing ESP implementation unmodified, but then
re-writing the IP protocol number before the packet is sent (or after it is
received).   This nice property holds because the actual ESP processing is
independent of the protocol number.

> before the hardware is updated the new protocol number will cause the

No, that's not right.  The problem with using an IPv4 Option is that every
router on the path between the ESP sender and receiver will be processing
the packets with the options in them using the slow path.   This is a far
worse problem than having sub-optimal performance on the ESP sender and
receiver.

> about ESP parameters and algorithms are wrong."

I've done some analysis on this which I'm in the process of writing up for
submission as an I-D.   I would be happy to send you a pre-draft version to
hear your thoughts on it.  But it appears that there are lots of ways in
which false positives can occur.

> CIF / IDS / IPS systems they will do deep inspection anyways,

But we are not assuming/requiring that deep inspection is taking place.  It
could be that the firewall is enforcing a policy based on TCP/UDP ports
and/or addresses contained in the ESP payload, for example.

> i.e.
> random authentication data to match without knowing the key.

In what you're describing, you're assuming that the inspection point
maintains state across a packet flow.  You're right that an inspection point
that does that can make really effective use of heuristics, but it is highly
desirable to not require that inspection points be stateful.

> Thus we

I'm sorry, but I'm not sure that I understand your point here.  I think
you're suggesting that a firewall that wants to inspect *some* ESP traffic
should require that *all* ESP-protected traffic is NULL-encrypted.  But
requiring that NULL encryption be used doesn't make the job of recognizing
NULL encryption any easier.

Best regards,

David

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 14 Sep 2007 15:09:31 +0300

> independent of the protocol number.

Yes, but that usually still requires changes to the hardware or the
firmware of the hardware, as usually the packets come directly to the
IPsec hardware based on the hardware checking the protocol numbers. 

> and/or addresses contained in the ESP payload, for example.

That is already going to the TCP layer of the packet, thus checking
more and more stuff from inside the packet (what is defined deep, and
what is not is changing all the time). I do not think people consider
non-statefull packet filtering based on IP address and ports enough
for any firewall anymore. Almost every firewall want to handle TCP or
UDP flows opened from inside differently than those opened from
outside, which requires the firewalls to keep track of the TCP and UDP
flows, thus checking for TCP SYN/FIN/RST etc flags and usually also
checking sequence numbers and so on.

Devices which do support very simple address and port based filtering
usually do not know how to do that inside the ESP-NULL packets
regardless which format we use.

> desirable to not require that inspection points be stateful.

All your examples you gave in the draft were stateful:
context-inspecting firewalls, ACL-enforcing firewalls, intrusion
detection systems, intrusion preventation systems etc.

> NULL encryption any easier.

I mean if someone wants to attack something which is behind firewall
that will let both ESP-NULL and encrypted ESP packets through the
firewall, why would the attacker use ESP-NULL where the firewall might
detect the attacks. He would of couse use the encrypted ESP packets
instead as then he is sure the firewall cannot detect the attack.

As in both cases the attacker needs to be able to create SA with the
host he is attacking to (i.e. he has some kind of security
relationship with the host), and we do know that the firewall is
trying to detect cases where the host being attacked has misconfigured
policy which allowed creating SA selectors which should be allowed to
go past the firewall. Thus if we know that the host being attacked do
have unsecure IPsec policy it is not really feasible to assume they
have policy unsecure policy based on one security problem (invalid
selectors), compared to have policy based on other security problem
(allowing encrypted ESP).

So for the filtering to be effective the firewall need to block all
ESP packets which are not ESP-NULL destioned to the host he is trying
to protect, as the firewall cannot trust the node he is protecting to
have secure IPsec policy rejecting invalid ESP encrypted connections. 
-- 
[email-masked]

---

From: mcgrew <[email-masked]>
Date: Fri, 14 Sep 2007 07:44:02 -0700

Hi Tero,

On 9/14/07 5:09 AM, "Tero Kivinen" <[email-masked]> wrote:
> for any firewall anymore.

I agree that many people see value in inspection at higher layers.  But
certainly conventional ACLs using addr/port/protocol are still very common
and very useful.

> Almost every firewall want to handle TCP or

True, but we would not want to require a firewall to generate and maintain
state based on packets that it receives from the outside, such as ESP-NULL
packets.  

> regardless which format we use.

It is highly desirable to not require that an inspection point maintain
per-flow state in order to determine which packets are NULL encrypted.
Even if the inspection point has the capability of maintaining state, we
want to minimize the state that it has to store.

> detection systems, intrusion preventation systems etc.

The "ACL" example was meant to specifically refer to stateless inspection
based on addresses and ports.  We'll be more clear in the next version of
the draft.

>> NULL encryption any easier.

Thanks for explaining further, more below.

> instead as then he is sure the firewall cannot detect the attack.

Well, an attacker would be motivated to use ESP-NULL in order to attack a
host that had a policy that only accepted NULL encryption.  In this case,
the attacker would know that the plaintext was available for inspection, but
would be hoping that the attack would go unnoticed.

> go past the firewall.

It might be a useful to have a firewall that detected misconfigured policy
on the networks that it protects, but let's not assume that in our analysis
of requirements.  

> Thus if we know that the host being attacked do
> have unsecure IPsec policy

This could be the case, but we can't require it.

> it is not really feasible to assume they

One of the main motivations for inspection inside of auth-only ESP, I think,
is the case in which an ESP sender/receiver has been trusted, but may be
subverted.  In this case, the host does have the correct policy, but it has
been the victim of a worm or some other form of malware.   Your analysis (if
I'm understanding it) disregards this case.

Best regards,

David

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Sep 2007 18:33:15 +0300

> certainly conventional ACLs using addr/port/protocol are still very common

You cannot use such simple tests to detect the problems you describe
in the end i.e. subverted node sending invalid data to the correct
host using proper IPsec policy.

> state based on packets that it receives from the outside, such as ESP-NULL

In normal case they do that for all traffic, not only ESP-NULL
packets. I.e. firewalls usually do keep track of all incoming and
outgoing TCP flows, and keeping track of flows inside ESP-NULL packets
belongs to same category, thus do not add any more work.

The question is whether those very simple filter machines which only
know how to filter packets based on IP and port numbers, need to have
feature where they can look in to the ESP-NULL packets. My guess is
that, such feature is needed and added to more high-end firewalls,
which will be already doing statefull checking of the packets.

> would be hoping that the attack would go unnoticed.

But IPsec policy already mandatory features that require it to check
that packets coming in must match the selectors used when creating the
IPsec SA. I.e. valid implementation of the recipient will throw the
packets away which do not match its security policy, thus those
packets that would be thrown away by simple firewall checking the IP
and port numbers inside the ESP-NULL packets, will be thrown away by
the recipient IPsec stack also as they do not match the policy
specified there (or the policy is incorrect, but that was not the case
here). 

> I'm understanding it) disregards this case.

Detecting subverted sender is much easier in the real recipient of the
packet than in the firewall in the middle. The end node has more
information about the situation and can do much stricter checking of
the data than firewalls in the middle, who are missing the big
picture. 
-- 
[email-masked]