On Tue, 2009-12-08 at 19:57 -0800, Casey Schaufler wrote: [snip] > > > > > The term "DOI" has been used in traditional MLS system for about two > > decades. In the MLS world, when systems use same DOI, it means they > > agree to the same label definition and MAC policy, and the systems are > > most likely under same administrative control (Note which policy is > > agreed upon is handled outside of a networking protocol). The label > > format is determined, i.e. it's CIPSO. > > Actually, the TSIG definition only requires that the two be able > to work out their differences. They are not required to speak the > same
I think that this is a reasonable statement. [snip] > > > > David Quigley and I had some offline conversation about this, as he > > has the same need for labeled NFSv4 work. The current thinking is to > > have a separate draft describing the need to set up an IANA registry > > and its content. Each entry consists at least the following fields: > > LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO, > > SELinux security contex strings, etc. > > SUB FIELD: Used to aid label handling, e.g. SELinux could use it for > > policy version numbers; CIPSO could use it for tag type; > > LABEL FORMAT: pointers to reference docs on how labels should be parsed. > > > > Both Labeled IPsec and labeled NFSv4 (and any future label protocol > > extensions) can refer to this document. > > Two systems, no matter how similar, will never be able to translate > formatted labels reliably. It only takes trivial changes to an SELinux > system for my_dog_has_no_nose_t to mean completely different things > on the two machines. > > I stick by my claim that the right and only rational scheme is for > each system to explicitly map the labels it understands from another > system to local values, and vis versa. Any label without a mapping > must be discarded unused. If you are brave and foolish you can say > that the mapping is unity. > I'm pretty sure this is what has been proposed from the beginning. I don't know where in our conversations at least that I've given you a different opinion. > > > >> > >>> Not that I expect a single DOI to use multiple label types, but at > >>> least one can then parse the label payload according to the stated > >>> type rather than having to find the right type for the given DOI. > >>> > >>> - Text on the encodings of specific label types' labels. > >>> > >>> Particularly I think you need to have normative references to the > >>> relevant RFCs and other work for the 'core' label types. > >>> > >>> > >> Yes, I agree, although I am unaware of any RFCs dealing with that yet. > >> > > > > There are more references for MLS labels (FIPS 188, CALIPSO draft, > > etc.) as they have a longer history. BTW, I don't think the label > > format specification has to be IETF RFCs. > > Yeah, that would be bad. I spoke with the people at IANA and I believe that we're going to go with a hybrid approach for the registry. It is going to be open standard meaning that the document that describes the format must be freely available and there will also be an expert review requirement. Dave _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
