Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt

Melinda Shore <mshore@cisco.com> Tue, 17 June 2003 00:58 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10946 for <nsis-archive@odin.ietf.org>; Mon, 16 Jun 2003 20:58:11 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H0vhQ20735 for nsis-archive@odin.ietf.org; Mon, 16 Jun 2003 20:57:43 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLX1a06324; Mon, 16 Jun 2003 17:33:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLW8m06298 for <nsis@optimus.ietf.org>; Mon, 16 Jun 2003 17:32:08 -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 RAA03607 for <nsis@ietf.org>; Mon, 16 Jun 2003 17:32:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S1Xy-000797-00 for nsis@ietf.org; Mon, 16 Jun 2003 17:29:50 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19S1Xy-00078z-00 for nsis@ietf.org; Mon, 16 Jun 2003 17:29:50 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5GLVVpa020024; Mon, 16 Jun 2003 14:31:32 -0700 (PDT)
Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIL17276; Mon, 16 Jun 2003 14:31:31 -0700 (PDT)
Message-Id: <200306162131.AIL17276@mira-sjc5-c.cisco.com>
To: "Attila Bader (ETH)" <Attila.Bader@eth.ericsson.se>
cc: nsis@ietf.org
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt
In-Reply-To: Message from Attila.Bader@eth.ericsson.se of "Mon, 16 Jun 2003 16:27:47 +0200." <F005CD411D18D3119C8F00508B0874800D3935D2@ehubunt100.eth.ericsson.se>
Date: Mon, 16 Jun 2003 17:31:30 -0400
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>

> I do not completely understand your argument for MUST
> implementation of hop-by-hop security. 'Must be
> implemented but not must use' means that there is the
> possibility to use hop-by-hop security in any NE but it
> has to be implemented even if it is never used. 'SHOULD be
> supported' means that it has to be implemented except in
> particular cases. I think it is strong enough.

"SHOULD be supported" does not mean what you say it means.

For practical purposes, if hop-by-hop security is a
must-implement, then failing to do so results in a
non-interoperable implementation.  If hop-by-hop security is
a should-implement, then failing to do so does not result in
a non-interoperable implementation.  Given the consequences
of a successful attack against this protocol, which could
range from dinking with QoS signaling (and all that implies)
to opening firewall pinholes to installing bogus address
maps in a NAT, it seems perfectly reasonable to have
mandatory-to-implement security mechanisms.

Melinda
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis