On Mon, 2008-05-12 at 13:52 -0400, Dan McDonald wrote: > * NIT: "Solaris IKE daemon". Maybe that's just s/happy/glad/g, though.
fixed. > > > 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. the main constraint is that TX networking policy is tied to ip addresses. I'll reword this a little. > * 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. Done. > 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. Noted. Reasonable RFE for a followup but out of scope for phase 1. > * 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. Close. I'll clarify. > > > > Section 5.5.1 > > * Can I also instantiate "multi-label" or "single-label" as global, inherited > by rules that do not state anything? Yes. Clarified. > 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) I've added text to explain this.
