Subject: Re: [Ieprep] Revised Rqmts ID

From: Fred Baker <[email-masked]>
Date: Wed, 24 Jul 2002 12:44:51 -0700

At 09:46 AM 7/16/2002 -0400, Folts, Harold wrote:
>I have just uploaded a proposed revision to the revised requirements ID as a
>result of discussions on the side with several people this week for
>discussion during the ieprep meeting this afternoon. It is available at:
>
>ftp://iepscheme.net/pub/ieps/docs/draft-ietf-ieprep-requirements-hfedits.pdf

Let's have a fairly focused discussion on this document.

The question before the house is: having read it,

         - does it give us enough of an overview, in the user requirements 
section,
           so that we can intuitively understand the issues?
         - does it tell us what technical problem needs to be solved in 
clear enough
           language that we can propose mechanisms to solve it?
         - does it give us enough information to help us decide which among 
multiple
           possible solutions is appropriate?
         - what detail is present that isn't related to requirements?

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

---

From: "Alistair Munro" <[email-masked]>
Date: Wed, 24 Jul 2002 21:44:51 +0100

Hi All,

I have spotted a number of minor editorials in Hal's revised draft that
I could fix more easily if I had the txt version. Can Hal supply this?

Back on topic, some initial suggestions:

> 
>         - does it give us enough of an overview, in the user 
>           requirements section, so that we can intuitively 
>           understand the issues?

I would prefer to see the security issues extracted as a separate item
in the list. Currently they seem to be split between (8) and (10), plus
any additional text appropriate from Ian's draft (as was suggested at
the meeting). Remove section 8.

Item 4: is a bit discursive. Suggest: "Emergency communications sessions
to receive preferential treatment to improve probability of connection
completion and normal termination over normal sessions under conditions
of congestion or saturation". In relation to this, keep 5.4 where it is.

Item 6: reword - there is no user requirement to transit multiple
providers, but we expect it to happen. Suggest: "Transparent national
and international access to emergency services implying cooperation
between service providers under some circumstances".

"

>           clear enough language that we can propose mechanisms to
solve it?

I find the list clear enough and complete at a top level. I think the
drafts from Ken and Ian provide a good basis for tutorial material on
the solution space to meet these requirements without imposing
constraints while highlighting issues - I promised Ken some input on
this. Is it considered the right way to go?

>         - does it give us enough information to help us decide which 
>           among multiple possible solutions is appropriate?

I would prefer not to have this sort of material in the requirements.
Having spent the effort to get solutions out of this draft, maybe there
is now too little information but IMO it's better that way.

>         - what detail is present that isn't related to requirements?

I am happy with the non-requirements text. Mostly it is useful
background and motivation. I still think section 1.1 should be retitled
"GETS - a motivating example" but I'm happy to keep it in section 1.

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: Fred Baker <[email-masked]>
Date: Wed, 24 Jul 2002 14:23:50 -0700

>is now too little information but IMO it's better that way.

There is a bit of a balance that has to be struck there, I agree, but in my 
opinion it is possible to place requirements that help us sort out 
solutions without specifying the solutions to be sorted out.

Take one example, one I mentioned in a too-hasty note a couple of weeks 
ago. As a user requirement, Hal says

         (2)Capability to rapidly authenticate users who are authorized to 
have access to
           emergency telecommunication services and to ensure maintenance 
of the user
           authentication in processing emergency communication through the 
network
           infrastructure.

And as technical requirements Hal has three numbered but empty sections 
that say
         3.2.3 Authentication of user/application
         3.2.6 Preserving authentication during transit
         3.2.7 Authorization of users for specific services/privileges

I find myself itching for some definitions. How "rapidly" must users be 
authenticated? Is this a matter of a couple of folks coming an hour apart 
to get a cookie that will serve them all day, or 10,000 folks, each coming 
for a separate cookie for each transaction, and by the way each producing 
transactions as quickly as they can wave a stylus on their PDAs?

How strong of authentication is required? In the PSTN, for GETS, we use a 
proof-by-assertion mechanism in calling the 710 area code, and then punch 
in a 32 digit number read off the back of a credit card. This is presumably 
sufficient in the PSTN, but I have to say I think it might be mostly 
because of the extreme limitations on the things that can present calls in 
the PSTN. As noted during the meeting, there are issues with that approach 
in the IP Network - you'd be amazed how many apparent calls to the 710 area 
code a script kiddie can generate if one were to put his or her mind to it. 
So what I get out of the draft is that, since nothing else is said, GETS 
uses a credit card with a PIN code on it, and that is probably fine for the 
IP Internet. But sez me who knows that script kiddies perpetrate thousands 
to tens of thousands of denial of service attacks in the Internet every 
week, and are deliberately destructive, I don't think that's adequate 
(humorous aside at http://ars.userfriendly.org/cartoons/?id=20010523). So I 
find myself wondering whether 
http://www.ietf.org/internet-drafts/draft-peterson-sip-identity-01.txt 
presents a useful direction - I know Rohan Mahy thinks it does. The issues 
I'm bringing out here, I suspect, are in fact *requirements* that the 
system must respond to. Not to say "thou shalt do Peterson's thing", but 
"it's fairly important that a script kiddie not be able to take out the ETS 
infrastructure".

"Authorization of users..." by whom? Is there more than one server (say, 
one for US NCS, another for UK's counterpart, and others for other such 
entities), or is there one server for the whole world? What is a user? Is 
it a person, or are anonymous persons or groups of persons reasonable to 
discuss?

"Preserving authentication during transit" - transit between what and what? 
Between IP networks? Between from the Internet to the PSTN? From the PSTN 
to the Internet? From PSTN to PSTN though the Internet? At what point is 
re-authentication acceptable? For example, if I have strong authentication 
like Peterson in the Internet and I hand the call off to the PSTN, it's 
likely to have a 710 area code in it...

It seems that we can place requirements here that help us sort out the 
applicability of separate solutions without going into the solutions 
themselves. In the above discussion I have mentioned two solutions - one to 
say that it appears to be accepted but I have a problem with it as a 
solution, and one to say that it is a potential solution on the table 
without saying anything about it. I suspect that I could have had the 
discussion without mentioning the latter at all, if I was sure that 
everyone knew about the existence of such potential solutions. My point is 
to get the requirements detailed enough that we can actually analyze the 
applicability of solutions, without having the requirements say "implement 
my solution".

---

From: "Alistair Munro" <[email-masked]>
Date: Wed, 24 Jul 2002 22:52:35 +0100

Hi Fred,

> solutions without specifying the solutions to be sorted out.

Yes, there is an issue of balance and I'm struggling a bit with it right
now. I think the 3.2.n subsections are the right place to restore it and
I'll put some suggestions together. I think we could focus on parameters
appropriate to the sub-sections, possible performance bounds and risks,
i.e. what the solution should do and should not do - requirements that
sort sheep solutions from goats (as you suggest).

Your example gives me some ideas for these bits and some material that
could also complement Ian's security draft. Let me chew over it a while
until tomorrow.

Regards,

Alistair