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

From: "Folts, Harold" <[email-masked]>
Date: Wed, 1 May 2002 09:19:32 -0400

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Friday, April 26, 2002 8:16 PM
> To: [email-masked]
> Subject: Re: [Ieprep] What next?, getting to the BCP deliverable.
> 
> 
> At 10:55 AM 4/11/2002 +0100, Alistair Munro wrote:
> >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
> 
> 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"),

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.

> 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.

I think there is more detail in the 11 "objectives/requirements" than first
appear. Some of these do not necessarily fall with in the IETF scope. I am
now preparing a revised version that I hope will zero in better without
suggesting solutions.

> 
> 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

The issues you list below are far beyond what is needed for ETS. We need to
keep it simple, yet effective. Two of the 11 address security - authorized
user authentication and specific security protection of ETS traffic. The
larger, global security issues with the Internet are being dealt with by
folks competent in that area. Where is what is looked for these two items:

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. These issues may be taken care of
by the overall security provisions existing or being developed. Then all we
need is to clearly describe how ETS traffic is protected. In addition, there
will be some specific traffic that contains sensitive/classified information
that will need to be encrypted or be non-traceable (if possible).

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

> 
>   - 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.

Again, I have not presented any solutions so that many alternatives and
approaches can be considered to find the best solution. Hopefully, many of
these can be accommodated with existing capabilities. Then we only need to
describe how they fulfill the requirement or objective. Some may prove to
not be solvable. The remainder would then need to be addressed through
additional provisions in existing specs or those under development. Ideally,
Separate dedicated standards would only be a last resort when there is
nothing that fulfills a requirement.

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

Hal

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

---

From: "Folts, Harold" <[email-masked]>
Date: Wed, 1 May 2002 13:57:10 -0400

> Sent: Wednesday, May 01, 2002 1:28 PM
> To: Folts, Harold
> Cc: [email-masked]'
> Subject: RE: [Ieprep] What next?, getting to the BCP deliverable.
> 
> 
> At 09:19 AM 5/1/2002 -0400, Folts, Harold wrote:
> 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.

That table was only intended to give a high-level introduction to the
remainder of the paper. The table actually was developed with industry
participation. It will be eliminated in the next draft because it really
does not serve any purpose but confusion.  The 11 requirements/objectives
are what the focus should be. Not all of them will be relevant to the IETF
so I will cull out the appropriate ones.

> 
> 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.

The users of the ETS will range from local emergency people at the disaster
scene all the way up the government ladder. At the local level there are the
fire, police, medical, utility, and construction activities are involved.
This is a mixture of government and private sector activities where the bulk
of traffic would originate. At the higher government level the requirement
for non-traceablity and encryption could come into play for particularly
sensitive traffic.

> >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"

Destination not required. Communications originated by an authorized user
can go to any destination.

> 
>       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.

Let's keep it simple. There is a specific mission for the ETS - provide
assured communications for emergency recovery activities to save lives and
restore community infrastructure.

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

We plan to apply SLAs to the provisioning of ETS. We are working with the
TMForum in the development of edition 2 of the industry SLA Handbook to
include provisions for the ETS.

> 
> 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.

All that we are looking for in the IETF are the technical provisions that
will facilitate establishment of preferential treatment of emergency
communications in the public telecommunications infrastructure to support
disaster recover operations. Preferential treatment only comes into play
when network resources are severely constrained and cannot handle the
critical emergency traffic. Otherwise ETS traffic would be treated the same
as all communications. 

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

Thanks Fred, I will be there.

Hal

---

From: "Folts, Harold" <[email-masked]>
Date: Mon, 6 May 2002 15:53:23 -0400

> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Monday, May 06, 2002 11:08 AM
> To: Folts, Harold
> Cc: ieprep
> On Monday, May 6, 2002, at 10:58 , Folts, Harold wrote:
> > Ran, let me provide you some very important background.
> >
> > Over the past 2.5 years, I have been very active in 
> collaboration with 
> > many
> > nations around the world. The requirements that I have been 
> addressing 
> > are
> > inclusive so that truly International solutions are established.
> 
> Harold,
> 
> 	It is important in an IETF context for the other 
> players you mention
> to actually show up and participate here.  No matter how well 
> intentioned
> any human might be, people make mistakes or forget things or overlook 
> things.
> The IETF needs to have visible public agreement from folks outside the
> US that the approach being taken within IETF is internationally 
> agreeable.
> 
> 
> 	No one person is *capable* of providing assurance of 
> that needed public
> agreement.  So trying to present yourself as the one person who has 
> everyone's
> requirements is well-intentioned, but not nearly sufficient.
> 
> 	If you are in contact with so many folks as you 
> outline, you should
> undertake active measures to get those other folks to show up at IETF
> and participate directly for themselves here.  That will 
> demonstrate the
> kind of broad multi-national support that is needed.  And nothing less
> will really be sufficient.

Ran, I am have given and will continue many briefings to interested groups
that include identification of all the many activities that are underway.
This includes the IETF work. I always encourage people to participate in
this work. However, the requirements people are not very interested in
getting into the nitty gritty of the IETF work.

I agree that one person cannot convey all the first hand requirements, but
on the other hand, I do provide status reports to most of these other
activities on the progress of work, including the IETF.

That's the best we can hope for at the moment.

Hal