Hi, Bill: I understood the spec pretty well. I like that you have limited the scope to what you consider to be likely higher-use scenarios. I have a couple of questions:
In paragraph 4 of section 4, you use the phrase "indirect labeling". Is this the same as implicit labeling? If so, continue to use implicit. If not, maybe you could provide a glossary of terms. In paragraph 1 of 5.1, you refer to "plaintext' at the end of the paragraph. Is plaintext the text that is covered by the SADB_EXT_SENSITIVITY extension? If so, make the connection explicit. If not, maybe you could say where the plaintext is in the packet. Nits: is be > is which will be used by in.iked ... > . This option is used by in.iked .... mark its key management traffic exempt > to mark that its key management traffic is exempt ... that the would > that they would -- Sharon ---------------------------------------------------------------------- > Message: 1 > Date: Mon, 12 May 2008 13:52:15 -0400 > From: Dan McDonald <danmcd at sun.com> > Subject: Re: labeled ipsec phase 1 design review > To: security-discuss at opensolaris.org > Message-ID: <20080512175215.GH5982 at sun.com> > Content-Type: text/plain; charset=us-ascii > > 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 > > > ------------------------------ > > _______________________________________________ > security-discuss mailing list > security-discuss at opensolaris.org > > End of security-discuss Digest, Vol 33, Issue 7 > *********************************************** >
