Subject: RE: [Ieprep] What next?, getting to the BCP deliverable.

From: Fred Baker <[email-masked]>
Date: Wed, 01 May 2002 10:27:54 -0700

At 09:19 AM 5/1/2002 -0400, Folts, Harold wrote:
>Its not appropriate to say US Government. The white paper was crafted with
>considerable industry interaction and input and I expect this to be done in
>partnership with industry.

Your draft says

     A US Government working group recently identified fourteen basic
     functional requirements for the future ETS. These requirements are
     listed in the table below and represent the objectives that need to be
     fulfilled for national security and emergency preparedness (NS/EP)
     in the ETS.

Specifically, some of the requirements (anonymity comes quickly to mind) 
have been explained to me as coming specifically from certain agencies in 
the US Government. If you'd like to reconsider some of that, I'm game, but 
at present the draft is very clearly a set of US Government requirements.

>1. A more streamlined authentication scheme than the "credit card" method
>used for GETS today. Also the authentication must be passed along the path
>in an Internet environment, where it does not in the PSTN.
>
>2. There is a need for specific security protection of ETS traffic. These
>include spoofing, impeding, and intrusion.

May I suggest that you then break what you are calling "Security" into 
several requirements, and entitle them something like:

"source (and destination?) authentication"

      ie, each participant needs to know whom he is talking to with a high 
level of
      confidence. We don't want "send in the national guard" to go to your 
favorite
      skinhead group...

"source (and destination?) authorization to use the service"

      ie, a given service class needs to be used if and only if one of the 
parties
      to the conversation is authorized to use it. This, of course, depends on
      authentication, as already stated.

      The specifics of the "credit card" seem to me to be 
contract-specific. In my case,
      I have a program on my computer that generates a one-time password 
that I can use
      when dialing into Cisco. Several one-time-password-card products 
exist and could
      be used by other organizations that wanted that sort of service. I 
don't think the
      international standard wants to specify the use of a particular 
authentication
      mechanism or product, however; it wants to say that a contracted ETS 
wants to use
      an authentication mechanism that has the necessary characteristics to 
positively
      identify its user with high probability of correctness. It wants to 
leave the door
      open for retinal scans or whatever seems appropriate to the agency 
contracting the
      service.

"assurance of minimum QoS"

      ie, the traffic within the specified class needs a certain guarantee 
of service as
      specified in the ETS contract, regardless of other traffic. This will 
require some
      form of policing (some on the list don't like diffserv, I'll let them 
specify an
      alternative that meets your requirement during a ddos storm)

"assurance of end to end inviolability"

      ie, if there is an intrusion, it will not disrupt normal delivery of 
the real traffic.
      That very likely involves technology that provides a high probability 
of detecting
      and dealing with intrusion, but the specification should be that any 
such intrusion
      will be ineffective, not that it will not happen or that it will not 
remain undetected.

>The ETS must be provided using the shared public telecommunications 
>resources, not dedicated, isolated networks.

No problem; the way you get GETS on the telephone networks is by writing 
contracts with the telphone networks you want to use. Write the corollary 
contracts with the ISPs you want to use.

As I told you a couple of years ago, the IETF is not a one-stop-shopping 
place for contracts. We can specify what things a service provider should 
be prepared to negotiate with you so that you can point to a document and 
say "the US Government will pay you <mumble> for a service compliant with 
RFC <whatever>". At the end of the day, whether the ISP agrees to offer you 
the service,and how they implement it, will come out of the negotiation.

>I will have a revised requirements/objectives document ready for the May 
>20th meeting.

Thanks. This time I have allocated five hours; there should be no problem 
with you taking time to present it in detail.

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Alistair Munro" <[email-masked]>
Date: Thu, 2 May 2002 09:18:48 +0100

Hi Fred, Hal,

>      fulfilled for national security and emergency 

I'm trying to get a view from my APCO contacts in the UK on the
differences in requirements but I don't have much hope of being able to
be specific. Can we state a working assumption that these requirements
may be different in other countries, update the requirements and then
ask for comments from local agencies?

Regards,

Alistair
 
--
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.u4eagroup.com

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 02 May 2002 13:21:49 +0100

> ask for comments from local agencies?

my hope would be that the differences between other countries would be
quite small, and mostly a reflection of local laws and regulation that
amount to turn-on or turn off feature X.

if you're going down the avenue of APCO, you may want to take a look
at Project 25 (i believe they have high level comms Requirements), as 
well as the final report of the Public Safety Wireless Advisory Committee,
circa 1996.  (if you ask where to get them, i'm afraid i have to plead
ignorance -- perhaps a google search will help)

-ken

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 2 May 2002 08:48:42 -0400

> amount to turn-on or turn off feature X.

	I have specific reason to believe that European requirements vary
significantly from the US requirements.  And the Japanese presentations
at IETF have so far been fairly different from the DISA presentations.

	So I think it would be very unwise for an *international* activity
like IETF to get driven primarily by US requirements.  I second 
Alistair's
request to note the existence of national variation in requirements
and to put more efforts into getting inputs from other 
nations/areas/regions
than the US.

Ran
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 02 May 2002 08:54:25 -0700

At 08:48 AM 5/2/2002 -0400, RJ Atkinson wrote:
>like IETF to get driven primarily by US requirements.

I agree, and that is exactly why I have pointed out that these are USG 
requirements. Not that this makes them invalid, but it makes them one view 
of the elephant. We need to make sure that we solve the problem for the 
elephant, not the wise guy standing beside it.