Subject: [Hipsec] Null IPsec

From: [email-masked] (Henderson, Thomas R)
Date: Wed Apr 6 19:34:01 2005

=20

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]=20
> Sent: Wednesday, March 09, 2005 3:20 PM
> To: HIP
> Cc: David Ward
> Subject: [Hipsec] Null IPsec
>=20
> Folks,
>=20
> during today's meeting, the chairs got an action point to=20
> talk to the security ADs about the possibility of having a=20
> MUST implement IPsec with null encryption and/or null=20
> integrity protection.
>=20
> I talked to Russ, and his gut reaction was that null=20
> encryption with integrity may be fine, but he would need to=20
> see the use case people have in mind before accepting null=20
> encryption and null integrity.
>=20

We should probably try to close out this issue.

At the WG meeting, I asked whether having ESP as a MUST implement
portion of HIP would constrain future implementations that might not
need to run ESP.  Specifically, I had in mind Secure RTP (RFC 3711).
HIP plus SRTP could be implemented for a VoIP node, without ESP.

IIRC, Pekka pointed out that there is usually required a minimal level
of interoperability specified, and by putting out HIP as a stand-alone
spec with no mandatory transport format, we would violate that tenet.

I then floated the idea of requiring, at a minimum, compliance with ESP
packet formats (with SPIs merely serving as per-packet shim context)
even if the crypto transforms were null.  However, I don't sense any
support for that idea, and I am not sure it is a good idea anyway.  It
violates RFC2406, for instance. =20

Presently, we have the following situation:
i) HIP draft requires implementation of ESP:  "All HIP implementations
MUST implement, at minimum, the ESP transport format for HIP [23]."
ii) ESP draft requires implementation of ESP-AES-CBC with HMAC-SHA1, and
ESP-NULL with HMAC-SHA1.
iii) ESP-NULL is deprecated:  "In addition to AES, all implementations
MUST implement the ESP NULL encryption and authentication algorithms.
These algorithms are provided mainly for debugging purposes, and SHOULD
NOT be used in production environments.  The default configuration in
implementations MUST be to reject NULL encryption or authentication."

Is there sentiment for changing any of these?  At the very least, I
think that iii) is too constraining-- we should not block the possible
use of null encryption with integrity check.  If no one else thinks i)
is a big deal, then I will drop it.  I suppose that a future RFC could
override that statement if needed.

Tom