Re: [RTG-DIR] Rtgdir last call review of draft-ietf-roll-turnon-rfc8138-10

Alvaro Retana <aretana.ietf@gmail.com> Thu, 27 August 2020 15:41 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6103B3A0ECA for <rtg-dir@ietfa.amsl.com>; Thu, 27 Aug 2020 08:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlhaE7-fx31J for <rtg-dir@ietfa.amsl.com>; Thu, 27 Aug 2020 08:41:04 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E32C3A0F3C for <rtg-dir@ietf.org>; Thu, 27 Aug 2020 08:41:03 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id j25so8266748ejk.9 for <rtg-dir@ietf.org>; Thu, 27 Aug 2020 08:41:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=kpLE8rrvmKpvOUnjJj6VV1ZMFPmJ86VpX5/jqZPbkCg=; b=P+Wyc4b5ZQ82Q4Us+W9g869jQdv2A9Mk6K+cp2CJ69PIDmu55A5oclQ1EI4OeFCkdJ tDPk/b4MmS3DeLSL/zKt4qOLc8sKRDbQ+dFTVzyQKB8sReIuzIH3bonh/BvJSFtT07mI DlCWPLn0sEDlBsnDCEpdFwNDnxGT8TlX7tYdRbfT2GqLHmAJyCoT9qO6yugniZstyfgD dcpfJhzP1BZiZb5pbh1U/zBhdMV1ZVwwi/Dms7ekZwyHloMkWHV5BGraHAO4RKFNSzcS ZvCYrsJ4kGfkU4IYp3hHzXMrBChdUSiXCOevGqjMISdK1FW31HiFsqlyK3d1SVndxNTK qtLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=kpLE8rrvmKpvOUnjJj6VV1ZMFPmJ86VpX5/jqZPbkCg=; b=ENw4OpBiY0DDSRDutTBdTYnXM0HD8LnXM+z0htlZV6Gk/QyohwirgowWBkfLTBHKjm gw8f4GEPOO6HJBqLDVd1D3L+/+sXVFSj/XmPBEl0Dwle6//CXC5U+S2b3xFlf9tqPxM5 0B9e1YUXueFqMbPy3YjkWjnHJgvAid6b7u2FxdZpEOGtkouzvE9ZVKYC9LcSnZwGnvAI UwB3hwsymHCU9UY/199gXKbsHbRnRqGi68SyxZ+G6QovaFSj//1eOZncsnam6g2qcP9X 98IEBhYSAOG3Ti4QECuXjKd5b5yfWYKo1lvx3L23ivdte3LigkCwRsNL9jh+54mQf4ka lHAw==
X-Gm-Message-State: AOAM530Qnbv5GSDDpYdTnGM6eh/4oEHSuTRCcwnJ+uu9I0G+JxMyth/r htfNXbq55Gi+9PjKbAP2/fayW07Pjdw1d4ESad4=
X-Google-Smtp-Source: ABdhPJz3EZw+bDfk9ix5p5/5iAaUVCo/Q1Q7WBOAJXvZlMPIvKSD+QDpZKewwAK3TsVIuvms/vIN09NV3DqbgoyLcKA=
X-Received: by 2002:a17:906:b20c:: with SMTP id p12mr21301990ejz.300.1598542861874; Thu, 27 Aug 2020 08:41:01 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 27 Aug 2020 08:41:01 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <MN2PR11MB35650CDF364323901C9227F8D8550@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <159743131948.29404.7285894923089059952@ietfa.amsl.com> <MN2PR11MB3565D36B4FB2E9D40EFCD400D85C0@MN2PR11MB3565.namprd11.prod.outlook.com> <MN2PR11MB35650CDF364323901C9227F8D8550@MN2PR11MB3565.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Thu, 27 Aug 2020 08:41:01 -0700
Message-ID: <CAMMESswxHfZ2RTL69pfAZYSXQgu3gE2ZwvKOE+QFxWQa40jJ+g@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/GhUVSVFsepWmKhNEvIikZpUPBDI>
Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-roll-turnon-rfc8138-10
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2020 15:41:05 -0000

On August 27, 2020 at 8:03:52 AM, Pascal Thubert wrote:


Hi!


> I just published 11 that has the proposed changes below

Looking at those changes, there's only one thing that doesn't work for me.


...
> > 7. Security Considerations
> >
> > First of all, it is worth noting that with [RFC6550], every node in
> > the LLN that is RPL-aware can inject any RPL-based attack in the
> > network. A trust model has to be put in place in an effort to
> > exclude rogue nodes from participating to the RPL and the 6LoWPAN
> > signaling, as well as from the data packet exchange. This trust
> > model could be at a minimum based on a Layer-2 Secure joining and the
> > Link-Layer security. This is a generic RPL and 6LoWPAN requirement,
> > see Req5.1 in Appendix of [RFC8505].
>
> > SB> I am surprised there is not a MUST in the above considering the
> > vulnerability.
>
> True, changing to
> "
> A trust model is REQUIRED in an effort to exclude rogue nodes...
> "

The resulting paragraph now reads:

   First of all, it is worth noting that with [RFC6550], every node in
   the LLN that is RPL-aware can inject any RPL-based attack in the
   network.  A trust model is REQUIRED in an effort to exclude rogue
   nodes from participating to the RPL and the 6LoWPAN signaling, as
   well as from the data packet exchange.  This trust model could at a
   minimum be based on a Layer-2 Secure joining and the Link-Layer
   security.  This is a generic RPL and 6LoWPAN requirement, see Req5.1
   in Appendix of [RFC8505].


Normatively requiring a trust model in this document doesn't work for
me for several reasons:

(1) The text points at a vulnerability present in all rfc6550
deployments, not something new to this document.  The paragraph is
used to set up the discussion in the rest of the section.

(2) There is no specific trust model to test compliance with; instead,
the text is tentative: "trust model could at a minimum be based
on...".  If we're going to make something REQUIRED, then we should be
able to point at what that is.

(3) The last sentence says that the trust model is already a "generic
RPL and 6LoWPAN requirement", which supports, even more, the point
about the issue not being specific to this document.


These reasons, and the fact that authorization doesn't prevent a node
from becoming rogue, led me to initially suggest not using MUST (in my
review of -07).

Having said all that, we should also explicitly point at the security
of the base spec.  I would even go for something simpler:

Suggestion>

   It is worth noting that with [RFC6550], every node in the LLN that is
   RPL-aware can inject any RPL-based attack in the network.  This document
   assumes that the security mechanisms as defined in [RFC6550] are followed.


Thanks!

Alvaro.