On Tue, 2007-09-18 at 13:56 -0700, Darren.Reed at sun.com wrote:
> Are there any relevant standards/RFCs that cover the two new
> on-the-wire formats?
As part of IKEv1, RFC2407 defines a way to carry sensitivity labels in
sections 4.2.2 (SIT_SECRECY) and 4.6.1, as part of the Security
Association payload.
IKEv2 does not contain an equivalent, but does have room for expansion
in the equivalent place. At an appropriate time we'll investigate
extending IKEv2 and publishing relevant internet drafts.
> Will this change to IPsec for [Open]Solaris make it easier
> or harder for future projects, such as IKEv2, compared
> with [Open]Solaris today?
Easier. In particular, we're likely to improve available documentation
for the interfaces used by key management daemons as a side effect of
this project.
> e.g. if IKEv2 were done today using racoon, I'd expect
> that it would continue to use the same configuration file
> as it does elsewhere today and there would be no changes
> required to racoon for how it fetches its configuration.
Porting racoon to solaris is not this project. I'd expect that a
hypothetical racoon port to solaris would retain its the ability to read
its current config file format but it seems like a poor idea to rule out
the possibility of enhancing/extending racoon.
> Is this project proposing to make the interfaces between
> IPsec and Trusted Networking public or will they remain
> [consolidation] private?
I'm not quite sure what you're asking about. It's likely that IPsec and
Trusted Networking kernel components (as parts of IP) will interact
using Consolidation Private interfaces. Its our intent to make
available Public (most likely Uncommitted) userspace APIs to manage the
policy stored in the kernel.
- Bill
