Paul Moore wrote:
On Wednesday 09 December 2009 02:31:16 pm Jarrett Lu wrote:
Paul Moore wrote:
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.
This sounds as too ambitious to me. Even if this can be done for all known
label formats in use today, how would we know it will map well for some new
labels in future?
We don't, well not unless your crystal ball works a lot better than mine :)
I'm concerned that if we devote too much effort into making the protocol
completely future-proof we will end up sacrificing capability with the
implementations we have today (or can envision).
Actually I was advocating the opposite of "devoting too much
future-proof effort". How about not going that route at all? The Label
Format Selector idea is quite extensible. For any new label in future,
you need to publish a Label Format Spec, get an INAN registry, add new
parsing capability in the system, and you are done. There is little to
change in the protocol itself.
Beyond the interoperability
concerns over multiple label formats, one of my main concerns is that a
protocol with multiple formats is almost surely going to be rejected/ignored
by the intermediate hop vendors as it is too difficult to put in an ASIC. One
of the lessons I learned during the CALIPSO review process was that one of the
reasons CIPSO failed was due to the different label formats, aka CIPSO "tag
types", which made it difficult for intermediate node vendors to parse and
apply security policy quickly.
I could be wrong here. I thought the opaque blob is passed as pay load
in IKE exchange, not as IP option in the header.
- Jarrett
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
