[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