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. I'm pretty sure this has been tried in the past and has failed.
I also think its not very reasonable to have the DOI incorporate both
the format of the label and the policy authority/identifier.

Dave

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to