home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  7KB  |  162 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. Compression Control Protocol
  10.  
  11. Fred Baker opened the meeting, advising the working group on the status
  12. of the issues with Motorola regarding the Compression Control Protocol.
  13. On 1 November, Steve Coya, Executive Director of the IETF, advised Fred
  14. that
  15.  
  16.  
  17.      ``I received a letter in the mail from Darlene Stockley at
  18.      Motorola.  In it, she states that Motorola will offer licenses
  19.      on fair, reasonable and non-discriminatory terms.  She closes
  20.      by saying they will have terms available by the end of the
  21.      year.''
  22.  
  23.  
  24. A copy of that letter was sent to Fred as well.  On 1 December, Motorola
  25. apparently sent a letter to Steve (copying Fred) describing those terms.
  26. Neither Steve nor Fred have received it at this point.  Fred will advise
  27. the working group of the contents of the second letter when he receives
  28. it.
  29.  
  30.  
  31. PPP Banyan Vines Control Protocol
  32.  
  33. Fred, in the absence of it's author (Steve Senum), presented the updated
  34. draft of the PPP Banyan Vines Control Protocol (BVCP). This draft is
  35. draft-ietf-pppext-vines-01.txt.  It formalizes the use of the control
  36. and data protocols specified by Assigned Numbers, and three options
  37. relating to routing protocol messages and fragmentation.  The working
  38. group approved advancement to Proposed Standard.
  39.  
  40.  
  41. PPP XNS IDP Control Protocol
  42.  
  43. Fred, in the absence of it's author (Steve Senum), presented the updated
  44. draft of the PPP XNS IDP Control Protocol (XNSCP). This draft is
  45. draft-ietf-pppext-xnscp-00.txt.  It formalizes the use of the control
  46. and data protocols specified by Assigned Numbers, and proposes no
  47. options.  The working group approved advancement to Proposed Standard.
  48.  
  49.  
  50.  
  51. PPP Encryption Control Protocol
  52.  
  53. Gerry Meyer presented the PPP Encryption Control Protocol (ECP). This is
  54. draft-ietf-pppext-encryption-00.txt.  This protocol is modelled on the
  55. CCP, including the use of separate informational documents describing
  56. separate encryption procedures.
  57.  
  58.  
  59.    o Negotiation of encryption using PPP
  60.  
  61.       -  Protects against eavesdropping on that link.
  62.       -  Dependent on the encryption algorithm used.
  63.       -  Care with which any `secrets' are protected.
  64.       -  Protection is not end-to-end (multiple hops).
  65.  
  66.  
  67.    o Main Features
  68.  
  69.       -  Encryption algorithm negotiated using PPP.
  70.       -  Similar concept to Compression negotiation.
  71.       -  Standard encryption algorithms.
  72.       -  Manufacturer specific encryption algorithms (IEEE 802 OUI).
  73.       -  Algorithm may be different in each direction.
  74.       -  Negotiate above or below multilink (different protocol).
  75.       -  Unlike CCP, Reset and Reset Ack not supported.
  76.       -  If negotiation fails - call is aborted.
  77.  
  78.  
  79. One change was suggested by Jeff Weiss (Magnalink Telco), to add an
  80. encryption reset and acknowledge, for use by non-self-synchronizing
  81. encryption procedures.  Gerry had been concerned that the procedure
  82. might be problematic due to Motorola's compression patents.  Jeffrey
  83. indicates that he holds a patent that Motorola cites as prior art.  This
  84. patent specifies a reset/acknowledge procedure.  He will give the
  85. Executive Director the necessary letter.
  86.  
  87. When Gerry has updated the draft, we will ask for a consensus on the
  88. list and send the document to the IESG for consideration as a Proposed
  89. Standard.
  90.  
  91.  
  92. Synchronous Data Compression Consortium
  93.  
  94. The Synchronous Data Compression Consortium made a presentation to the
  95. working group at the last IETF meeting, describing its use of PPP
  96. between DSUs.  It has now largely completed its design and is about to
  97. ask TR 30.1 to recommend the use of the procedure.  These documents are:
  98.  
  99.  
  100.    o PPP for Data Compression in Data Circuit-Terminating Equipment
  101.      (DCE)
  102.      draft-ietf-pppext-dce-compress-00.txt
  103.  
  104.    o PPP LZS-DCP Compression Protocol (LZS-DCP)
  105.      draft-ietf-pppext-lzs-dcp-00.txt
  106.  
  107.    o PPP Serial Data Transport Protocol (SDTP)
  108.      draft-ietf-pppext-sdtp-00.txt
  109.  
  110.  
  111. There was no representative present to present them.  David Patrick of
  112. Motorola stood to describe what they are and lead a discussion on them.
  113. Several questions were raised concerning technical aspects.  The people
  114. concerned about them will contact the author and discuss them on the
  115. dsu-compress[-request]@paradyne.com list.  These will be published as
  116. Informational RFCs when complete, due to their status in ANSI.
  117.  
  118.  
  119. Other Business
  120.  
  121. Discussion then continued with subjects from the floor:  the development
  122. of IPCP, LQM, Authentication, and AppleTalk.
  123.  
  124. IPCP is being updated by Gurdeep Singh Pall of Microsoft.  On
  125. 6 December, he advised the chair and the PPP Editor that the document
  126. had been posted for anonymous FTP. He is soliciting those inputs before
  127. posting an Internet-Draft.
  128.  
  129. LQM, apart from a few typographic errors, appears to have several
  130. interoperable implementations and serve its purpose well.  Bill Simpson
  131. will update it and post a new Internet-Draft.  We expect to send this in
  132. as a Draft Standard.
  133.  
  134. In the currently widely held security model, exchange of passwords in
  135. the clear does not appear wise.  Thus, PAP is no longer a recommended
  136. procedure.  CHAP, however, is still believed to be acceptable for a
  137. certain class of problems.  Bill will create a new Authentication
  138. Internet-Draft which does not have PAP in it.  The IESG can declare
  139. RFC 1334 ``Historical,'' making PAP a historical procedure, and the new
  140. CHAP-only draft will become a Draft Standard when a consensus on the
  141. list supports that.
  142.  
  143. The Kerberos and one-time passwords effort (Carrels, Blunk, and Parker)
  144. has not to date produced a requirements document.  Two companies,
  145. however, have deployed incompatible authentication procedures of that
  146. type.  Brad Parker will update the draft-ietf-pppext-gap-00.txt draft
  147. according to deployment experience, and we will publish that, probably
  148. as a Proposed Standard.  Fred will contact Larry Blunk to determine
  149. whether the combined effort is still likely to occur.
  150.  
  151. Brad Parker indicates that he has received no comments on his AppleTalk
  152. draft.  Working group members are asked to read the draft and comment on
  153. it.
  154.  
  155. Craig Fox and Moon are checking with their management concerning
  156. PPP-a-thons adjoining the Danvers and Stockholm IETFs.  These would be
  157. for general protocol testing and testing on ISDN, X.25, etc.,
  158. respectively.  Rachel Willmers of Spider is also trying to organize some
  159. testing.  This will be discussed further on the list as we determine
  160. what facilities are available and what folks are ready to test.
  161.  
  162.