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

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 10 Nov 2003 11:27:16 -0500

One comment which Barbara and I noticed in many of the 2401 issues is
the use of the terms "red-side", "black-side", "red-to-black", etc.

To date these terms have not been used in the IPsec RFC's and I-D's, and
I'd like to suggest that perhaps we should be careful not to introduce
them.  The reasons for this is two-fold.  First of all, it introduces
additional specialized lingo which may make the documents more difficult
to read.  Secondly, "red" and "black" primarily only makes sense in the
case of a security gateway, and do not necessarily make much sense in an
peer-to-peer configuration.  There is at least one example where the use
of "red" and "black" lingo has also been accompanied by diagrams that
only address the use of IPsec in tunnel mode and assume the VPN/Security
gateway model.

Comments?

						- Ted

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Nov 2003 14:08:43 -0600

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Theodore" == Theodore Ts'o <[email-masked]> writes:
    Theodore> careful not to introduce them.  The reasons for this is
    Theodore> two-fold.  First of all, it introduces additional specialized
    Theodore> lingo which may make the documents more difficult to read.
    Theodore> Secondly, "red" and "black" primarily only makes sense in the
    Theodore> case of a security gateway, and do not necessarily make much

  Agreed.

    Theodore> sense in an peer-to-peer configuration.  There is at least one
    Theodore> example where the use of "red" and "black" lingo has also been
    Theodore> accompanied by diagrams that only address the use of IPsec in
    Theodore> tunnel mode and assume the VPN/Security gateway model.

  Also, Red/Black terms are *exchanged* in some Canadian CSE documents.
  So, please just avoid the terms.

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Jonathan Stone <[email-masked]>
Date: Mon, 10 Nov 2003 12:25:54 -0800

[Keep "red"/"black" security-gateway terminology out of I-Ds and RFCs]

Yes, please!  I've been using IPsec-style technology in peer-to-peer
mode since before it was IPsec, and I've become very increasingly
concerned by the apparently-growing tendency to think of IPsec as if
the _only_ scope of IPsec is security gateways and VPNs.

I've been wondering how to word a similar request for some weeks.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Nov 2003 16:47:42 -0500

>I've been wondering how to word a similar request for some weeks.

Jonathan,

VPNs are not the genesis of the terminology. The terms arose in the 
DoD context 50 years ago, well before there was a notion of VPNs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Nov 2003 16:52:48 -0500

>only address the use of IPsec in tunnel mode and assume the VPN/Security

The terms are applicable in all 4 examples of IPsec implementations, 
and in transport and tunnel mode.  The terms are thoroughly relevant 
to peer-to-peer use of IPsec.

One might prefer better names, but not for most of the reasons you cite.

Steve

---

From: Jonathan Stone <[email-masked]>
Date: Mon, 10 Nov 2003 15:00:57 -0800

>DoD context 50 years ago, well before there was a notion of VPNs.

I'm well aware of that.  But it's a non-sequitur to my response to and
Ted's second point, which I can only assume you missed:

> [...] the use
> only address the use of IPsec in tunnel mode and assume the 
> VPN/Securitygateway model.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 10 Nov 2003 18:28:31 -0500

> > VPN/Securitygateway model.

At the WG session today, Steve Kent clarified that the "red interface"
on a host stack implementation could be a purely internal functional
interface rather than an IP Interface (virtual or physical).

That said, I still get confused more often than I'd like about red vs
black.  If the documents are to use the terms, we need a clear
definition, and a mnemonic phrase or such to avoid embarrassing sign
errors like the one Michael Richardson pointed out.

					- Bill

---

From: Jonathan Stone <[email-masked]>
Date: Mon, 10 Nov 2003 15:45:36 -0800

>interface rather than an IP Interface (virtual or physical).

Hm. I suppose one couuld invent terminology like that, but its a
pretty radical departure from the DoD terminology, since (outside the
VPN/securitygateway model), one can trivially produce graphs where
nodes cannot be consistently labelled either "red" or "black".

Even disregarding that, it's still a bit of a non-sequitur to the
point abouta

   "... only address the use of IPsec in tunnel mode and assume
        the VPN/securitygateway model".

which struck me as a legitimate concern, orthogonal to whatever
terminology one adopts for the VPN/security-gateway model.

(For what it's worth, I'd like to see of "red" and "black" or any
other similar terms prohibited, lest they seduce anyone into thinking
*solely* in terms of IPsec tunnel mode and VPNs/security-gateways).

---

From: Dan McDonald <[email-masked]>
Date: Mon, 10 Nov 2003 19:51:46 -0500

> *solely* in terms of IPsec tunnel mode and VPNs/security-gateways).

Alternatively, a decent up-front definition of "red" and "black" while
discouraging the VPN-only seduction would also be a fine idea.

	"IPsec:  Not just for VPNs any more"
		 - The header of the internal Solaris IPsec web page.

Dan

---

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 10 Nov 2003 22:38:24 -0500

