[NSIS] Re: More IESG Review of draft-ietf-nsis-req-08.txt - Comments 2
Marcus Brunner <brunner@ccrle.nec.de> Wed, 23 July 2003 16:43 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19266 for <nsis-archive@odin.ietf.org>; Wed, 23 Jul 2003 12:43:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMhh-0002hH-Bw for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 12:43:01 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NGh1rl010362 for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 12:43:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMhg-0002gc-Vi; Wed, 23 Jul 2003 12:43:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMgy-0002g7-PN for nsis@optimus.ietf.org; Wed, 23 Jul 2003 12:42:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19227 for <nsis@ietf.org>; Wed, 23 Jul 2003 12:42:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fMgx-00063K-00 for nsis@ietf.org; Wed, 23 Jul 2003 12:42:15 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19fMgm-00063A-00 for nsis@ietf.org; Wed, 23 Jul 2003 12:42:04 -0400
Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6NGfSVI014534; Wed, 23 Jul 2003 18:41:28 +0200 (CEST)
Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D169BB6DEF; Wed, 23 Jul 2003 18:21:33 +0200 (CEST)
Date: Wed, 23 Jul 2003 18:41:28 +0200
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
To: Allison Mankin <mankin@psg.com>, smb@research.att.com
Cc: john.loughney@nokia.com, nsis@ietf.org
Message-ID: <30533605.1058985688@[10.1.1.130]>
In-Reply-To: <E19Vl3d-000Oy2-VM@psg.com>
References: <E19Vl3d-000Oy2-VM@psg.com>
X-Mailer: Mulberry/3.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Subject: [NSIS] Re: More IESG Review of draft-ietf-nsis-req-08.txt - Comments 2
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
--On Donnerstag, 26. Juni 2003 21:41 -0700 Allison Mankin <mankin@psg.com> wrote: > > Steve Bellovin also had comments on the NSIS Requirements draft: > > Section 3 effectively rules out any requirement for security within a > domain. I don't think that's right. > That's definitely not right. I assume you refer to point 5 of section 3: 5. We can see the network at the level of domains/subdomains rather than individual routers (except in the special case that the domain contains one link). Domains are assumed to be administrative entities, so security requirements apply to the signaling between them. How about the following 5. We can see the network at the level of domains/subdomains rather than individual routers (except in the special case that the domain contains one link). Domains are assumed to be administrative entities. So security requirements might apply differently for the signaling between them and within them. > In 5.7.8, confidentiality SHOULD be supported. The ability to listen > to signaling channels is a major guide to what data channels are > interesting. Is ok for me. The requirement changes then from OLD: 5.7.8 Confidentiality of signaling messages Based on the signaling information exchanged between nodes participating in the signaling protocol an adversary may learn both the identities and the content of the signaling messages. To prevent this from happening, confidentiality of the signaling message in a hop-by-hop manner MAY be provided. Note that the protection can be provided on a hop-by-hop basis for most message payloads since it is required that entities which actively participating in the signaling protocol must be able to read and eventually modify the content of the signaling messages. to NEW: 5.7.8 Confidentiality of signaling messages Based on the signaling information exchanged between nodes participating in the signaling protocol an adversary may learn both the identities and the content of the signaling messages. Since the ability to listen to signaling channels is a major guide to what data channels are interesting ones. To prevent this from happening, confidentiality of the signaling message in a hop-by-hop manner SHOULD be provided. Note that the protection can be provided on a hop-by-hop basis for most message payloads since it is required that entities which actively participating in the signaling protocol must be able to read and eventually modify the content of the signaling messages. Objections? Marcus > > > > > > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis
- [NSIS] More IESG Review of draft-ietf-nsis-req-08… Allison Mankin
- [NSIS] Re: More IESG Review of draft-ietf-nsis-re… Marcus Brunner