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