[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