[IPsec] NIST's Guidelines for secure deployment of IPv6

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 04 January 2012 14:12 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF8C21F866D for <ipsec@ietfa.amsl.com>; Wed, 4 Jan 2012 06:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level:
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf5rNdVBQFYW for <ipsec@ietfa.amsl.com>; Wed, 4 Jan 2012 06:12:31 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BBE8B21F84FF for <ipsec@ietf.org>; Wed, 4 Jan 2012 06:12:31 -0800 (PST)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q04ECReB016168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <ipsec@ietf.org>; Wed, 4 Jan 2012 08:12:29 -0600 (CST)
Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q04ECQg0023124 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <ipsec@ietf.org>; Wed, 4 Jan 2012 19:42:27 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 4 Jan 2012 19:42:26 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: IPsecme WG <ipsec@ietf.org>
Date: Wed, 4 Jan 2012 19:42:24 +0530
Thread-Topic: NIST's Guidelines for secure deployment of IPv6
Thread-Index: AczK6uF/sV4X1s36QyGLlmSov1Rk8A==
Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2AE1@INBANSXCHMBSA1.in.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: [IPsec] NIST's Guidelines for secure deployment of IPv6
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2012 14:12:32 -0000

NIST has published the "Guidelines for secure deployment of IPv6" and it unequivocally says that AH has fallen out for ESP-NULL.

One can go through the document in detail. I have not gone through the entire document but here are some excerpts from that document:

(1) It says the following for OSPFv3:

"With routing protocols, routing integrity is usually a greater concern than confidentiality. The ESP 
parameter NULL indicating no encryption is generally regarded to be an acceptable choice for OSPF 
security."

(2) 4.2.4 Unresolved Aspects of IPv6 Multicast

"The security recommendations for PIM call for using IPsec AH, even for unicast messages.  Where IPsec 
is used with IPv4, AH has generally fallen out of use in favor of ESP, with NULL encryption when 
authentication-only is desired.  Thus the IPsec standard (RFC 4301) no longer requires AH, and many 
implementations omit it. See Section 5.3.6 for additional discussion of this topic."

(3) 5.3.1 Specification Overview

"Two security protocols: Authentication Header (AH) and Encapsulating Security 
Payload (ESP).  AH can provide integrity and replay protection for packet headers and data, 
but it cannot encrypt them.  ESP can provide encryption, integrity, and replay protection for 
packets, but it cannot protect the outermost IP header, as AH can.  This protection is not 
needed in most cases.  Accordingly, ESP is used much more frequently than AH because of its 
encryption capabilities, as well as other operational advantages.  The latest IPsec specification 
states that implementations MAY implement AH, and many choose not to.  For a VPN, which 
requires confidential communications, ESP is the natural choice."

And the below is the most interesting:

(4) 5.3.6 Unknown Aspects

"A debate exists over whether to use AH or ESP with NULL encryption for IPsec packets requiring
integrity protection but not confidentiality.  The standards themselves do not answer the question: IPv6 
standards tend to recommend or require AH, whereas IPsec standards have downgraded AH from MUST 
implement to MAY implement.  OSPFv3 originally specified AH, but this has been changed to ESPNULL.  
Some implementations only provide ESP.  AH has not been widely deployed.  (The common 
IPv4 applications of IPsec-VPNs and secure remote access-usually provide confidentiality, so this 
question does not arise.)  AH may also require more processing steps to compute or verify the integrity 
check value.  On the other hand, one of the main arguments in favor of AH is that it makes it easier for 
devices such as packet filtering routers, firewalls, and intrusion detection systems to recognize plaintext 
and examine packets (because ESP-NULL transmits plaintext but gives no visible indication that the 
payload is unencrypted).  As far as the cryptographic protection provided by AH versus ESP, it is difficult 
to discern any tangible difference when IPsec is used as intended.  In some cases, AH may protect certain 
vulnerable parts of the header or extension headers, but these cases are rare, and in these few cases, 
ESPNULL can achieve the same effect by being run in tunnel mode."

(5) 5.4.1 Using IPsec to Secure Autoconfiguration and ND

"AH was downgraded to MAY in RFC 4301 and is not included in many implementations."

Cheers, Manav