CURRENT_MEETING_REPORT_ Reported by Ron Sharp/AT&T CIPSO Minutes Here are the Minutes for the Commercial Internet Protocol Security Option Working Group meeting held in Atlanta, Georgia. Most of these Minutes were provided by Noel Nazario who recorded them and sent me an electronic version. Thanks again Noel. The Working Group met for 1.5 days with the first half day being spent on new issues described below. The second day we addressed and closed nearly all of the old issues. Quick CIPSO Summary Option type 134. One option per packet. Only sensitivity tags are currently defined in the document. The document provides a common format and minimum configuration parameters required for interoperability. Interpretation of values within the option are DOI-dependent (Domain of Interpretation). Description of Open Issues 1. Clarifications to the Spec 2. Multiple DOI's 3. Sort Categories 4. Policy on unrecognized tags 5. Exclusionary tag types 6. Multiple sensitivity tags 7. Minimum RFC Compliance 8. Tag alignment 9. Change exclusionary tag type number 10. Error condition definition 11. Configuration parameters 12. New tag types 13. Tags 128-255, Vendor/DOI defined 14. Move security level out of tags 15. Vendor tag types - router problem 16. 8-bit security level and 2-bit errors 17. Header space 18. Should DOI #3 be included in spec for testing 19. Canonicalization of encodings 20. Whether to allow category 0 21. Routing based on nationality caveats New issues Mike St. Johns proposed the following change to the CIPSO format: 1 8 8 16 bit |--------------------------------------------| | Type | Length | Level | |--------------------------------------------| | DOI | |--------------------------------------------| | Cat ID | Categories | |--------------------------------------------| | (8 bits) | (24 bits) | |--------------------------------------------| | 255 | | <-- Sys Hi |--------------------------------------------| This format will effectively eliminate all tags. Its basic merit is that it is simpler for routers to handle. The 16-bit security level is to be encoded for certain Hamming distance and not open to definition of 2 to the 16th levels. It would be easy for a router to implement. No flexibility in specifying different security policies. It was voted 9:4 to continue the discussion of the other issues and table this proposal and discuss it more electronically before the next meeting. Discuss and Close Issues o Issue 1: Spec Clarifications Section 4, eliminate the non-security IP options from the document. This section will be replaced with a reference to the Internet Assigned Numbers Administration (IANA). Note that the length fields and tag numbers in the document should be reviewed and corrected. The requirement to transmit between DOI should be done by IP gateways and not by routers. Pro: 11, Con:0 Clarify the concept of classes of tags (i.e., sensitivity tags). Pro: 12, Con: 0. o Issue 3: Sort Categories Categories enumerated in type-2 tags should appear in ascending order. Pro: 12, Con: 0 o Issue 5: Exclusionary tag type change Eliminate the exclusionary flag from the enumerated tag in favor of 2 adding a new range tag type with lower and upper bounds. Pro: 14, Con: 0 Redesigning Tag Type 2 8 8 8 |----------------------------------------------------------| | Type | Length | Level | Enumerated Categories | |----------------------------------------------------------| It was voted to eliminate the flags field from the Tag Type 2 format. Pro: 13, Con: 1 Design Tag Type 5 (Range type) 8 8 8 16 16 |------------------------------------------------------| | Type= 5 | Len | Level | 1h | 1l | |...| | nh | nl | |------------------------------------------------------| ^ Optional, 0 assumed if missing nh is the range high value and nl is the range low value. ranges are sorted high to low non-overlapping. The use of this format for the new Tag Type 5 was voted Pro:11, Con: 2. o Issue 8: Tag alignment Compliant implementations will support unaligned tags. Pro: 12, Con: 0 o Issue 13: Tag types 128-255: Vendor/DOI assigned It was agreed that these tag types would be defined by the DOI and not the vendor. For example, a vendor should not implement a new tag format with a hard coded type number >127 unless the implementation is solely for a particular DOI. The need of these tag types was questioned during the meeting. There was concern that allowing users to define their own label formats could lead to non-interoperability issues later. It was decided to table the discussion until we had more time to look at the problem. o Issue 2: Multiple DOI's 2a. Implementations must support one DOI and may/should support 3 more than one. Pro: 13, Con: 0 2b. Recommend to administrators that a common DOI should be understood by all hosts on a subnetwork. Pro: 12, Con 0 2c. For outgoing communications the DOI is selected based on either the network interface that will be used or by the address of the destination. This insures that the DOI selected on outgoing packets is not just a host level default but can be configured based on either the network interface (i.e., network default DOI) or by the destination host address. If it is on the destination host address then a DOI could be configured for the destination IP subnetwork or the host itself. Pro: 8, Con: 0 o Issue 18: Reserve DOI number 3 for use in testing Not necessary to include in the RFC. DOI's are configurable. Pro: 12, Con:0 o Issue 6: Multiple sensitivity tags Only one sensitivity tag included in a CIPSO option. Pro: 8, Con: 2. o Issue 19: Canonicalization Require a common deterministic algorithm in CIPSO implementations where each label can be represented by only 1 sensitivity tag type. - Increases speed of equality check - Possible algorithms * Ascending order of tag numbers (1 first then 2 . . .) * Minimize space (use tag that requires least bytes) - Possible loss in speed due to time required for new algorithm - Goes against concept of maximize what you will accept Tabled o Issue 4: What to do on unrecognized tag types The behavior on unrecognized tag types should be configurable with the default being not to accept the packet. Pro: 8, Con: 4. Make configuration optional, the default being to generate an error on unrecognized tags. Pro: 10, Con: 1 Issues not discussed due to time constraints 4 1. Minimum RFC compliance 2. Error conditions and responses. Brian Yasaki and Debbie Futcher wrote up a section for error conditions. A new copy will be sent out the mailing list and comments should be placed back on the mailing list. 3. Configuration parameters. Minimal configuration parameters required for each CIPSO host. Some of these changed with the issues discussed and a new version will be put on the mailing list before the next meeting. Conclusion As you can see we made it through a lot of issues and closed most of them. This is great. Part of the reason many were closed so quickly is that we discussed them at the previous CIPSO IETF meeting but we agreed to hold them open until this meeting. A request was made for a new CIPSO IETF editor. Mark Powers has been doing a great job but due to job requirements he has not been able to make many of the meetings. Mark Christenson from Cray volunteered to do the work. I will make the appropriate changes to the document and submit it to Internet-Drafts and then give the document to Mark. Thanks Mark. The next meeting of the CIPSO IETF will be at the HP complex in Cupertino, CA September 24th - 26th of this year. It will be held in conjunction with the TSIG meeting. It will start around 9am on the 24th and will have a morning wrap-up on the 26th ending around noon. I will send out more details as I get them. If you have comments on any of the issues discussed please put these comments out on this mailing list now. Do not wait until the next meeting. If you have any new issues then again please bring them out now. New issues brought up at the next meeting will take a lower priority to existing issues that have had a chance to be digested and discussed on the mailing list. Attendees Richard Balcon rbalcon@oracle.com Tom Benkart teb@saturn.acc.com Nelson Bolyard nelson@sqi.com Doug Brown cdbrown@sandia.gov Mark Christenson mgc@cray.com Daylan Darby daylan@ssc_bee.boeing.com Deborah Futcher dfutche@eco.twg.com Amir Hudda amir@sware.com Barry Miracle miracle@sctc.com Noel Nazario nazario@csdserv.ncsl.nist.gov 5 Oscar Newkerk newkerk@decwet.enet.dec.com Jackie Proveaux jackie@csd.harris.com John Seligson johns@ultra.com Ron Sharp rls@neptune.att.com Rick Slade ricks@csd.harris.com Richard Smith smiddy@pluto.dss.com Frank Solensky solensky@clearpoint.com Michael St. Johns stjohns@umd5.umd.edu Emil Sturniolo emil@doe.dss.com Bruce Taber taber@interlan.com Dean Throop throop@dg-rtp.dg.com Gerard White ger@concord.com Brian Yasaki bky@eco.twg.com 6