[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Meta-comment: use of "red" / "black" terminology...
I think terms such as "protected", "sensitive", and "plaintext" are
problematic because they are loaded with other meaning. Perhaps we
should choose terms which are currently neutral, and colors are a good
selection.
Some people have said that "red" and "black" are overused. I don't
agree with that, but it should be a simple matter to choose other
colors without all the baggage. Or we could choose some other pair of
meaningless terms like "north" and "south" or "wet" and "dry". So,
are we going to mandate wet-side defragmentation?
Seriously, though, I don't see a problem with "red" and "black" so long
as we don't treat these terms as generic, and explain them in every
doc.
On Nov 12, 2003, at 5:50 PM, Stephen Kent wrote:
At 15:39 -0800 11/11/03, Sean Kevin O'Keeffe wrote:
I prefer the PT/CT terminology and I believe there are ambiguity
issues with using either 'Red'/'Black' or 'unprotected'/'protected.'
Even within the DoD community, I find the use of terms 'Red' and
'Black' confusing, or even inaccurate, for many network
configurations. For example, if a user wishes to use a gateway to
tunnel 'unsenstive' information through a 'sensitive' network, the
encapsulated ciphertext appears at the 'Red' interface of the
gateway, not the 'Black' interface. Another example where these
terms are confusing is when a user nests multiple gateways. This
leads to situations where the 'Red' interface of a gateway may
exchange packets with the 'Black' interface of a gateway in an
interior layer. (I believe the terms 'protected' and 'unprotected'
suffer from the same ambiguity.)
This second example raises another interesting notation issue. If
there is only a single PT/CT boundary in a system then it makes sense
to refer to the 'PT network' and the 'CT network.' However, with
gateway nesting, we may have multiple PT/CT boundaries in a system.
What naming system should we use to describe the various networks in
such a configuration?
-Sean O'Keeffe
Sean,
Since we have the option for already encrypted packets to enter the
"plaintext" side of an IPsec device, and because IPsec will often
allow traffic to pass through the barrier without encryption and
emerge on the "ciphertext" side, that I think these terms are not very
helpful.
I think we have to pick a pair of terms and realize that they will not
always be perfectly descriptive in all contexts.
Rich Graveman, in a message to me yesterday, noted that the ATM forum
folks use "protected" and "unprotected" to describe the sides of the
ATM crypto boundary in their documents. So, barring any better
suggestions, we will use those terms going forward.
Steve