Re: [Roll] [roll] #144 (applicability-home-building): Missing discussion of link encryption and group keys

"roll issue tracker" <> Wed, 23 April 2014 03:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DE9431A02CC for <>; Tue, 22 Apr 2014 20:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WJO6KYs-atU5 for <>; Tue, 22 Apr 2014 20:13:49 -0700 (PDT)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id 385271A000C for <>; Tue, 22 Apr 2014 20:13:49 -0700 (PDT)
Received: from localhost ([]:44066 ident=www-data) by with esmtp (Exim 4.80) (envelope-from <>) id 1Wcncp-0002si-SL; Wed, 23 Apr 2014 05:13:33 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: roll
Date: Wed, 23 Apr 2014 03:13:31 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 144
In-Reply-To: <>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [Roll] [roll] #144 (applicability-home-building): Missing discussion of link encryption and group keys
X-Mailman-Version: 2.1.15
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Apr 2014 03:13:52 -0000

#144: Missing discussion of link encryption and group keys

Comment (by

 Catherine Meadows comment - 04/22/2014

 "My comment had been that a comparison of link and group key encryption
 was needed.  It looks like
 what you have instead is a summary of the recommended practice for
 wireless/mesh networks, which is to
 use link encryption in which all links are encrypted with the same key,
 which is also used for authentication,
 so that unauthorized nodes can’t join the network, with reference to the
 appropriate RFC’s.  That is fine.

 I had another comment about the danger of having critical components (e.g.
 burglar alarms) sharing keys with non-critical and
 easily misplaced components (such as remotes).  But that is really
 irrelevant to whether you are using link encryption or group keys.  It
 would be better in such a situation to have the two components on separate
 networks.  This is now touched upon in the Deployment Scenario
 Section (last paragraph before 2.1), so I don’t see any reason to bring it
 up here.  However, you might want to mention in the last paragraph
 before 2.1 that having non-critical functions such as gaming on a separate
 network from the control is also a good idea from the point of view
 of security and reliability of the control network.


 Section 6.1

 Wireless networks are typically secured at the link-layer to prevent
    unauthorized parties to access

 should be

 Wireless networks are typically secured at the link-layer in order to
    unauthorized parties from accessing"

 Reporter:                           |       Owner:  draft-ietf-roll-      |  applicability-home-
     Type:  defect                   |
 Priority:  major                    |      Status:  new
Component:  applicability-home-      |   Milestone:
  building                           |     Version:
 Severity:  Active WG Document       |  Resolution:
 Keywords:  Security Review          |

Ticket URL: <>
roll <>