[IPsec] IPv6 Address resolution on IPsec node

Tero Kivinen <kivinen@iki.fi> Wed, 14 April 2010 15:02 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D66A28C266 for <ipsec@core3.amsl.com>; Wed, 14 Apr 2010 08:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level:
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfs03cWSQ+qC for <ipsec@core3.amsl.com>; Wed, 14 Apr 2010 08:02:01 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9B81228C28F for <ipsec@ietf.org>; Wed, 14 Apr 2010 08:01:46 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o3EF0mNM025801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Apr 2010 18:00:48 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3EF0m6L022910; Wed, 14 Apr 2010 18:00:48 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19397.55456.596478.752413@fireball.kivinen.iki.fi>
Date: Wed, 14 Apr 2010 18:00:48 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Thamilarasu Kandasamy (thamil)" <thamil@cisco.com>
In-Reply-To: <0D25A594A60CDD45A1A00FCD1F88E7F8026126F9@XMB-BGL-414.cisco.com>
References: <0D25A594A60CDD45A1A00FCD1F88E7F8026126F9@XMB-BGL-414.cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 6 min
X-Total-Time: 8 min
Cc: ipsec@ietf.org
Subject: [IPsec] IPv6 Address resolution on IPsec node
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 14 Apr 2010 15:02:02 -0000

Thamilarasu Kandasamy (thamil) writes:
> IPv6 nodes use Neighbor Discovery messages for address resolution as
> defined in RFC 4861.  However on an IPv6 node having IPsec
> implementation, if there is an SPD entry with a selector that covers all
> IP traffic, Neighbor Discovery messages could potentially be discarded
> (especially during system reload) and IKE negotiation be initiated.  But
> this would eventually fail as the node haven't yet determined the
> link-layer address for the given IPv6 address.  The RFC 4301 is not
> explicit about  according any 'special' treatment to Neighbor Discovery
> messages.  Like in case of IKE messages, we shall make provisions for ND
> messages to bypass IPsec protection?  Would appreciate feedback/comments
> from the working group!

RFC4301 says that all kind traffic goes through SPD, including
management traffic , which includes also IPsec management traffic such
as IKE. 

This means that your SPD needs to explictly have passby rules for
local management traffic, i.e. things like dhcp, neighbor discovery,
router advertisement, router solication, IKE (both IPv4, and IPv6, and
both normal IKE, and NAT-T IKE port).

So all of those rules should be like just normal IPsec SPD rules, they
should not be hardwired to the system (you can of course provide easy
way to add all of those, for example if you do not turn "no default
management rules" option on, then all of those rules are added
automatically when you start your IPsec service).
-- 
kivinen@iki.fi