As indicated by the brevity of other e-mails, there's not a lot here to pick
apart. I'll do my best, though. :)
First off --> Glenn Faden: There's one IKE per IP Instance. This means
the IKE in the global zone is working on behalf
of all shared-stack zones, including TX labelled
ones.
Now, on to the review itself.
Section 1
* NIT: "Solaris IKE daemon". Maybe that's just s/happy/glad/g, though.
Section 2
* "statically addressed" implies (at least to me) that every node has a
static address. Perhaps "statically allocated" would be more correct, as
you could have rules with a.b.c.d/N where N < 32 that could work with many
deployments.
* A source has informed me about one big known style of deployment today.
Often legacy boxes reside on an edge network. Such edge network routers
often scribble labels into the transiting outbound packets and remove
labels from the transiting inbound packets. I suspect a properly
configured deployment of your project will work nicely even communicating
with IPsec to these legacy edge boxes. If you could mention this
possibility, it would make some people happy.
(NOTE: I'm Bcc:ing my source on this, in the hopes that he crawls out
of his hiding place to review this himself.)
Section 5.1
* Another concern from my aforementioned source is that in non-encrypted
IPsec (AH or Auth-only ESP) that the inner label "shines through"
regardless, and that if there is an outer label that it must match or
dominate the inner label. Perhaps this belongs in Use Cases, or perhaps
it's worth of a SECURITY CONSIDERATIONS section of a manpage.
* It's not 100% clear when the SADB_X_SENS_IMPLICIT flag applies. From my
readings, I get the idea that:
* All label-aware SAs have both SADB_EXT_SENS... and
SADB_X_EXT_OUTER... in their messages.
* The ...X_EXT_OUTER... has either a label OR this IMPLICIT flag.
* The SADB_EXT_SENS... never has this flag set.
I'd like to see clearer text for how this flag gets used.
Section 5.5.1
* Can I also instantiate "multi-label" or "single-label" as global, inherited
by rules that do not state anything?
Section 5.7
* Historical note: IKE was originally kept in with the kernel IPsec bits
because if we modified PF_KEY, we wanted any
corresponding IKE modifications to come along for the
ride.
To be fair - and to the best of my knowledge - we've
never backwards-broken PF_KEY. OTOH we have rewhacked
how NAT-Traversal is implemented. I'm not sure how that
affects the possibility of splitting out in.iked &
closed-source friends into a separate package (whether
old-school SysV or new-school IPS).
Dan
