[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Meta-comment: use of "red" / "black" terminology...



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