That
means a Fed push down to the States with a reference
architecture. Work in
some
of the BAAs from HSARPA may instigate that.
Simpler is better. The USAF Cursor On Target approach is a good
one. When one
has to
pull together a system dynamically scaling out from the command to the
area
command, as each system comes on line and the locus of command shifts,
the
need for quick set ups dominates the need for
expressiveness.
The
NRP is a good read. They thought it through and have a solid plan. I
suspect
that
as in most disaster planning, simulations and exercises will be
done.
len
-----Original Message-----
From: Bob Wyman
[mailto:]
Sent: Thursday, January 27, 2005 2:59
PM
To: Bullard, Claude L (Len); 'Carl Reed OGC'; ; 'Kon
Wilms'; 'Art Botterell'
Cc:
Subject: RE: [emergency] CAP and
Signatures/Encryption
Len Bullard
wrote:
> Someone will have to
pare this down before it has to operate in real
time.
I whole heartedly agree! In general, for an effort such as this, options,
flexibility, and variety are *bad* things. We should be doing what we
can to define a strict protocol that provides very little opportunity for
misunderstanding and maximizes interoperability – even if the cost is a
potential loss of expressiveness. The more ways there are to do something, the
more ways there are to misunderstand. Misunderstandings could cost lives or
property.
The “normal” rules and customs which encourage flexibility in other
communications and applications protocols should not apply to this
effort.
bob wyman
From:
Bullard, Claude L (Len) [mailto:]
Sent: Tuesday, January 25, 2005 11:07
AM
To: 'Carl Reed OGC'; ''; 'Kon Wilms'; 'Art
Botterell'
Cc:
''
Subject: RE: [emergency] CAP and
Signatures/Encryption
I hope someone is
simulating this system. As I read through the byzantine
numbers of
organizations,
protocols, structures and policies that make up the NRP document, and
try to imagine
assembling a just in time interoperating network of networks for C2 given
an ongoing INS, it
makes the problems of 9/11 pale in
comparison.
It is one thing to be
transport-agnostic; it is quite another to have so many options at
so many layers that
the system simply cannot be operational quickly enough to meet
the
requirements.
Someone will have to
pare this down before it has to operate in real
time.
len
From: Carl
Reed OGC
[mailto:]
Interesting discussion. I would like to add that are
also a number of Internet standards (IETF) that deal with encryption and are
used for encrypting messages, such as e-mail. This includes the work of the
IETF S/MIME working group, specifically the S/MIME electronic mail security
protocol that is widely implemented in commercial mail agents. If you want
something a bit more low-level, I would also check out the work of the IPSEC
group, specifically RFC 3686 - Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload (ESP). This standard
incorporates the NIST standard that defines five modes of
operation for AES and other FIPS approved block ciphers
[MODES].
As Bob suggests, rather than the EM TC define a new
method of encryption, I would opt for a statement of best practices for
encrypting a CAP message using existing, well known industry
standards.
Regards
Carl
