home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-95dec.txt < prev    next >
Text File  |  1996-06-03  |  8KB  |  203 lines
  1. CURRENT MEETING REPORT
  2.  
  3.  
  4. Minutes of the Point-to-Point Protocol Extensions (pppext)
  5.  
  6. Reported by Fred Baker, Cisco Systems
  7.  
  8.  
  9. We are forwarding a variance request for CCP/ECP that indicates that 
  10. we will accept Motorola's letter of intent on these and advance these 
  11. documents.  Frank has posted an Internet Draft of the variance to this 
  12. end.  There will be an extended last call to consider this, going into 
  13. January.  We should expect acceptance of the existing CCP/ECP 
  14. documents for Proposed Standard status in February.
  15.  
  16. Motorola's letter of intent states that Motorola will license the use of 
  17. its patents to all who apply for reasonable terms.
  18.  
  19. The problem in the variance proposal is the dependence on Motorola 
  20. carrying out its promise to reasonably license its patents.  Vendors who 
  21. deal with Motorola should report their experience to the PPP list as a 
  22. test of this, as this report will be considered in taking the CCP and ECP 
  23. to Draft Standard.
  24.  
  25. IPCP Update to Draft Standard (Pall) draft-ietf-pppext-ipcp-
  26. network-00.txt
  27.  
  28. Update to the IPCP left some ambiguity in RFC 1332. This draft 
  29. primarily clarifies RFC 1332 without adding new features.
  30.  
  31. Option 3 (IP address negotiation) is at issue.
  32.  
  33.  
  34. Announcing an IP Address
  35.  
  36. Peer announces IP Address; you may:
  37. o  Ack the address
  38. o  Nak with a different (non-zero) address
  39. o  Reject the option (in effect accepting the address)
  40.  
  41. Peer requests 0.0.0.0; you may
  42. o  Nak with an address, assigning that address
  43. o  Reject the option (saying the link is unnumbered)
  44.  
  45. In addition, please add text to say that folks should not Ack this 
  46. packet.
  47.  
  48. Peer requests with no option; you may
  49. o  Say nothing in the Ack
  50. o Nak 0.0.0.0; Ack with their own address or router ID.  This permits 
  51.   the system to ask its neighbor what its router ID is.
  52.  
  53. It was agreed that a note will be added pointing to other IP options, 
  54. such as the address of the DNS server.  Those which may be negotiated 
  55. should use the DHCP INFORM option.
  56.  
  57. Updates to Draft Standard (Simpson)
  58. o  draft-ietf-pppext-chap-ds-00.txt
  59. o  draft-ietf-pppext-lqm-ds-00.txt
  60.  
  61. We are going to draft standard on these two, and these drafts are 
  62. clarification edits.
  63.  
  64. Implementors of these protocols are requested to send a note to the chair 
  65. identifying their CHAP implementations, and say with whom they 
  66. have tested interoperability.
  67.  
  68. US Robotics, Compatible Systems, Cisco, Bay Networks, Xyplex, and 
  69. 3COM have done LQM implementations, but need an interoperability 
  70. test.
  71.  
  72. LCP Extensions
  73. o  Endpoint ID (Xyplex, Cisco, Network Systems): This is a go.
  74. o  Callback (Compatible, Cisco, Combinet, Digiboard): This needs 
  75.    further updates for time before callback occurs.  We also need to 
  76.    discuss the option on the list
  77. o  Compound Frames: Let's drop this extension.
  78. o  Multiple FCS: Let's drop this extension
  79. o  Self Describing Pad: SGI?
  80.  
  81. Multilink: (Sklower)
  82. o  draft-ietf-pppext-des-multi-12.txt
  83.  
  84. There have been clarifying updates, requiring no operational changes.  
  85. Discussion of those edits will have to happen on the list, however.
  86.  
  87. Ascend MP+
  88. There was a general consensus in the room that proposals made to 
  89. incorporate features from Ascend MP+ (which has advocates) should 
  90. not hold up revision and republishing of the Multilink Specification; 
  91. rather that these features should become additional control protocols 
  92. that might be useful on any dial line and not just a multilink dial line.  
  93. Multilink should target any line group, not specifically dial or ISDN 
  94. lines or any other specific line type.
  95.  
  96. Craig Richards (Shiva) will post a draft describing new control 
  97. protocols to implement the functionality of Ascend MP+.  This will 
  98. differ from Ascend's proprietary implementation.
  99.  
  100. EAP Authentication: (Blunk et al)
  101. o  draft-ietf-pppext-eap-auth-01.txt
  102.  
  103. MD5 is the default authentication approach for EAP, and various 
  104. updates have been made per comments from Stockholm.  One issue 
  105. raised there was the user interface definition in the specification, 
  106. which was too much.  This was entirely removed in the current draft, 
  107. and that appears to be too much.  The right level is a hint that says 
  108. that the password is a secret or something else, and therefore should or 
  109. should not be echoed. Token Card Type is debated; it may not be useful.
  110.  
  111. Network Express and Soliton Systems have implemented the RSA 
  112. implementation and interoperate.
  113.  
  114. Dave Carrel mentioned mutual authentication; there is a "man in the 
  115. middle" attack possible in CHAP, which would be obviated by one peer 
  116. requiring that the other peer also authenticate him.  This is relevant to 
  117. Kerberos 5, which includes an IP Address in the credential.  One 
  118. suggestion is to deal with this by using timing and challenges 
  119. subsequent to the authentication phase.  Another suggestion is that 
  120. when A receives an LCP request from B which does not require 
  121. authentication and wants mutual authentication, it could LCP Nak 
  122. with an authentication option on the LCP Nak.
  123.  
  124. o  draft-ietf-pppext-eaprsa-00.txt
  125.    Bill Whelan
  126.  
  127. RSA Type 9 Public Key Authentication proposal, using the ISO X.509 
  128. certificate.
  129.  
  130. Network Express and Soliton Systems have implemented the RSA 
  131. implementation and interoperate.
  132.  
  133. Certificate format appears to be problematic.  The certificate needs a 
  134. type, preferably a well-known type, that is revocable and is available 
  135. to anyone with an RSA license and/or internet access.  The issue here is 
  136. the purchase of ISO X.509.
  137.  
  138. Alternative Compression Proposal (Mader)
  139. o  draft-ietf-pppext-wcp-00.txt
  140.  
  141. Bay Networks Compression Protocol is a lightweight reliable 
  142. compression protocol.  The issue is the perceived heaviness of LAPB.
  143.  
  144. Given the variance on CCP, it is not clear that this fills a real need, but 
  145. it has many good ideas.  Keith will confer with Dave Rand on a follow-
  146. on to CCP with the additional options.  He continues to believe that 
  147. WCP itself should become a standard protocol, and is invited to make 
  148. that case on the list.
  149.  
  150. LZS-DCP Compression (Schneider, Friend)
  151. o  draft-ietf-pppext-lzs-dcp-01.txt
  152.  
  153. Add a bit to support moving the check field to the end of the packet, as 
  154. used by Stac's new hardware.
  155.  
  156. Option 23 padding - this should be done using self describing pad if 
  157. padding is required.
  158.  
  159. This was taken to the list.
  160.  
  161. PPP/FR and the Data Encapsulation Draft
  162.  
  163. A lunch meeting was held to discuss the future of these drafts, which 
  164. was attended by Keith Sklower, Keith Mader, Bill Simpson, Joel 
  165. Halpern, Andy Malis, Fred Baker, and Frank Kastenholtz.
  166.  
  167. We agreed that the basis of discussion should be a set of criteria.  The 
  168. criteria we chose were:
  169.  
  170. Both drafts should be advanced as Proposed Standard if and only if 
  171. they had clearly differentiated applicability-if there were two or 
  172. more different problems and neither approach solved all of them.
  173.  
  174. Since the Frame Relay Forum has its own compression/encryption 
  175. specification, one or both should advance to Proposed Standard if and 
  176. only if additional PPP features are in view.
  177.  
  178. There has been an assertion that Data Encapsulation is the preferable 
  179. approach because it preserves the same data encapsulation. 
  180. Implementation experience is a guide to determining whether vendors 
  181. feel that this is a real issue.
  182.  
  183. We observed that three vendors, Xyplex and two unnamed vendors, 
  184. have implementations or implementations in progress of PPP/FR, and 
  185. no vendor has indicated plans to implement Data Encapsulation.  
  186. Therefore, we determined that preservation of the data encapsulation 
  187. is not a vendor concern.
  188.  
  189. We also noted that Authentication has always been mentioned as a 
  190. reason for parameter negotiation, and that some vendors already 
  191. implement Van Jacobsen Header Compression on Frame Relay.  
  192. Therefore, there is additional purpose.
  193.  
  194. We also note that all vendors present report market demand, and that 
  195. this demand specifically references PPP/FR. We could not identify a 
  196. set of applications where one would clearly prefer Data Encapsulation 
  197. given that PPP/FR was implemented.
  198.  
  199. Therefore, the consensus reached was that PPP/FR should advance 
  200. with all due haste to Proposed Standard, and that Joel and Keith 
  201. Mader would discuss the possible need for Data Encapsulation, and 
  202. would be free to publish it as an experimental RFC if they so choose.
  203.