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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 27 August 2020 20:38 UTC

Return-Path: <pthubert@cisco.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 496CA3A12D8 for <rtg-dir@ietfa.amsl.com>; Thu, 27 Aug 2020 13:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IDtJZ7XK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EfqLvMmg
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 Sc9uBJAWxpi7 for <rtg-dir@ietfa.amsl.com>; Thu, 27 Aug 2020 13:38:24 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B313A12D5 for <rtg-dir@ietf.org>; Thu, 27 Aug 2020 13:38:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22153; q=dns/txt; s=iport; t=1598560704; x=1599770304; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=O1+0Hwm5Vk2RLILey9uBud2N7QkRrddqaQs+JUj5CE0=; b=IDtJZ7XKho8tbWenDbmLv6qtwKUsFaqqPMQJ8A4PPz05puxqKI9L7++E lvocdbI9/1AltrcF+jJGuXPvTIx1Tk9LhTfrXz3cp2hu7MUTa+f4emiSs KXJTw+CYAjIj46VHQghnkTSeFFhzf+e3WyhOIx+IsPVVbiaWBolrkkN8z U=;
IronPort-PHdr: 9a23:noJX/hAASRbX69U9RbnaUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qw00A3GWIza77RPjO+F+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGF8P3ZlmUqXq3vnYeHxzlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CVBQDYGEhf/5ldJa1gHAECAgEHARQBBAQBgguBIy9RB3BYLyyEN4NGA41yiguJeIRuglMDVQsBAQEMAQElCAIEAQGETAIXgjICJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAwESER0BATcBBAsCAQYCDgMEAQEoAwICAh8RFAkIAgQOBSKDBAGBfk0DDiABDpc6kGgCgTmIYXaBMoMBAQEFgTcCgRKCaw0LghADBoE4gnGCV0tDSjiBQoFAgksbgUE/gREnHIJNPoIaQgEBAgGCCQmCYTOCLZJUPYZpi2iPcjdRCoJjiGaMRIUDAxUJmkyFeZ0XgmaNcoQoAgQCBAUCDgEBBYFrI4FXcBVlAYI+UBcCDZIQhRSFQnQ3AgYBCQEBAwl8j3UBAQ
X-IronPort-AV: E=Sophos;i="5.76,361,1592870400"; d="scan'208,217";a="565840562"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2020 20:38:23 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 07RKcNH5020831 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2020 20:38:23 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 15:38:22 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 16:38:21 -0400
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 27 Aug 2020 15:38:21 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RtSd7OlHJoRiv6oEqguy7/HUE1pnT6O2DH8FeBRG2hcI0J4ED7NzehMpqbty0sU1jyvjml5pgdAbn0nHLEMxpEGKYXqF3JeywOE88A+xa2PKlsmV/Aj4WFeJEBfjoLGerAirsfx7XoKFiB6wrD97fyJKxXqlNqc/EK6wRBkX6Cry62uNOpuyIwjoD8UOBQGLtmYU4/5XwKbeIo/lZSkV2PiVPZzdxvxB8jUJI5zYe10FMU4x5bKfZnMvdCALKva3BRDY6fXUl0OTwP8Zp5P9FgakxviBeQKy+w8LCosM4Zegue8e28CGP2xweC3DtXzWz1yKixNAopGJHzRmOggt0Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O1+0Hwm5Vk2RLILey9uBud2N7QkRrddqaQs+JUj5CE0=; b=f6fZ3UkyYseY+3pAsdnRy4UzcS38klIrd3ceCOZ9bBpGvKc+nz86aKhNUPkwKZvtyDYt5mwBGIaZX5GpOWtcA6xyzYY2IJ2/s6bF34BDjifo7AgX0v/Pxx5Db9iWUkPqXy+LkPMt2324R+JTZwXCNYwPp8EP3UHc3rI8TxxALlZ1phahfTKdKjBBfQEnD+yuqbmrqbIGeZ7171nBuJZeBRzoTbPQHJfTDY0+oemwt/ZXPXQZYpgf3z/d5YkfTaXy1aCLqCn8kfKG0WN0FuikcxyEV5HT5VOzpHchCJiAxxd6+OpzXJNmYe7fx4UspGaw2rjyJoJ5OTuW3j2QGbXkcA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O1+0Hwm5Vk2RLILey9uBud2N7QkRrddqaQs+JUj5CE0=; b=EfqLvMmgAgKdE5Ur8Wcb+9Lc5KWOBb94kiK1js16PEQ19Pf17SA11bWkB0KbAwaHJLXuGImCjTwh4GCHFWITE3kN/A8NBLXPEjEWZ+8mayoevA/cqmsAU1j7pdFQ2E+8yoOWZeWQ/eqrjZ4Y1GE5vEMmxAkkXhoXR3cQE0QPzIg=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3917.namprd11.prod.outlook.com (2603:10b6:208:135::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Thu, 27 Aug 2020 20:38:20 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::40e1:2d7d:1a3:cf8a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::40e1:2d7d:1a3:cf8a%3]) with mapi id 15.20.3305.032; Thu, 27 Aug 2020 20:38:20 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
CC: Stewart Bryant <stewart.bryant@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Thread-Topic: [RTG-DIR] Rtgdir last call review of draft-ietf-roll-turnon-rfc8138-10
Thread-Index: AQHWfIh/iWFkC6nI2kOTIh6SNvGeE6lMLZyQgAAFNgCAAAMmIIAAJhGAgAAO4wA=
Date: Thu, 27 Aug 2020 20:38:20 +0000
Message-ID: <ECDE63C1-1CC9-4A73-96C2-03AB453014B7@cisco.com>
References: <CAMMESsyZ2_THfcWS73nbBKyCAktmmejQZAHwauGTj4vu-x8P8Q@mail.gmail.com>
In-Reply-To: <CAMMESsyZ2_THfcWS73nbBKyCAktmmejQZAHwauGTj4vu-x8P8Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:418b:eefe:576e:7eae]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 301efe70-fc57-4d97-1a6a-08d84ac9229c
x-ms-traffictypediagnostic: MN2PR11MB3917:
x-microsoft-antispam-prvs: <MN2PR11MB39179C7366040C69DC3497C2D8550@MN2PR11MB3917.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5YuSiW0zPV6FE9PtZH7XDMBXMM3hTvCRQwSd0jNISwmZoJb71BznhgI38ogtzr+NqJlfSG7OqTPzsuFN5ZdBSFE+LzQ+sQFBa1h836K5FD038P1iYXwt+fR+Dr4A1tFIqZLXTdR8v9tUhwvSQ2GOUZLBDIbl9kUQ9diVS8qvfmDcztWylqYfmJqKKafYh8hZX8m0kRNFg2Mj1VhZejj/wZG0L80af3qrb1fL6z/BEhRZkSgu7zPO5qnp24GsnsWr//pF4ZaX4dy6InqqFXWsHcz6Xm49MwmoOIGxujoDRsosIcAhYR6sdmw809eY8ErcFeH6WqlaLOXFbObVX7ZwM8+nIOZeWW7sJqLdZrs/R9UN0w1enEvNbyidc/vntGZMyG5RdUh9f/GpGvW9mx+Gf7tMWDhGxnZuc8VOlvW9mZ0SlFXkUHe8f5Rjr3GJNWMQU7qQU2q0S9RMB6PxLoqOCEx+O/8NYA2I+ue172tqPu2IeWPZ1RslWz+M7uDPbnvDKahc400YBSmgGx63XseSlA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(366004)(136003)(346002)(39860400002)(2906002)(83380400001)(966005)(91956017)(186003)(166002)(4326008)(64756008)(66946007)(66574015)(6506007)(76116006)(66476007)(5660300002)(66556008)(66446008)(316002)(6512007)(53546011)(8936002)(6486002)(478600001)(33656002)(54906003)(71200400001)(86362001)(2616005)(36756003)(6916009)(8676002)(244885003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: VwcmdJqZugVv40GAO3bHVOpHFiE3VCMSGYmGhqhYpavnjpljjcokojR07IWSqfFo5Z2d3EOgu6B6yKFugxHivNKUngkmHyE/AwwChw/wLM+Q4s1U9sLJeVnj5mMbyfvrsV5ld2uTeKZxNOOB55ALquGm5ZR3Xio0dNN6v+PmUP8bZMetRDKpG9Lv9N3M3kam6+7YQe8hnHrmbISiPMEytqyVTgr/jNwJtrGbDUAYCQ0qFvsZmUN/UnK7e/KOEoy33W1lph5SA6AqQWI1I40oJ6AJUnJmQ25xfvan95KyNh6kc/fdI2gkgWz+S/p990jawj5OKTEGnctFQBSHtOWBAjQcwz7jSDc9ttRgQAgsTnXamYbhuKJpfLdj8PCVRfnQ4TiyRGY/VTNjlfzdaFssHmbXtJd3fewm6Q55QVFIvUerccQUrS1fXZYD/qEPL1ib5zs3rRSOQ93ZnQuo4yn3EUX00GZrLOmHChaRpI6AvEUSN7IFLHSOE63gnNxkuRm6MNR0B1LwWB9xZ0O/toweQvfD3lv2VDP+wgfkIQXuZz1KqL/H59xLRL+LkMT+VECXcL8Z1A5RhsHzHCUd6jqwPKOvlVyFUrxhzdmHPV8zWXrUkZs3wc1Afkj8fs/NF94VggWxlsseKzyIyOXpJQz3WZkPZkn1KRhYMaI1pW3Fx600YHO1EbuYLcd+mdi6ruByI9461qah18ZD5RTUcgj8Tw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_ECDE63C11CC94A7396C203AB453014B7ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3565.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 301efe70-fc57-4d97-1a6a-08d84ac9229c
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 20:38:20.1443 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qecKcEadAQ8lT0dQXq9eOsWkvoRW3OVNebllGIKwfrqcwodYv4UYlRSyfCMKXjlBaKywxompKfOvjUZMg//6Iw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3917
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/9lGsLsCWRvJhKoYuDZ6NAa5u0d4>
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 20:38:26 -0000

