On Fri, 2008-05-09 at 19:59 -0700, Glenn Faden wrote: > Sect 5.2 > > I can't parse the end of the last sentence > > protected by either AH or ESP integrity protection and perhaps ESP > integrity protection.
That should have been "perhaps ESP confidentiality protection". ESP can provide either or both of confidentiality and integrity. > Sect 5.3 > > The privilege you are are probably referring to net_mac_aware, is > currently used to allow clients to make requests to lower-level remote > unlabeled servers to support reading down. The primary use is for NFS > client side operations in labeled zones. The SO_MAC_BYPASS to mark > in.iked traffic exempt from labeling seems sufficiently different to > justify a new privilege. Ok. I'll do that, creating a NET_MAC_BYPASS privilege. > Am I correct in assuming the in.iked only runs in the global zone? Under TX, yes. With exclusive IP instances, you get one in.iked per exclusive IP zone but we don't yet allow TX to run with multiple IP instances. If we begin allowing multiple ip instances with TX we'll have to tackle this but by denying zones this NET_MAC_BYPASS privilege we can at least keep them out of trouble.. > Nit: > > 5.4.2 s/labe/label in last sentence. fixed. > 5.5.2 Wire encoding > > If case 2, wire-label none label, is there a limit on the number of > compartment bits? Currently the CIPSO limit is 240 bits, but you're not > using CIPSO in this case, so 256 bits should work, right? The label needs to pass through IKE's SIT_SECRECY extension (so it needs to fit in a UDP packet along with the rest of an ike phase 2 message) and through PF_KEY, but 256 bits of compartments wouldn't be a problem. Note that in the "wire label label" case, the inner label is not limited but the outer label is limited. If you need to go much bigger than this we should talk..
