[OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS)
"Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com> Thu, 19 February 2015 15:45 UTC
Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477711A90F6; Thu, 19 Feb 2015 07:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
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 jAbejU0OTmc6; Thu, 19 Feb 2015 07:45:56 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D09611A9152; Thu, 19 Feb 2015 07:43:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150219154359.13340.37635.idtracker@ietfa.amsl.com>
Date: Thu, 19 Feb 2015 07:43:59 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsawg/iSoHLsVsAIW3fVSeyAeG4cW5s5s>
X-Mailman-Approved-At: Thu, 19 Feb 2015 08:09:31 -0800
Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-use-cases.all@ietf.org
Subject: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 15:45:58 -0000
Kathleen Moriarty has entered the following ballot position for draft-ietf-opsawg-coman-use-cases-04: 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft, I just have some security stuff I'd like to discuss that should be easy to resolve as some text is provided. In section 4.5, it is critical to also include a statement on security in addition to privacy. Medical devices with network attachments could be used to kill someone. http://abcnews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justified-experts/story?id=20633284 Suggest changing this text from: In both cases, however, it is crucial to protect the privacy of the people to which medical devices are attached. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. To: In both cases, however, it is crucial to protect the safety and privacy of the people to which medical devices are attached. Security precautions to protect access (authentication, encryption, integrity protections, etc.) to such devices may be critical to protecting the safety of the individual. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. General statement: Many of the other use case scenarios also have safety as a concern, requiring security protections (Confidentiality, Integrity, Availability). Sensors used to control environmental settings is another example where air regulation might include detection of harmful things in the air (carbon monoxide). I'm sure there are other safety concerns that motivate security protections in each of the use cases, it's not just privacy (which is important). What if a sensor was tampered with to report or not report something detected? That's not covered in the discussion on availability related problems in 4.6, but does represent another set of security considerations that could lead to safety issues. More text on access control considerations for NMS may help.
- [OPSAWG] Kathleen Moriarty's Discuss on draft-iet… Kathleen Moriarty
- Re: [OPSAWG] Kathleen Moriarty's Discuss on draft… Sehgal, Anuj
- Re: [OPSAWG] Kathleen Moriarty's Discuss on draft… Kathleen Moriarty
- Re: [OPSAWG] Kathleen Moriarty's Discuss on draft… Ted Lemon
- Re: [OPSAWG] Kathleen Moriarty's Discuss on draft… Sehgal, Anuj
- Re: [OPSAWG] Kathleen Moriarty's Discuss on draft… Kathleen Moriarty