[6lo] Alvaro Retana's No Objection on draft-ietf-6lo-ap-nd-17: (with COMMENT)

Alvaro Retana via Datatracker <noreply@ietf.org> Tue, 04 February 2020 22:41 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-ap-nd@ietf.org, Shwetha Bhandari <shwethab@cisco.com>, 6lo-chairs@ietf.org, 6lo@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <158085606697.15785.1980731784696257986.idtracker@ietfa.amsl.com>
Date: Tue, 04 Feb 2020 14:41:06 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/tRvDga_mGHQ-AdtWp6E3xnLz5bo>
Subject: [6lo] Alvaro Retana's No Objection on draft-ietf-6lo-ap-nd-17: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-6lo-ap-nd-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) The first sentence in the Abstract reads: "This document updates the
6LoWPAN Neighbor Discovery (ND) protocol defined in RFC 6775 and RFC 8505."  It
gives the impression that both RFCs are formally Updated, but document itself
(and the header) make it clear that only rfc8505 is in fact Updated.  IOW, the
Abstract is a little confusing.

Suggestion>
   The 6LoWPAN Neighbor Discovery (ND) protocol is defined in RFC 6775 and RFC
   8505.  This document updates RFC 8505 by defining a new extension called
   Address Protected Neighbor Discovery (AP-ND) which protects...

(2) §5.3 of rfc8505 has the following text related to collisions:

   Note regarding ROVR collisions: Different techniques for forming the
   ROVR will operate in different namespaces.  [RFC6775] specifies the
   use of EUI-64 addresses.  [AP-ND] specifies the generation of
   cryptographic tokens.  While collisions are not expected in the
   EUI-64 namespace only, they may happen if [AP-ND] is implemented by
   at least one of the nodes.  An implementation that understands the
   namespace MUST consider that ROVRs from different namespaces are
   different even if they have the same value.  An

Even if this document updates rfc8505 to specify "the RECOMMENDED method for
building a ROVR field", there may be nodes in the LLN that don't support it.  I
would like to not only see text about explicitly recognizing the possibility of
collisions in mixed networks, but also deployment considerations related to the
incremental implementation of the extension.

(3) Nits:

s/allow the an attacker/allow an attacker
s/forwarding an IPv6 packets/forwarding IPv6 packets

[6lo] Alvaro Retana's No Objection on draft-ietf-… Alvaro Retana via Datatracker