Re: [Roll] Roman Danyliw's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)

Roman Danyliw <rdd@cert.org> Sat, 18 September 2021 21:28 UTC

Return-Path: <rdd@cert.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8373A09F0; Sat, 18 Sep 2021 14:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.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 MqsfcPv6jOzL; Sat, 18 Sep 2021 14:28:36 -0700 (PDT)
Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0137.outbound.protection.office365.us [23.103.208.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38213A09E8; Sat, 18 Sep 2021 14:28:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=I2Vc8dkUwxib6ff6UPgyn0HxB/zHvakWVHtn9yNxAUX2F3AWH7F/YZ1TN5oXUl0rqWHoLqFJcxQvlek4E76lBXKflnhV6/gjqOBb4ai8K3tRovOXizZYPSK+VDhlT0cXbL926G0It3f8G4ig6Z6zwMIHbGDXCFaURtDmY3M0xGrbPVp43pRF1v8DqFWcQt0v95Lqk20qAR99wIRY6x93g5yZJgjftgTgCBZ5iUaOIcwp8dn5bTognJEvAcFV0Spp7cKhRhGUZ9dzh/jzTZD6YiU2okJzMzGDzVn/AyNzMs27+eLE2JwpiIuSR3tGJ3wwsVUEW5lArSNrCTz+DnlZrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cX4ohtY8gJejGdDF6SgdSCvLqbIrPInYmY16qB/wV8w=; b=o2Il/JmszNhXqZigxisJikVEfYQp1B1y49d1JAWrLjcr7GoyJG94KLmoNRBDBEQEDYRTR7ueADUK/t558bFfEEMSHucz5aBk5Q1ZBt3kEdgder4t2mf/y6OMX5wCyApsULo4mJUKCD5MmEwdELu9UBKZkYUgSXjvZaxODTmYTYFL8RTfPnSoA2ca8PDLQ0S07MtGqnKwoRk/L7QUQrKE6mA8Ftm1XwAydMAIFZZpSmHVNfUgrD6ozoWH4d19Ran86i/Cru6ESpDmabc+PehtPAFCT+IKM/H8+dWhKCMVVhgv8In6ek0z9uJsFJKUgw+Vr4Ih01CtF3gAiAp0zjNUGQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cX4ohtY8gJejGdDF6SgdSCvLqbIrPInYmY16qB/wV8w=; b=ES2fDkgufUB49mg7/nauG2bCzNb1PpIToCyj1H1bmQhty9gyAMPvCzt6ohKJqw5v7d9txImyrUE6P12d7O3bB3lDoz2dckt4/4OdmRC6PqBJgPikVlRjPvzMS4QzdcA2AWxqUrRemwmM8nSkoAdYYH12TJelow+vtglx5zt1dns=
Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM (52.145.69.12) by BN1P110MB0100.NAMP110.PROD.OUTLOOK.COM (23.103.22.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Sat, 18 Sep 2021 21:28:33 +0000
Received: from BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::93b:40b5:d4b6:9650]) by BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM ([fe80::93b:40b5:d4b6:9650%5]) with mapi id 15.20.4523.018; Sat, 18 Sep 2021 21:28:33 +0000
From: Roman Danyliw <rdd@cert.org>
To: Charles Perkins <charliep@lupinlodge.com>, Routing Over Low power and Lossy networks <roll@ietf.org>, The IESG <iesg@ietf.org>
CC: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "mariainesrobles@googlemail.com" <mariainesrobles@googlemail.com>, "draft-ietf-roll-aodv-rpl@ietf.org" <draft-ietf-roll-aodv-rpl@ietf.org>
Thread-Topic: [Roll] Roman Danyliw's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
Thread-Index: AQHXNwKjunJS1hLcjEGGiF6NprwFhKt6cSMAgDDIphA=
Date: Sat, 18 Sep 2021 21:28:32 +0000
Message-ID: <BN1P110MB0939368B0FD1E944310B85E0DCDE9@BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM>
References: <161904623841.17653.13314629547868546211@ietfa.amsl.com> <c5de8cf9-dd5d-cfd1-50d6-c0368d3762f0@lupinlodge.com>
In-Reply-To: <c5de8cf9-dd5d-cfd1-50d6-c0368d3762f0@lupinlodge.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: lupinlodge.com; dkim=none (message not signed) header.d=none;lupinlodge.com; dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 10328e20-a587-4492-64a9-08d97aeb4452
x-ms-traffictypediagnostic: BN1P110MB0100:
x-microsoft-antispam-prvs: <BN1P110MB0100950C8CB958989E3A5B2BDCDE9@BN1P110MB0100.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JlpVLCOGtvMT9WYd8CsaH8/amIP4tlScJeYGLLAjNqg1J5Huv75ssq6U1o/dJuOehj821GiJMPT5CSK4Xj/AzQs7Gw3c2wULqBuial/2w4YBddQZFb6SAgUt5X8+2+qWEz/k3yga4dMnc/rEoJZ7KsBHiYYNdLHdkBDlPVw7o5V9HQNgGeBiC0oxEOoq9I/mMNmoqst2S4DxgBvvDr5+jv2783fVval90u5z8vm6bIpw32JhblyVxxI9H826qZedFY8FJkXWPUpEoY6RT7OXxVJlQrzrrlnERpq0R3iymnaxnz/DPRwQWjryEymtUxMg2Zr1FGc3L5tY0c+4ItbTXKRgSfFqA3r0OrlYer0zdLgETpZII1+UMcwqOa1hSMftFz7Blc8m6TWUVo65s00zLDf4BT4TQd3ual3FA2qHC52s1xG/3ZQOUhv/MiL054xfjhLMArZ2VzRNFyohrUT/4qprpINmwjS0j/hOi1FvcoMOCUqFxEaWPS+UAUNKrLaUJZKYzA8pZHhgn7xZOEofjQwC7aLuT2oiV8JW6q9BA7FtPwpg/auZQuJMCsuwmbDP7feBnw35+tGQ+1QblQI/R/mhawwTz/0WRvIERIMGvjh1Ja32EklIWmw5XDq2NzFgY0NkT6pgjRbIyQDUgZMD7O4EYGMELTVJds2X9FscAijMDMx22VFdBILpI3WYFvQhzWOf717Lw5AIUhpiEIWtqBYrKYXYtzTWIDf7j2Ic9aPMqMItbhKTPh/3J1A2Qk2jBcPLnGOl0eKgtHMf9A/czA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(76116006)(966005)(66476007)(316002)(83380400001)(55016002)(64756008)(508600001)(66556008)(110136005)(54906003)(9686003)(38100700002)(122000001)(8936002)(33656002)(66946007)(86362001)(26005)(52536014)(5660300002)(2906002)(4326008)(53546011)(7696005)(38070700005)(66574015)(71200400001)(8676002)(186003)(66446008)(6506007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dk1zcGp0V1hlQXZyRTdHNVFxcnpMVS9lRk1uTlFhUnk4SzdkV1BYL0tKQ2VN?= =?utf-8?B?VE5SMXVweHJUUTlONStRMkF3OUhDK0xoNFAxcUdRbTM5ajhlaVVZbHl6eGwx?= =?utf-8?B?MzBwUHUwT2dFNE9JdlFGNzRjK0RwUEVXd0thK25sSW1uUXlnOVY2eHlOb05x?= =?utf-8?B?RDRBQ0RoaDJ4NlVPQWRMK1FocTdZck9aVEplMGd4N3pPTEUyd2VJQlJFczZP?= =?utf-8?B?VjZnWXhpU3VYVE1GSUY2RGZRQ3UzMWpVN0tIaTlHSUVSc3hBZlI1RFFRSVlY?= =?utf-8?B?a24zc2srWEtRaXNycm5RaWJ5am9hMW91elJwZ3NNYlNyT3FVOXU4NXdWZGFw?= =?utf-8?B?QVN1R291YVB2V3YyM0d4U0pvcEJ4UGNleEEvYjFhRzVPSHRST2JwSzd5OEZs?= =?utf-8?B?dHJFRjlhRkNLZ3dkL3hiR2RqNUcwVUUyL1g1QUpIWGRFV09xcmxnUkpOYkta?= =?utf-8?B?eG1WVXdaa3BZbUZrMGhlb3IrdDNzWDFQSXdqS21ZekxXYUp1Q1BoWTV0a2VY?= =?utf-8?B?ZUtqU25zTDRSbzlGNDlmUWRsYjMwRWo2TiswdXR5eDZQSFVHcjg3UUlmd1Zr?= =?utf-8?B?eGU3OTlJMXA3SlloTTF2T1NadHRPRUdWZ1o5Z0N5VW0xKy9EZGRJNHFOM1Vp?= =?utf-8?B?S1c0elJaRnd3SkQrQ0N5akdkZFRrRnI1WmpsM09MK2xzczEydWRQNGZjMnE3?= =?utf-8?B?MkFHQkkxTDNvTzVVT1hEL1p3VjFaUlZvWW5VOVpnUVE3ZGQ4YmFUVzJrdnh3?= =?utf-8?B?OWdVaW1tSVBZNlNKaDVVajdMRWJTUW1Cc3pmWWdib2d5VzM5eWN4U2tnbzhM?= =?utf-8?B?eWR3aFlDOVg1dFNwVkF1bFl5bTNWdktUTXpqN3EyTUJVNmtWU2tQaGZjRlY3?= =?utf-8?B?bjlpeEV0YVRZbk5rb25WTDl3eWdPYStyTFQ1c0NxbTh0cHYxRlJxdXpQeXB2?= =?utf-8?B?aTJTdUhYSHhCaExVa1VoMzBFeG1mRUU5OEZhbEFDQ05ta0trV3BwVEVQaDdD?= =?utf-8?B?bGFKSmFRWTM3ck95cHA0S2RyclZnRWM2bXUrQjNhTEp6b2xIbEd2U29lbnhC?= =?utf-8?B?KzdINGZYVFhnWnZza056b0ZMa2gyZFE3VmhIREt4aCtvU1ZkY2ZWb0crbnlY?= =?utf-8?B?V3NKbDNISGVqSHNRelRwRXJ0NzFDbmgvRTZ4cGFGczA2WWlpYytqTEVkS04r?= =?utf-8?B?QVZ4dktWNlN6SGpsbEI0c2JCRm1JdmUxSytwK2JXR2F4eEdzZGlZZGszMjRL?= =?utf-8?B?R292SXJXbmdxdktMcGZ1NldpZGJyQ1JmTmVrTVhjNlpNNHFlUnlpRkhnRWtB?= =?utf-8?B?eEhzRGhadWY2Y3hCeDRkUTBIaDQrSHhudUpBZWNjVnR1alRHekJUZG44U0pk?= =?utf-8?B?Sjd1cHhad001U3VVbjZ6YlZjRDdNelppWElDRlhSWEpVZUUwdTIwdTR6S1FC?= =?utf-8?B?a1lKNDhmeHJXLzJrZ1NIUWFBMlhLdXBIeldEK2Vtck9QUDNJbUtxckVlbmdp?= =?utf-8?B?M1hGNmZ3YkgvcTJLR1ZVeVJ3UTRjcUlLYlBqZHkySW9NNjZjaWtrcFVRMCt6?= =?utf-8?B?a29PMG04TENPMC9ycEpuODNVVW1qNENkaHFRYkdwa25ObER4RGQ4bzJDRkhO?= =?utf-8?Q?EKhgpkQiDxT7AwvLk3LwmPtHFwR2zKLcqZbOUQQRY404=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN1P110MB0939.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 10328e20-a587-4492-64a9-08d97aeb4452
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2021 21:28:33.0190 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1P110MB0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/D71GcmD4J7Svo9dVjXHH_iMyicY>
Subject: Re: [Roll] Roman Danyliw's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Sep 2021 21:28:42 -0000

Hi Charlie!

Now my turn to apologize for the long delay.  Thank you for the clarifications below and the changes in -11 to address the COMMENTs.  I've cleared my ballot.

Regards,
Roman

> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Charles Perkins
> Sent: Wednesday, August 18, 2021 4:28 PM
> To: Roman Danyliw <rdd@cert.org>rg>; Routing Over Low power and Lossy
> networks <roll@ietf.org>rg>; The IESG <iesg@ietf.org>
> Cc: roll-chairs@ietf.org; mariainesrobles@googlemail.com; draft-ietf-roll-aodv-
> rpl@ietf.org
> Subject: Re: [Roll] Roman Danyliw's Discuss on draft-ietf-roll-aodv-rpl-10: (with
> DISCUSS and COMMENT)
> 
> Hello Roman,
> 
> Please excuse the unusually long delay it has taken for us to respond to your
> comments.
> 
> Regarding the following:
> 
>  >  Roman Danyliw Discuss
>  > Discuss (2021-04-21)
> 
>  > ** Section 10
> 
>  >    If a rogue router knows the key for the Security Configuration in  >    use, it
> can join the secure AODV-RPL route discovery and cause  >    various types of
> damage.  Such a rogue router could advertise false  >    information in its DIOs
> in order to include itself in the discovered  >    route(s).  It could generate bogus
> RREQ-DIO, and RREP-DIO messages  >    carrying bad routes or maliciously
> modify genuine RREP-DIO messages  >    it receives.  A rogue router acting as
> the OrigNode could launch  >    denial-of-service attacks against the LLN
> deployment by initiating  >    fake AODV-RPL route discoveries.  In this type of
> scenario, RPL's  >    preinstalled mode of operation, where the key to use for a
> P2P-RPL  >    route discovery is preinstalled, SHOULD be used.
> 
>  > Can the normative language in the last sentence please be clarified.  The  >
> entire paragraph prior is describing the behavior of the attacker. Is this  > last
> sentence is suggesting a particular mode of operation?  If the router  > is rogue,
> how is the fact that the key is pre-installed inhibit the behavior  > of the
> attacker?
> 
> We are just referring to normative behavior in a published RFC.  It is not the
> purpose of AODV-RPL to develop new security mechanisms, and so we rely on
> existing specification.  The vulnerability is not new or specific to AODV-RPL.
> 
> 
>  > Comment (2021-04-21)
> 
>  > ** I support John’s DISUSS.  My feedback are also around clarifying what  >
> AODV-RPL inherits from RPL.
> 
> Our response to John addresses this comment.
> 
>  > ** Section 10.  Per "In general, the security considerations for the  >
> operation of AODV-RPL are similar to those for the operation of RPL",  > to be
> clear do all of the considerations from RFC6550 apply? The caveat  > of "In
> general "" doesn’t necessarily suggest that to me.
> 
> "In general" needs to be deleted.  We will identify which considerations do not
> apply, if any.  Since the routing is point-to-point instead of only star-shaped,
> AODV-RPL may have other security threats to be considered in addition to RPL
> security considerations.
> 
>  > ** Section 10.  Unless AODV-RPL is upgrading the requirements of RPL, I  >
> believe all of the referenced security framework is optional. I would  >
> recommend being clear on that:
> 
>  > OLD:
>  > Sections 6.1 and 10
>  >    of [RFC6550] describe RPL's security framework, which provides data
> >    confidentiality, authentication, replay protection, and delay  >    protection
> services.
> 
>  > NEW:
>  > Sections 6.1 and 10 of [RFC6550] describe RPL's optional security  >
> framework, which AODV-RPL rely on to provides data confidentiality,  >
> authentication, replay protection, and delay protection services.
> 
> Thanks for the text.
> 
> 
>  > ** Section 10.  Per  "A router can join a temporary DAG " only if it  > can
> support the Security Configuration in use, which also specifies  > the key I use":
> 
>  > -- Is "Security Configuration" a term of art in RPL to be capitalized?
>  >  I'm not sure if this is editorial feedback or a reference to some RPL  >
> mechanism.
> 
> "Security Configuration" should not have been capitalized.
> 
>  > -- Is this section referring to the processes described in Section 10.2  > of
> RFC6550?  I ask because couldn’t there be an RPL configuration which  >
> doesn’t use secure join (i.e., "unsecured mode" per Section 10.1 of  >
> RFC6550)?
> 
> The security configuration refers to Section 6.1 of RFC6550 entitled "RPL
> Security Fields" for configuring various security variants.  Other RPL security
> configurations might not use secure join.  During AODV-RPL route discovey, a
> router can join a temporary DAG created with any of the security modes of
> operation per Section 10.1 of RFC6550.
> In modes other than "unsecured" mode, a router can join only if it can support
> the security configuration in use, which also specifies the key in use.
> 
> 
>  > ** Section 10.  This section introduces a new acronym "P2P-RPL" not used
>  > in any other part of the document
> 
> That terminology is not needed at all, and is to be deleted.
> 
> Regards,
> Charlie P.
> 
> On 4/21/2021 4:03 PM, Roman Danyliw via Datatracker wrote:
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-roll-aodv-rpl-10: Discuss
> >
> > 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 DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > ** Section 10
> >
> > If a rogue router knows the key for the Security Configuration in
> >     use, it can join the secure AODV-RPL route discovery and cause
> >     various types of damage.  Such a rogue router could advertise false
> >     information in its DIOs in order to include itself in the discovered
> >     route(s).  It could generate bogus RREQ-DIO, and RREP-DIO messages
> >     carrying bad routes or maliciously modify genuine RREP-DIO messages
> >     it receives.  A rogue router acting as the OrigNode could launch
> >     denial-of-service attacks against the LLN deployment by initiating
> >     fake AODV-RPL route discoveries.  In this type of scenario, RPL's
> >     preinstalled mode of operation, where the key to use for a P2P-RPL
> >     route discovery is preinstalled, SHOULD be used.
> >
> > Can the normative language in the last sentence please be clarified.  The
> > entire paragraph prior is describing the behavior of the attacker.  Is this
> > last sentence is suggesting a particular mode of operation?  If the router is
> > rogue, how is the fact that the key is pre-installed inhibit the behavior of
> > the attacker?
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > ** I support John’s DISUSS.  My feedback are also around clarifying what
> > AODV-RPL inherits from RPL.
> >
> > ** Section 10.  Per “In general, the security considerations for the operation
> > of AODV-RPL are similar to those for the operation of RPL”, to be clear do all
> > of the considerations from RFC6550 apply?  The caveat of “In general …”
> doesn’t
> > necessarily suggest that to me.
> >
> > ** Section 10.  Unless AODV-RPL is upgrading the requirements of RPL, I
> believe
> > all of the referenced security framework is optional.  I would recommend
> being
> > clear on that:
> >
> > OLD:
> > Sections 6.1 and 10
> >     of [RFC6550] describe RPL's security framework, which provides data
> >     confidentiality, authentication, replay protection, and delay
> >     protection services.
> >
> > NEW:
> > Sections 6.1 and 10 of [RFC6550] describe RPL's optional security framework,
> > which AODV-RPL rely on to provides data confidentiality, authentication,
> replay
> > protection, and delay protection services.
> >
> > ** Section 10.  Per  “A router can join a temporary DAG … only if it can
> > support the Security Configuration in use, which also specifies the key I use”:
> >
> > -- Is “Security Configuration” a term of art in RPL to be capitalized?  I'm not
> > sure if this is editorial feedback or a reference to some RPL mechanism.
> >
> > -- Is this section referring to the processes described in Section 10.2 of
> > RFC6550?  I ask because couldn’t there be an RPL configuration which doesn’t
> > use secure join (i.e., “unsecured mode” per Section 10.1 of RFC6550)?
> >
> > ** Section 10.  This section introduces a new acronym “P2P-RPL” not used in
> any
> > other part of the document
> >
> >
> >
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll