[Ieprep] Folts' stated requirements: security

Fred Baker <fred@cisco.com> Tue, 02 April 2002 20:12 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 PAA00961 for <ieprep-archive@odin.ietf.org>; Tue, 2 Apr 2002 15:12:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10238; Tue, 2 Apr 2002 15:08:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10204 for <ieprep@ns.ietf.org>; Tue, 2 Apr 2002 15:08:22 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00733 for <ieprep@ietf.org>; Tue, 2 Apr 2002 15:08:20 -0500 (EST)
Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g32K7nb20273; Tue, 2 Apr 2002 12:07:50 -0800 (PST)
Message-Id: <5.1.0.14.2.20020401085848.01d76788@mira-sjcm-4.cisco.com>
X-Sender: fred@mira-sjcm-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 02 Apr 2002 12:07:44 -0800
To: "Folts, Harold" <foltsh@ncs.gov>
From: Fred Baker <fred@cisco.com>
Cc: ieprep@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [Ieprep] Folts' stated requirements: security
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
X-BeenThere: ieprep@ietf.org

In 
http://www.ietf.org/internet-drafts/draft-folts-ieprep-white-paper-00.txt, 
you state that "A US Government working group recently identified fourteen 
basic functional requirements for the future ETS."

In section 2, you bring up the issue of security:
   +----------------------------------------------------------------
   |b. Secure Networks     Networks must have protection against
   |                       corruption of, or unauthorized access to,
   |                       traffic and control, including expanded
   |                       encryption techniques and user
   |                       authentication, as appropriate.
   +----------------------------------------------------------------

I'm not just certain what direction you want to take this. It is 
understandable in the sense of motherhood and apple pie: "people shouldn't 
be able to disrupt my communications, especially when I am calling for a 
fire truck, and people shouldn't be able to simulate calls for fire trucks 
when there is no need for one."

The question we need to ask is "so who needs to implement what, and what 
problem that we have are you addressing when you prescribe that?"

Your generic IP Service Provider, one readily argues, needs to be in 
control of his routers and switches. To accomplish this, we need good 
neighbor authentication between routers, and perhaps we need digital 
signatures on routes in some sense. In context, there has been quite a bit 
of work; OSPF, IS-IS, and RIPv2 each have built-in neighbor authentication 
using MD5 hashes. BGP uses RFC 2385 MD5 hashing for the same purpose. OSPF 
V3 uses IPSEC neighbor authentication, and the same has recently been 
proposed for BGP as well. On the digital signature side, Sandy Murphy 
designed RFC 2154, which has not been widely deployed for lack of interest 
from service providers, and Steve Kent et al have pushed the model in BGP 
(for example, http://www.net-tech.bbn.com/sbgp/sbgp-index.html).

In short, I hear you arguing that people should not be able to compromise 
routing. Are you stating that there is a problem here which needs to be 
addressed, or simply observing that security would be a nice attribute to have?

When it comes to user services such as AOL and various instant messaging 
platforms, there is also a requirement for user authentication and 
authorization to use services. There are also business requirements for 
same; one doesn't want people to use one's service if they are not going to 
pay for it. Are you stating that the type of authentication used for 
business purposes is inadequate for emergency use? Are you stating that you 
would like to be able to use https or some other "Secure" access technique 
to get to your IM provider? Are you saying that you want the provider to 
encrypt IM traffic internally? What problem are you addressing, and what 
are the details of the requirements relating to the problem?

Much email and other access is directly from the user's desktop or laptop 
computer. Are you asking for security for the end computer? Do you mean 
that in the sense of the network preventing DOS attacks in some way? Are 
you asking for encryption and authentication services to be implemented on 
the laptop? Specifically what problem are you addressing and what types of 
solutions would meet the requirement?


_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep