home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / cipso / cipso-minutes-92jul.txt < prev    next >
Text File  |  1993-02-17  |  9KB  |  219 lines

  1. Editor's Note:  Minutes Received 7/23
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Ron Sharp/AT&T
  7.  
  8. Minutes of the Commercial Internet Protocol Security Option Working
  9. Group (CIPSO)
  10.  
  11. Due to other IETF meetings and additional TSIG plenary sessions the
  12. Working Group met for only six hours this meeting.  The primary
  13. discussions involved the IETF/TSIG relationship and how to allow and
  14. encourage more participation from other IETF members.  There was also
  15. much discussion concerning the Internet Draft entitled ``Son of IPSO''
  16. that was submitted by Michael StJohns.
  17.  
  18. The format for this meeting changed a little.  Issues were presented and
  19. discussed, however there was no voting to determine the Group's
  20. consensus.  It was felt by some new attendees that this led to the idea
  21. that all work and decisions was done at the meetings and if you could
  22. not attend the meetings then you were left out.  That was not the
  23. intended purpose of voting, however, it must be admitted that the result
  24. may still be the same.  We encourage anyone to participate either at the
  25. meetings or electronically.  Ron Sharp has been trying to push people
  26. into using the electronic media more but it has been used only a little.
  27. When an issue does come up on the mailing list and is not resolved Ron
  28. includes it in the Agenda for the next meeting.  Even if there is a
  29. consensus at the meeting the issue is still alive as long as someone is
  30. willing to discuss it in any forum.
  31.  
  32. Ron will go over the issues discussed and the resolutions that were
  33. purposed.  Please respond to the mailing list if you disagree with any
  34. of the proposals.  If Ron hears no discussion he will make the
  35. appropriate change to the specification.  Even then the issue is not
  36. dead and may be brought at a later time when some things may be clearer,
  37. though the sooner the better for everyone.
  38.  
  39. Issue 1:  Changes to CIPSO Version 2.2
  40.  
  41. There were several nit changes to the CIPSO specification for accuracy
  42. and readability.  These changes will be marked in the next release of
  43. the CIPSO specification.  The process for releasing the specification
  44. was also changed.  As editor of the specification Ron will gather the
  45. comments from the meetings and the mailing list and will make the
  46. appropriate changes.  He will first put the new specification out on the
  47. mailing list for comments.  After two weeks or so, depending on the
  48. comments received, Ron will send a revised version to the Internet
  49. Drafts database.  He hopes to have a new draft of CIPSO 2.2 out for
  50. comments soon that will include the last two meetings and discussions
  51. between the meetings.
  52.  
  53. Issue 2:  CIPSO MIBs
  54.  
  55. Tabled.
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. Issue 3:  Router Participation
  64.  
  65. There were at least two router vendors at this meeting from cisco and
  66. 3com.  It is hoped that more will be heard from them on the mailing list
  67. describing their needs and requirements.  The cisco representative said
  68. that cisco is waiting for a decision to be made as to which is going to
  69. be the next IP label.  She said they were about to go with CIPSO when
  70. SIPSO came out.  We need to get to one specification, one label soon.
  71.  
  72. Issue 4:  Test Plan
  73.  
  74. The next IETF CIPSO Working Group meeting will be in conjunction with
  75. TSIG in Minneapolis, Sept 22-24.  At this meeting several vendors will
  76. bring their CIPSO implementation and test interoperability.  Cray has
  77. graciously offered to host the meeting for the interoperability test.
  78. Aaron Schuman of SGI wrote a test plan to use.  The plan was reviewed
  79. and several changes were made.  The primary change was to use telnet as
  80. the application to test basic CIPSO functionality.  Telnet was chosen
  81. since it was common to all implementations.  Aaron will get a revised
  82. test plan out prior to the next meeting.
  83.  
  84. Issue 5:  CIPSO, BSO Translation
  85.  
  86. Aaron presented a solution to allow a CIPSO gateway machine to translate
  87. BSO labels to CIPSO labels and CIPSO labels to BSO. The security level
  88. would mapped to the corresponding value for the other label.  The BSO
  89. PAFs would map to CIPSO DOIs.  Each combination of PAf flags would be a
  90. unique DOI. Mike suggested including this map directly in the CIPSO
  91. specification.
  92.  
  93. Issue 6:  BSO tag type
  94.  
  95. Tabled.
  96.  
  97. Issue 7:  Future of CIPSO Working Group
  98.  
  99. The Group decided to meet next time in conjunction with TSIG. A lot of
  100. electronic discussion is needed to resolve some of the remaining issues.
  101. The primary issues are described at the end of the Minutes.  Steve
  102. Crocker agreed to work with us to resolve all issues between CIPSO and
  103. SIPSO prior to the next IETF meeting.  The goal is to have a CIPSO
  104. specification that is acceptable to the IETF and the CIPSO vendors which
  105. incorporates the best of both specifications.  Without a resolution
  106. soon, we will end up with three standards.  IPSO will still be out there
  107. and included in new systems since there is no new unified label.  CIPSO
  108. vendors will continue to ship CIPSO, but it will not be based on an IETF
  109. standard which they would prefer and SIPSO will be trying to get vendor
  110. participation.
  111.  
  112. Issue 8:  CIPSO Option Processing
  113.  
  114.  
  115.                                    2
  116.  
  117.  
  118.  
  119.  
  120.  
  121. MSJ felt that the description of option processing in the specification
  122. should be split out by end systems, intermediate systems, and routers.
  123. I will look at SIPSO and make appropriated changes to make the
  124. processing clearer.
  125.  
  126. Overall it was a good meeting.  The Group did not get many issues
  127. covered but there was more dialogue as to what is expected of CIPSO to
  128. finally get to Proposed Standard stage which is long overdue.  Ron feels
  129. there are still four primary issues that must be addressed and resolved
  130. between the CIPSO vendors and a few other IETF members.  These are
  131. listed below:
  132.  
  133.  
  134.    o A. IPSO backward compatibility.
  135.      MSJ feels that the first 4 bytes of CIPSO could look like IPSO and
  136.      thus have interoperability.  The PAFs would represent a unique DOI
  137.      like discussed in issue 5 above.  If we could truly get backward
  138.      compatibility then we could more quickly move to one IP security
  139.      option which is what everyone wants.  There is the question of
  140.      whether existing implementations like BLACKER can accept these new
  141.      CIPSO options without modifications.  If modifications are
  142.      necessary than why not just move to a full CIPSO and get the added
  143.      flexibility and interoperability a full CIPSO implementation
  144.      offers.  There is also concern that this would tie CIPSO to a
  145.      particular security policy, that of the US DOD when the commercial
  146.      market has show little interest in hierarchical labels.
  147.  
  148.    o B. Number of CIPSO tags supported in this RFC
  149.      The current draft has three tags to allow for large category sets.
  150.      MSJ questions whether 3 are necessary.
  151.  
  152.    o C. CIPSO currently allows for tag types above 127 to be defined by
  153.      the DOI. This allows for support of new policies such as integrity
  154.      and to hide classified formats and definitions.  There is a concern
  155.      that this could lead to interoperability.  The Working Group has
  156.      been working on this issue and the current draft includes words
  157.      that state that implementations that support tags above 127 must be
  158.      able to configure a DOI that does not require those tags.  This
  159.      will assure communication using standard well defined tags in the
  160.      event of an emergency like the Gulf war.
  161.  
  162.    o D. Inclusion of application to TCP or UDP interface processing
  163.      rules.
  164.      It is felt that, while this is a good idea, it may belong in an RFC
  165.      that describes a network level security option.  SIPSO includes
  166.      some of these rules, however they are included as suggestions.
  167.  
  168.  
  169. The above should cover the last meeting and where the Group is
  170. currently.  If anything has been missed, please respond to the mailing
  171. list.  Discussion of the four issues identified is needed.  If anyone
  172. feels there are others than please include them.  There are other issues
  173. such as options processing, however Ron has confidence that these can be
  174.  
  175.                                    3
  176.  
  177.  
  178.  
  179.  
  180.  
  181. worked out.
  182.  
  183. Thanks for attending the meeting and helping out.  A special thanks to
  184. Aaron Schuman who presented two homework items AND recorded the minutes
  185. which were used to produce these minutes.  Ok now lets hear some
  186. discussion on the remaining issues.
  187.  
  188. Attendees
  189.  
  190. George Abe               4247140@mcimail.com
  191. J. Allard                jallard@microsoft.com
  192. Randall Atkinson         atkinson@itd.nrl.navy.mil
  193. Suhas Badve              badve@cup.hp.com
  194. Uri Blumenthal           uri@watson.ibm.com
  195. C. Douglas Brown         cdbrown@sandia.gov
  196. Robert Ching             natadm!rching@uunet.uu.net
  197. Mark Christenson         mgc@cray.com
  198. Frank Coviello          
  199. John Ioannidis           ji@cs.columbia.edu
  200. James Keller             j.keller@sprint.com
  201. Paulina Knibbe           knibbe@cisco.com
  202. Kent Malave              kent@chang.austin.ibm.com
  203. Mary Christine O'Connor  oconnor@interlan.com
  204. Charles Perkins          perk@watson.ibm.com
  205. Paul Sangster            sangster@ans.net
  206. Aaron Schuman            schuman@sgi.com
  207. Ron Sharp                rls@neptune.att.com
  208. Jeremy Siegel            jzs@nsd.3com.com
  209. Richard Slade            ricks@ssd.csd.harris.com
  210. Michael St.  Johns       stjohns@umd5.umd.edu
  211. Dean Throop              throop@dg-rtp.dg.com
  212. James Watt               jamesw@newbridge.com
  213. Luanne Waul              luanne@wwtc.timeplex.com
  214. Peter Williams           p.williams@uk.ac.ucl.cs
  215.  
  216.  
  217.  
  218.                                    4
  219.