Hello Alvaro

The point is if the security measures in RPL are not turned on, it’s either L2 security or none at all.

Shouldn’t we mandate L2 security in that case?

The quote from NP DAO is imprecise in that the security section in RPL only discusses the secured modes.  RFC 6550 says nothing in case of unsecured because we expected secured. It fails to recommend L2 security. The NPDAO text this inherits that gap.

The real world decided otherwise  and uses L2 security ubiquitously. Shouldn’t we reflect that ? Saying that we expect RPL security is a denial of the world around us.

So I’m good with your proposal but I feel the gap should be closed somewhere.  Agreed this is but a side spec, but then where should that be?

Take care,

Pascal

Le 27 août 2020 à 21:45, Alvaro Retana <aretana.ietf@gmail.com> a écrit :


Pascal:


The link-layer security is a mechanism that applies to all the RPL messages.  It doesn’t just apply to messages associated with this document.  Making it required (or even just normatively recommending it) in this document feels like overreaching because we’re just defining a flag, not changing how the RPL adjacency works.

I rather go with something akin to the Security Considerations in, for example, draft-ietf-roll-efficient-npdao (also approved by Ben)…which is where I borrowed the "This document assumes that the security mechanisms as defined in [RFC6550] are followed…” phrase from.


BTW, we should at least point the reader to the Security Considerations in rfc6550 and rfc8138.


