John Fischer wrote: > Mark, > > Was the last point that wasn't considered a TCA Advisory? > If so then it should go into section 6. Reading the opinion > it sure seems like that is where it ought to end up. I think I can recall who made that comment (or it's almost certainly in the record). I think the last line is clear that the author of the comment didn't feel it warranted official section 6 status. The text used was the exact text from the issue. If you feel like promoting it (as it were) as advice, I'll be happy to reword that last paragraph into a TCA.
> > Thanks, > > John > > Mark Martin wrote: >> 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 >> >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc at opensolaris.org
