home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  5KB  |  147 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Fred Baker/cisco Systems
  5.  
  6. Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT)
  7.  
  8.  
  9. Agenda
  10.  
  11.    o Intellectual Property Rights -- Frank Kastenholtz
  12.    o Implications for Compression -- Fred Baker
  13.    o Encryption/DES -- Gerry Meyer and Keith Sklower
  14.    o Multilink Procedure -- Keith Sklower
  15.    o Authentication Protocols -- Dave Carrels
  16.  
  17.  
  18. Frank Kastenholtz:  Motorola Patent Claim
  19.  
  20. Motorola has not met the requirements of RFC 1602; they have not given
  21. the IESG a blanket license for the use of their patent claims.  Within
  22. the context of RFC 1602, the working group has two choices:  continue to
  23. hope that the situation will change, or change the CCP and ECP drafts so
  24. that they do not infringe on the patent claims.
  25.  
  26. The consensus of the working group is to remove references to the
  27. HISTORY RESET REQUEST and HISTORY RESET RESPONSE from the CCP and the
  28. ECP, and indicate that CCP should run over reliable PPP (LAPB). Removing
  29. all reference to resetting the history buffer is believed to obviate any
  30. claim Motorola has regarding these drafts.
  31.  
  32. Actions:  Dave Rand to modify the CCP draft accordingly.  The authors of
  33. the compression algorithm drafts to update drafts if necessary.  Gerry
  34. Meyer to modify the ECP draft accordingly.
  35.  
  36.  
  37. Keith Sklower:  DES Electronic Codebook Encryption Algorithm
  38.  
  39. Keith described his draft.  The consensus was that the draft was
  40. acceptable and standardization of ECP should continue based on it.  DESE
  41. is an informational draft supporting ECP.
  42.  
  43. Keith indicates that the key is ``derived'' from the authentication/EID
  44. information; it is ``derived'' in the sense that one of some number of
  45. perviously configured keys is selected on the basis of that information.
  46. Consensus was to change the word to ``selected''.  If there are no other
  47. more substantive changes required (and at this point there does not
  48. appear to be) this can be handled by the RFC Editor.
  49.  
  50. Dave Carrel suggested that we need a way to specify and perhaps execute
  51. a key exchange algorithm in ECP; we discussed an option of the general
  52. form:
  53.  
  54.         +-------+-------+-------+-------
  55.         | Type  | Length| Code  | 0 or more bytes of data
  56.         +-------+-------+-------+-------
  57.  
  58.  
  59.         Code = 1   use hard coded keys, perhaps selected via
  60.                    authentication/EID information (default)
  61.  
  62.         Code = 2   key exchange algorithm involving the data
  63.  
  64.  
  65. If there are several possible key exchange algorithms, they should be
  66. enumerated.  This detail to be clarified in list discussion.
  67.  
  68. The draft explicitly does not define a key exchange algorithm, and we do
  69. not particularly want to get into defining the key exchange; the
  70. objective is to enable a key exchange defined by the IPSEC Working Group
  71. to be used.
  72.  
  73. There is some belief that the EBC Mode is inadequate, that Cypher Block
  74. Feedback should be used or at least defined.  This will be discussed on
  75. the list.
  76.  
  77. Actions:  Dave to discuss key exchange on the list; if favorable
  78. consensus is formed, Gerry to update draft appropriately.  Upon closure
  79. of this item, Updated ECP draft to Proposed Standard and DESE to
  80. Informational RFC.
  81.  
  82.  
  83. Keith Sklower:  PPP Multilink Revision
  84.  
  85. Keith reported that the California Multilink/ISDN interoperability
  86. testing prior to the Danvers meeting indicated the desirability of a
  87. call-back control protocol to mitigate line-flapping when different
  88. systems have different criteria of when a second B-channel is needed.
  89. (Keith had volunteered to participate in such work, but not do it
  90. unilaterally).  No progress has been made.  Vern Schryver, in a private
  91. communication, suggested to Keith that Ascend be contacted to see if
  92. they would be willing to disclose their protocol to be used (even if
  93. only as a basis for discussion).
  94.  
  95. Consensus was not to hold up RFC 1717bis for inclusion of any such
  96. protocol.
  97.  
  98. Revisions that the current draft embodies:
  99.  
  100.  
  101.    o Clarify:  must use MMRU or MMRU+SSNHF: cannot use SSNHF alone to
  102.      negotiate M/L
  103.  
  104.    o Sequence numbers start from zero
  105.  
  106.    o No default for MMRU; implementations MUST support MMRU=1500
  107.  
  108.    o No NAK of EID
  109.  
  110.    o Must use same SNHF on all links to same peer; other links may use
  111.      same or different SNHF
  112.  
  113.  
  114. Revisions needed:
  115.  
  116.  
  117.    o OK to stop using M/L headers if only one link up in certain cases.
  118.  
  119.    o When second link passes LCP and Authentication, must use M/L
  120.      headers and assign next fragment number to new link.
  121.  
  122.    o Draft specifies one anonymous bundle to be used in the case of no
  123.      authentication and no EID provided.  RK Hariram commented on the
  124.      list that this would fail in the case of one system connected to
  125.      two others.  The consensus already had been to allow (multiple)
  126.      manually configured bundles, but the draft did not actually say
  127.      this.  The draft should be changed to make this clear.
  128.  
  129.  
  130. Kevin Pierce's MP ISDN Modes Comment
  131.  
  132. Kevin sent a longish note to the list asking for clarification of
  133. certain operating modes in PPP M/L. Some of the modes are problematic,
  134. and there seems to be no reason to include the discussion in the draft
  135. itself.
  136.  
  137. Action:  Keith and Kevin to correspond and settle issues.
  138.  
  139.  
  140. Dave Carrel:  EAP Draft
  141.  
  142. An EAP draft was posted too late to discuss at the IETF, and the
  143. relevant people were for the most part not present.
  144.  
  145. Action:  This will be taken to the list.
  146.  
  147.