Thanks!

Alvaro.




On August 27, 2020 at 1:45:09 PM, Pascal Thubert (pthubert) (pthubert@cisco.com<mailto:pthubert@cisco.com>) wrote:
Hello again Alvaro

We had a pass on similar text (with Benjamin K.) for the IESG review of https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-21 (now in RFC ED queue) and ended up with

   As indicated in [FRAG-FWD<https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-21#ref-FRAG-FWD>], Secure joining and the Link-Layer
   security are REQUIRED to protect against those attacks, as the
   fragmentation protocol does not include any native security
   mechanisms.

Indeed this requirement is common to anything 6LoWPAN or RPL. And MUSTing it in the form above seemed to reach consensus.
In the case of RPL alone it’s either as above or one of RPL’s secured modes, preinstalled of authenticated. RPL’s security section discusses the last to but does not really say what to do with Unsecured. We could fill that gap.

What about combining all this as:
“
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 RPL exchange are protected against on-link attacks such as forged and replayed packets.
Section 10 of [RPL] proposes 3 security modes, Unsecured, Preinstalled and Authenticated.
In the Unsecured Mode, secure joining and the Link-Layer security are REQUIRED to protect against those attacks.
“

Keep safe,

Pascal
From: Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>>
Sent: jeudi 27 août 2020 19:18
To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>
Subject: RE: [RTG-DIR] Rtgdir last call review of draft-ietf-roll-turnon-rfc8138-10

Sure…

I just to want to recommend anything that is not already specified somewhere else for RPL.  :-)


On August 27, 2020 at 1:05:39 PM, Pascal Thubert (pthubert) (pthubert@cisco.com<mailto:pthubert@cisco.com>) wrote:
Hello Alvaro 😊

I see your point.

> 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.

This should be clarified a little bit. RPL has a security mechanism that to my best knowledge no one uses (https://tools.ietf.org/html/rfc6550#section-10).
What everyone uses is a Layer 2 access security. The text above seems to recommend to use RPL's secured mode. Is there a way to reword that a bit?

Take care,

Pascal