On Wednesday 09 December 2009 02:06:04 pm David P. Quigley wrote: > On Wed, 2009-12-09 at 12:31 -0500, Paul Moore wrote: > > On Wednesday 09 December 2009 10:21:30 am David P. Quigley wrote: > > > 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. > > > > I agree with Casey and David. I think the only way we stand any chance > > of success is to develop a on-the-wire format that can be easily > > internalized by a variety of implementations. For example, I know CIPSO > > is far from the darling child of labeled networking, but due in large > > part to it's simple, MLS (level/compartment) format it is possible to > > interoperate between fairly different security models. I've personally > > used CIPSO to communicate between Trusted Solaris (that is traditional > > TSOL not FMAC) and SELinux as well as SELinux and Smack (interesting > > because Smack does not have inherent MLS specifics like TSOL and > > SELinux); I have not tried to interoperate between Smack and Trusted > > Solaris but I see no reason why it would fail. I will be the first to > > admit that these were simple test cases and there was definitely > > configuration on both required to reach this point, but it is possible. > > > > I hope to be able to do the same with CALIPSO when I finish the Linux > > implementation (only about 50% at present). > > > > It is partly because of this experience that I'm not entirely convinced a > > label format token is needed along with the DOI token and label blob. I > > currently believe that the best solution would be one that only specified > > the DOI and the label, in whatever representation seems "the best" given > > what we currently know. Specify in great detail what the on-the-wire > > format should look like and let the individual implementations worry > > about translating from their native format to the wire format. I suspect > > this will provide the highest level of interoperability and as a result, > > adoption. > > I don't think its realistic to develop a single on the wire format for > labels.
Well, I've seen it work so I know it is possible, I guess it all comes down to what we decide "realistic" really means. > I'm pretty sure this has been tried in the past and has failed. I've actually seen very little discussion about why single format labeling protocols have failed (or rather was it the systems that failed, causing the protocols to fail as a result) and unfortunately I wasn't involved in that space at the time so I have no personal history. I think a good first step to arriving at a new protocol is to understand what went wrong in the past and why it went wrong. It is important to note I'm talking about adoption, implementation and interoperability; I'm not talking about what went wrong between the IETF and TSIG (although based on what I've learned I suspect there is some overlap here). > I also think its not very reasonable to have the DOI incorporate both > the format of the label and the policy authority/identifier. I think this is secondary to the single vs multiple wire format question. If you only have a single wire format then a label format token is a bit silly, however, if you want to support multiple label formats then you might as well include some sort of format specifier. -- paul moore linux @ hp _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
