Address-Protected Neighbor Discovery for Low-Power and Lossy Networks
draft-ietf-6lo-ap-nd-23

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: rfc-editor@rfc-editor.org, 6lo-chairs@ietf.org, draft-ietf-6lo-ap-nd@ietf.org, shwethab@cisco.com, The IESG <iesg@ietf.org>, 6lo@ietf.org, suresh@kaloom.com, Shwetha Bhandari <shwethab@cisco.com>
Subject: Protocol Action: 'Address Protected Neighbor Discovery for Low-power and Lossy Networks' to Proposed Standard (draft-ietf-6lo-ap-nd-20.txt)

The IESG has approved the following document:
- 'Address Protected Neighbor Discovery for Low-power and Lossy Networks'
  (draft-ietf-6lo-ap-nd-20.txt) as Proposed Standard

This document is the product of the IPv6 over Networks of
Resource-constrained Nodes Working Group.

The IESG contact persons are Éric Vyncke and Suresh Krishnan.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/

Ballot Text

Technical Summary

  This document specifies an extension to 6LoWPAN Neighbor Discovery
   (ND) protocol defined in RFC6775 and updated in RFC8505.  The new
   extension is called Address Protected Neighbor Discovery (AP-ND) and
   it protects the owner of an address against address theft and
   impersonation attacks in a low-power and lossy network (LLN).  Nodes
   supporting this extension compute a cryptographic identifier (Crypto-
   ID) and use it with one or more of their Registered Addresses.  The
   Crypto-ID identifies the owner of the Registered Address and can be
   used to provide proof of ownership of the Registered Addresses.  Once
   an address is registered with the Crypto-ID and a proof-of-ownership
   is provided, only the owner of that address can modify the
   registration information, thereby enforcing Source Address
   Validation.

Working Group Summary

 This draft has been extensively discussed in 6lo and some of the crypto experts. Following a workgroup discussion on crypto in the draft and given the nature of crypto expertise required :
 - Rene Struik joined as an author in -08 to help with the crypto details.
 - Russ Housley reviewed -08 and suggested following directions for removing HashEdDSA  based on the decisions in RFC 8410 and RFC 8419 and curdle wg discussion.
 - version 09 of the draft was updated to reference PureEdDSA (instead of earlier EdDSA25519ph). Additional sub-section  Implementation Attacks was added to the Security consideration.
 - version 10 additional updates on the security processing, new security considerations, and organized  3 different schemes for the crypto computation : mixing  NIST P-256   and  Curve25519 (for the curves and   ECDSA and Ed25519) for the signature algorithms, associated with either SHA-256 or SHA-512 for the hash function.
- version 11 as part of shepherd review found that ND option definition can be made explicit, this resulted in the latest version 12.

Document Quality

There are no implementations, but there are vendors have indicated plans to build 6lo defined backbone router as a product that would lead to adoption of this ND extensions.

Personnel

Document Shepherd: Shwetha Bhandari
Responsible Area Director: Suresh Krishnan

RFC Editor Note