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

From: Alistair Munro <[email-masked]>
Date: Thu, 11 Apr 2002 07:55:02 +0100

Hi Hal,

Finding myself becalmed in an airport again, I have been through the 
drafts from Fred, yourself and Ken C. a few more times. I was wondering 
how to move forward. From my point of view, there are two things I need: 
functional/service requirements from the ETS side (your draft), and 
solutions from the IP side (Fred's draft). I like very much your A. - K 
paragraphs in section 4 as a list of requirements for the ETS - this is 
my interpretation at least, I don't know if others see it that way. 
Would it be a good idea to add a list of solutions to each, based 
roughly on Fred's draft plus some the results of current discussions, 
plus additions where topics aren't covered (Ken's document contains some 
useful stuff), aiming for the BCP deliverable?

If this is blindingly obvious, please excuse me. However, I would like 
to start making some real contributions, and I also need to plan for 
getting solutions out of other WGs where they are (apparently) missing.

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.degree2.com, http://www.u4eagroup.com

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

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 Apr 2002 20:15:49 -0400

At 10:55 AM 4/11/2002 +0100, Alistair Munro wrote:
>paragraphs in section 4 as a list of requirements for the ETS

I agree that functional requirements are needed. If I can say this without 
appearing to slam Hal's draft (which I consider a very reasonable start on 
something which might be entitled "US Government requirements of an ETS"), 
I personally find it to be a list of glittering generalities, some of which 
are mutually contradictory. I'm not at all sure how to design a service 
that meets those requirements.

Let's take "the network must be secure" as an example (and of course 
ignoring Ian's recent comments on the list). It is not clear to me whether 
the draft requires

  - Physical isolation of the network from the Internet backbone (which
    is seen as insecure), or
  - Use of Code Division Multiple Access signaling to reduce the
    probability of jamming interference with a radio signal, or
  - Use of Ultra-Wideband signaling to provide limited probability of
    detection of a radio signal, or
  - Use of technologies to prevent and detect interference or
    interdiction of a signal (such as placing fiber in a pressurized ABS
    pipe to detect attempts to bend the fiber to capture leaking
    lambdas), or
  - Use of type 1 encryption on all communications links, or
    fragentation and reordering of traffic in a transaction with fill
    traffic taking up any excess bandwidth on the line to prevent
    or limit traffic analysis
  - Strong authentication and perhaps encryption of every transaction
    (email, web, file transfer, database access, whatever) end to end
    using a mechanism such as IPSEC (is the blackberry to blackberry or
    IMM server to IMM server, or both?), or
  - Continuity and privacy of communication needs to be provided at the
    transport layer in a manner which traverses firewalls and NATs, such
    as TLS, or
  - Communication is required to be proof positive against denial of
    service attacks, viruses, or worms, or
  - Fast detection and operator interdiction of network overloads
    resulting from such attacks, or
  - Intrusion Detection Services (such as provided by a variety of
    products including my company's Net Ranger product) need to be
    deployed to automatically detect and interdict attacks,
  - Firewalls (such as CheckPoint or PIX) need to be deployed for
    perimeter protection, or
  - Tracing of hackers and ddos attacks to their sources, whether zombie
    system or the actual script kiddie, or
  - requiring ISPs to have their users "log in" in some manner (which
    seems to me superfluous; they have their own requirements in this
    area, dictated by their business), or
  - Routing needs to neighbor authentication to reduce risk of
    misrouting on incorrect data, or
  - Each route needs to be digitally signed to preclude transitive
    routing faults that neighbor authentication would not prevent, or
  - Digital signatures on XML records to ensure their authenticity
    in the database they were read from (eg, demonstrate to me that
    the record presented to me as a library of congress record is in
    fact from that place and is in fact exactly the authoritative
    record that someone wrote there 32 years ago)
  - Digital signatures on DNS records to ensure authenticated name-to-
    address translation (DNSSEC), or
  - Logging of all transactions (does that apply to DNS lookups?
    Transmission of log records?), or

  - Reasonable and customary protections (including any or all of the
    above as appropriate in the environment du jour) need to be provided
    against malicious or misconfigured behavior.

I can think of communication environments where each of those bullets is a 
reasonable interpretation, and where it is in fact the operative 
interpretation or part of it. My last bullet is (I hope Hal doesn't mind me 
trying to put words into his mouth) probably what is actually intended. 
Without explanation of the requirement, I can't tell whether we have 
succeeded in meeting it, and I'm pretty certain we won't meet every 
possible variation on it (exactly how do you ensure that nobody can attack 
you, ever?). Any of those interpretations of "secure" can be inconsistent 
with the service being anonymous, which is also one of the bulleted 
requirements. Once I put an encrypting key or authenticating hash on 
something, I at minimum know that the composer or sender of a message is 
one of the persons or devices that knows the key or hash to use. I often 
know that only one person should know that key or hash, whether his or her 
name is included or not.

So I think what needs to happen to that draft, if we are to make it a 
working group output, is that it must either be generalized beyond US 
Government requirements or it must be re-entitled "US Government 
Requirements..." It also must be extended to the next level of detail on 
each of the points, giving an analysis of what is being requested in each 
bullet, why, and in what environments that consideration is applicable.

As I understand the charter, the requirements document is not to be a BCP, 
and there is no need for there to be one requirements document. 
Requirements documents are generally informational. In fact, I think it 
might be simplest for us to present a number of requirements documents that 
describe US Government requirements, requirements for the SIP service, 
requirements for data services, and so on. The BCP or BCPs would be the 
recommended procedures that respond to the drafts. If the requirement, for 
example, is that a network be secure in some sense, a BCP for network 
security might address the types of authentication that are recommended for 
use in this type of service, when encryption is necessary and what types 
are appropriate or inappropriate, and so on.