Please find attached (and text inline) the draft opinion for 2008/252
Labeled IPsec phase 1. Commentary, concerns, criticisms, and
corrections wanted. Please.
_
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: James Carlson, Kais Belgaied (opinion written by Mark
Martin),
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.
3. Interfaces
This project will compatibly extend the PF_KEY interface as necessary to
manipulate new SA parameters, and will extend the IKE configuration
interfacefile format similarly
4. Opinion
4.1. The "wire-label" keyword
It seems to me that this controls 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. I think that'd make a
lot of
sense if there were only a handful of operationally meaningful combinations.
Thus, I was asking about those "meaningful combinations." I don't know which
ones off hand are the most meaningful. The omit/omit setting seems sort of
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.
My suggestion here (not quite rising to the level of a TCA) is 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.
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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: psarc_2008_252_draft_opinion.txt
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090617/46dca3d9/attachment.txt>
