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

No Subject



Of course, in the IPv4 world we will still continue to use (C)IPSO
since we have no choice. That wouldn't seem to be related to this
discussion (unless IPv4 tunnelled thru IPv6 comes into play, but
I don't think so.)

The only concern I have is how the notion of the implied labelling 
scales to networks with a large number of compartments where the 
number of *potential* labels increases exponentially. Your model
assumes a small number of classifications (which scales linearly)
and a small comparment set. 

The solution may be simply a matter of using a subset of the compartments
for network labelling or restricting the number of active security  
associations with different labels between any 2 end points. 
We will need to keep this in mind when we get around to discussions
of how the S/A's are managed.

   It would be significant risk reduction to
   authenticate such IPSO (or CIPSO, though that is neither standard nor
   widely interoperable [we run multi-vendor tests of this once in a
   while] or well documented) labels end-to-end using AH, hence my
   concern that IPSO be included in the AH computation (as the Proposed
   Standard RFCs already require).

If we assume that vendors will be able to use the implied S/A labelling,
then whether or not (C)IPSO labels are authenticated may be moot.
If a vendor chooses to stick with IPSO then not authenticating is
certainly no worse than IPv4 and would give an incentive to using the
S/A labelling. I don't think I have a strong opinion one or the other.

BTW: Most MLS vendors that I know about support CIPSO. Sun and Sequent
     are the only exceptions I know about and I think Sun is working on it.
     I can't speak to how well it is documented by individual vendors
     and how easily configurable it is for other vendors. From the Digital
     perspective it is easily configurable in all of our MLS+ 3.x releases.
     The CIPSO specifications are accessible in the TSIG archives. 
     (I do not want to get into a discussion of why it is not an RFC,
      since that predated my involvement and I would rather let it lie.)

	/andy