This ran for a week (or longer) over on opensolaris-arc. http://mail.opensolaris.org/pipermail/opensolaris-arc/2009-June/016505.html
I'm re-distilling on this alias to ensure proper aging and body. I'd appreciate feedback. I'll set the timer for next Wednesday, 2009-09-02. The text is available at: http://cr.opensolaris.org/~devnull/PSARC/2008/252/psarc_2008_252_draft_opinion.txt <http://cr.opensolaris.org/%7Edevnull/PSARC/2008/252/psarc_2008_252_draft_opinion.txt> It is also attached here (inline): Sun Microsystems Systems Architecture Committee _________________________________________________________________ Subject: Labeled IPsec phase 1 Submitted by: Bill Sommerfeld File: PSARC/2008/252/opinion.txt Date: June 17th, 2009. Committee: Kais Belgaied (opinion written by Mark Martin), James Carlson, Mark Carlson, Richard Matthews, Sebastien Roy, Gary Winiger Product Approval Committee: Solaris PAC solaris-pac-opinion at sun.com 1. Summary The current labeled networking technologies in Trusted Extensions assume that the underlying network will not misroute or manipulate packets in flight between parties. This project proposes to augment labeled networking to allow IPsec to be used instead of or in addition to the existing CIPSO security option, with the IPsec SADB augmented to associate sensitivity labels with each security association. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. 3. Interfaces Interfaces Exported Interface Classification Comments ike config file Committed /etc/inet/ike/config PF_KEY extensions Committed 4. Opinion 4.1. The "wire-label" keyword Members of the committe noted that the "wire-label" keyword has the potential for confusion. It can be used to control two different and possibly independent things: the choice of outer labels on IKE and AH/ESP traffic. Those labels can conceivably each be entirely missing, computed based on the label ranges of the peers (either max or min), hard-coded to some particular value, or driven by the label of the invoking zone. There are at least 25 distinct choices for the two policies combined, perhaps more if we get really creative. The single keyword approach means that you need to have subkeywords that somehow indicate how each of this traffic will be handled. That would make a lot of sense if there were only a handful of operationally meaningful combinations. Depending on the amount of "meaningful combinations", or the most meaningful of those combinations, the "omit/omit" setting may be obvious as a way to get out of the CIPSO mire, but it seems all of the others require detailed understanding of the policies that sites have and (likely) the limitations of the other vendor's equipment they're using. It is strongly suggested to control them separately, and introduce a single simplified control in the future if particular combinations turn out to be common enough to warrant it. This last point was not felt strongly enough to be listed as a TCA 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2008/097. 1 Onepager File: 20080409_bill.sommerfeld 2 Inception minutes File: inception.materials/20080806.2008.252.inception 3 Commmitment minutes File: commitment.materials/20090128.2008.252.commitment 4 Issues File: issues 5 PSARC 20 Questions. File: commitment.materials/txipsec-phase1-20q.txt 6 Security File: inception.materials/txipsec-phase1-security.txt PSARC/2008/252 Copyright 2008 Sun Microsystems
