54th IETF Meeting - SEcuring Neighbor Discovery BOF (send)

agenda@ietf.org Thu, 11 July 2002 22:19 UTC

Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09504; Thu, 11 Jul 2002 18:19:51 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id SAA28080 for ietf-123-outbound.10@ietf.org; Thu, 11 Jul 2002 18:15:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id MAA24121 for <all-ietf@loki.ietf.org>; Thu, 11 Jul 2002 12:03:42 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22659; Thu, 11 Jul 2002 12:02:48 -0400 (EDT)
Message-Id: <200207111602.MAA22659@ietf.org>
To: IETF-Announce:;
From: agenda@ietf.org
cc: new-work@ietf.org
Subject: 54th IETF Meeting - SEcuring Neighbor Discovery BOF (send)
Date: Thu, 11 Jul 2002 12:02:48 -0400
Sender: dinaras@cnri.reston.va.us

SEcuring Neighbor Discovery BOF (send)

Tuesday, July 16 at 1700-1800
==============================

CHAIRS: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
        James Kempf <kempf@docomolabs-usa.com>

DESCRIPTION:

In draft-kempf-netaccess-threats-00.txt, attacks on IPv6 Neighbor
Discovery are defined for public access networks where the last hop is a
multi-access link. These threats are not mitigated by link level
authentication mechanisms, such as 802.1x or PPP, because the attacks
can be carried out by authenticated hosts. In addition, while the
threats are valid for both wired and wireless networks, wireless
networks are particularly vulnerable because access cannot be controlled
through securing the physical premises.


Various solutions have been proposed to securing IPv6 Neighbor
Discovery. RFC 2461 proposes using IPsec for securing Neighbor
Discovery, but the actual details of how to do it are left as an
exercise to the reader. draft-arkko-manual-icmpv6-sas-00.txt proposed
manual IPsec configuration for securing link local messages. IKE or
other automatic key establishement protocols that involve Neighbor
Discovery are excluded, since they suffer from bootstrapping problems,
though key distribution using link layer AAA protocols such as 802.1x
remain a possibility. draft-kempf-secure-nd-00.txt proposes using
identity-based cryptography with the routing prefix and interface id as
the public identifiers. Other techniques that might be used are
Cryptographically Generated Addresses (CGA, see
draft-roe-mobileip-updateauth-01.txt for an application to Mobile IPv6
Binding Update security).

This BOF will discuss the threat and proposed possible solutions and
will formulate a proposed charter for a working group to standardize
security measures for IPv6 Neighbor Discovery.

Agenda

5 min.  Agenda Bashing
10 min.  Problem Statement (including brief description of threats)
10 min.  IPsec solution
10 min.  proposed nonIPsec solutions
25 min.  Discussion on WG charter

Strawman Work Items and Schedule

July 2002 - Form a small design team of people with expertise in IPsec
and in other possible security algorithms to examine the feasibility of new
IPsec policy, removing the need for manual keying, to use IPsec for ND
security.

August 2002  Complete draft-kempf-netaccess-threats.txt with a short
description of which threats will be addressed and which won't.

September 2002  After mailing list discussion, complete a draft of other
requirements for a solution.

November 2002  IPsec feasibility design team report complete.

November 2002  Begin protocol design.
     If IPsec policy changes required, co-ordinate with
        IPsec working group and IESG as to how to proceed.
     If new protocol required, define extensions to ND to
        allow various cryptographic algorithms and examine
        candidate algorithms for selecting a default.

March 2003  Completed protocol design(s).

July 2003  End of Working Group.


References:

RFC 2461
draft-kempf-netaccess-threats-00.txt
draft-arkko-manual-icmpv6-sas-00.txt
draft-roe-mobileip-updateauth-01.txt