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