In some private discussions this evening, it was noted that "red" and
"black" are used in two senses.  The first is pre- and post-
processing by the IPSEC stack, in the inbound and outbound paths.
(i.e., "red to black") In this case, being explicit about something
like "before ipsec processing" or "after ipsec processing", etc. would
probably be less confusing.

The second is "trusted" and "untrusted", or "internal" and "external"
when referring two networks or interfaces on a security gateway.
Granted that "trusted" is overloaded by other meanings that might
cause confusion, does "internal networks" and "external networks" work
better folks.  (All of this assuming that we have explicit definitions
before we use any of these terms.)

						- Ted

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 11 Nov 2003 11:02:57 -0500

> In this case, being explicit about something like "before ipsec
> processing" or "after ipsec processing", etc. would probably be less
> confusing.

But this needs to be clarified with a direction as well.

> before we use any of these terms.)

This has the same problem of implicitly excluding end-to-end ipsec, as
the "internal network" exists solely within the box.

					- Bill

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Nov 2003 11:34:30 -0500

IPsec provides a barrier through which traffic passes. There is an 
asymmetry to this barrier, which is reflected in the processing 
model. Outbound data, if not discarded or bypassed, is protected via 
the application of AH or ESP and the addition of the corresponding 
headers.  Inbound data, if not discarded or bypasses, is processed 
via the removal of AH or ESP headers, after processing. We need to 
refer to inbound and outbound directions in discussion processing, 
and these directions have to be expressed relative to the sides of 
the IPsec barrier. Interfaces for an IPsec implementation, including 
the internal interface that a native, IPsec host implementation 
presents to applications, must be characterized relative to the side 
of the barrier on which the exist.

We could use "protected" for "red" and "unprotected" for "black" if 
that makes it easier for folks to remember.

Steve

---

From: Paul Koning <[email-masked]>
Date: Tue, 11 Nov 2003 13:53:23 -0500

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> IPsec provides a barrier through which traffic passes. There
 Stephen> is an asymmetry to this barrier, which is reflected in the
 Stephen> processing model....

 Stephen> We could use "protected" for "red" and "unprotected" for
 Stephen> "black" if that makes it easier for folks to remember.

Yes, I would like that a lot.

For one not steeped in DoD jargon, "red" and "black" have no intuitive
meaning.  I usually get the two sides mixed up, because my mind
interprets "red" as "sensitive" so I think that the red side is the
unprotected side (where the classified stuff is exposed) rather than
the protected side.

It sounds like I'm not the only one who suffers from this.
"Protected" and "unprotected" have clear meanings and are a lot harder
to misinterpret.

     paul

---

From: David Waitzman <[email-masked]>
Date: Tue, 11 Nov 2003 14:28:17 -0500

> "Protected" and "unprotected" have clear meanings and are a lot harder

My input would be CT == Cipher Text for the side where the data is 
enciphered and PT == Plain Text where the data is plain.

Similar to Protected but more history behind it.

-david waitzman

---

From: Henry Spencer <[email-masked]>
Date: Tue, 11 Nov 2003 15:40:15 -0500 (EST)

On Tue, 11 Nov 2003, Stephen Kent wrote:
> ...We need to 
> the IPsec barrier...

Or "tame" and "wild".

"Red" and "black" are really poor choices, because they are not clearly,
unambiguously associated with the meanings we want to convey.  *Both* of
those colors have some negative associations -- in electric power wiring,
"black means death", the black wire is the "hot" wire -- so if we are
going to use colors at all, those are the wrong pair.  Black and white, or
red and green, would be better.  But even those suffer from ambiguity and
cultural bias.  It's better to use words that are close to what we *mean*
than to unnecessarily introduce a potentially-confusing metaphor. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: "Sean Kevin O'Keeffe" <[email-masked]>
Date: Tue, 11 Nov 2003 15:39:51 -0800

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

---

From: Greg Troxel <[email-masked]>
Date: 12 Nov 2003 08:25:55 -0500

My reaction on reading Steve's message was that protected/unprotected
was also confusing.  I read Steve's comment equating protected and red
as the network port which had some sort of physical
security/connection control, and thus was not using IPsec, and the
'unprotected' port as the one which traversed e.g. the public Internet
and thus on which data needed IPsec protection.  On reading Paul's
message, I'm sure they are confusing; I am pretty sure he interpreted
them differently from how Steve meant them.

That said, PT and CT are useful terms that are more descriptive.  But
the nesting terminology concern that Sean points out can not be
addressed fully with any choice of terminology; the fundamental
difficulty is that one system's CT data is another's PT data (e.g. two
hosts using transport mode across a VPN).

-- 
        Greg Troxel <[email-masked]>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Nov 2003 10:50:03 -0500

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

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Nov 2003 09:58:06 +0200

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:

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

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 25 Nov 2003 13:10:42 -0500

> suggestions, we will use those terms going forward.

Thanks, I think these would be a better set of terms going forward, in
particular with respect to issue #91.

						- Ted