Subject: [Ipsec] NULL/NULL forbidden in ESP

From: [email-masked] (Arnaud EBALARD)
Date: Thu, 09 Aug 2007 18:17:36 +0200

Hi,

First, let me say this is a real question, and not just a joke.

NULL authentication algorithm and NULL encryption algorithm are
mandatory-to-implement in ESP. RFC 2406 and revised version (RFC 4303)
states in section 3.2:

   Note that although both confidentiality and integrity are optional,
   at least one of these services MUST be selected, hence both
   algorithms MUST NOT be simultaneously NULL.

I obviously understand that this configuration makes ESP useless in term
of protection and just consumes bandwidth. Is there any other reason
behind the "MUST NOT" statement? I tried to dig but did not find any.

Now, please consider the following architecture (it's not just
hypothetical). In a domain with dynamic keying mandatory for IPsec SA
negotiation between all nodes and filtering dropping everything except
500/udp and esp (*), i have some specific needs (security at upper
layer, performance, ...) to _explicitly_ allow few unprotected flows
between some nodes or sets of nodes, based on a policy and credentials
(X.509 certs).

For that purpose, _negotiated_ NULL/NULL is the right solution, as the
tiny mtu loss (say 12 bytes in worst case) spares me the burden of
static configuration in the core and on the nodes. 

At the moment, even if some implementations allow it, the standard
prevents it. I'll be interested in comments on that.

Thanks,

a+

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

---

From: Dan McDonald <[email-masked]>
Date: Thu, 9 Aug 2007 13:06:45 -0400

On Thu, Aug 09, 2007 at 06:17:36PM +0200, Arnaud EBALARD wrote:
<SNIP!>
> behind the "MUST NOT" statement? I tried to dig but did not find any.

Just the prevention of one sending not-so-secure packets.

> static configuration in the core and on the nodes. 

If you have IPsec policies at the end-nodes that can make NULL/NULL
negotiatable, why can't those same policies be set to PASS instead?  Then
it's a simple matter of your filtering configs.

> prevents it. I'll be interested in comments on that.

Just recently I hacked a custom OpenSolaris kernel (without the IKE mods) to
allow NULL/NULL ESP - I did so for performance testing (can't blame the
crypto with NULL/NULL).  It was mildly painful and it requires a deft touch
to configure.  To have a proper implementation of NULL/NULL, however, it
would take a while to extract various checks.  Not to mention, at least our
implementation makes assertions/assumptions around that sentence in section
3.2.

BTW, what are you worried about w.r.t. performance?  Are you running on
multi-gigabit links or with legacy hardware?  Are you severely latency
sensitive?

Dan

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Aug 2007 13:14:50 -0400

>prevents it. I'll be interested in comments on that.

We proscribed this combination because it yields no security and may 
give folks the illusion of security because, after all, IPsec (ESP) 
is being applied to the traffic flow. We're trying to prevent folks 
from shooting themselves in the foot.

If your environment has a policy that mandates use of IPsec and 
"dynamic keying," then presumably someone believes that access 
control and integrity (or confidentiality or both) are to be employed 
at layer 3 for all traffic.  So I suggest you convince the folks who 
developed the policy that is not appropriate for the apps in 
question, rather than trying to subvert the policy this way.

Steve

---

From: Charlie Kaufman <[email-masked]>
Date: Thu, 9 Aug 2007 11:17:23 -0700

The requirement exists in ESP in order to keep people from accidentally
doing something stupid (or being lured into doing so). No one make a
convincing use case for it, so it seemed conservative to prohibit it in
the spec. This walks a fine line, because NULL encryption *or* NULL
authentication is also often a really bad idea. These are allowed
because they both did have compelling use cases.

There are use cases for having both null. One is for debugging. Another
is where processing capabilities are severely limited on one or both
ends, but there is sufficient processing power to authenticate the
connection setup. There may be cases where the tunneling
abilities of IPsec are desirable (i.e. NAT traversal, red network address
assignment, and traffic selector negotiation) but where security is not
needed (or more likely is provided at another layer (e.g. Web Services
Security)).

Usually in those cases, having cryptographic processing is wasteful of
CPU and bandwidth but is otherwise harmless (and might accidentally end up
adding security). Doing so also enforces a discipline on middle boxes in
that it prevents them from modifying the data in transit (some will
examine the data if it is not encrypted). This discipline is worth
keeping, since otherwise network behavior becomes more unpredictable as
"transparent" middle boxes accidentally break end-to-end expectations.

So far, none of the use cases has been sufficiently convincing to
allow it in the spec. I would be interested to hear whether others have
made their implementations non-compliant in order to get this option,
and if so why. It is possible that some future revision of RFC 4303
could change the prohibition into something that allows exceptions
under specific circumstances if there were sufficient pressure from
the community.

        --Charlie Kaufman

-----Original Message-----
From: Arnaud EBALARD [mailto:[email-masked]]
Sent: Thursday, August 09, 2007 9:18 AM
To: [email-masked]
Subject: [Ipsec] NULL/NULL forbidden in ESP

Hi,

Thanks,

a+

---

From: [email-masked] (Arnaud EBALARD)
Date: Thu, 09 Aug 2007 20:45:42 +0200

Hi,

> Just the prevention of one sending not-so-secure packets.

That's what i thought.

> it's a simple matter of your filtering configs.

Having to put specific filtering rules in the network 

> implementation makes assertions/assumptions around that sentence in section

Static rules on recent Linux kernel just works out of the box (just
tested emission, noone at reception).

> multi-gigabit links or with legacy hardware?  Are you severely latency

Mobile devices with limited CPU and Battery, mainly. I'll try to
benchmark the cost of applying the auth alg on the traffic that does not
need IPsec protection under standard use. It might end up having a
limited impact on battery/load.

Thank you all for the answers. 

a+

---

From: [email-masked] (Arnaud EBALARD)
Date: Thu, 09 Aug 2007 20:56:38 +0200

> because they both did have compelling use cases.
ok.

> needed (or more likely is provided at another layer (e.g. Web Services
Yes, especially if i have the insurance that ESP is usable between end
nodes but not necessarily unencrypted traffic. 

> "transparent" middle boxes accidentally break end-to-end expectations.
interesting point.

> under specific circumstances if there were sufficient pressure from
I would also be interest to know which IPsec stacks support it and which
IKE[v2] daemon supports negotiation of NULL/NULL.

a+