home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-96jun.txt < prev    next >
Text File  |  1996-10-07  |  12KB  |  308 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4. The PPP Extensions Working Group met at the Montreal IETF meeting 
  5. on Wednesday, June 26th from 1300-1500 and on Thursday, June 27th 
  6. from 1300-1500.
  7. Minutes of the two meetings follow:
  8.  
  9. Reported by: Ed Allen
  10.  
  11. Wednesday meeting
  12.  
  13. 1. LCP Extensions (draft-ietf-pppext-lcpext-ds-00.txt) 
  14.  
  15. Bill Simpson led a discussion of the various LCP extensions described in 
  16. the document.
  17. Bill said this draft has been on hold waiting for someone who wanted 
  18. to change callback.
  19. An informal poll showed that there are 2 implementations of the 
  20. Identification option, and 2 implementations of callback. Discussion 
  21. revealed there is concern that the callback option is not ready yet.
  22.  
  23. Resolution is that Callback option will be stripped from current draft 
  24. and made into a separate draft, so that the remaining LCP extensions 
  25. can continue on the standards track. draft-ietf-pppext-lcpext-ds will 
  26. then be resubmitted and sent out for working group last call.
  27.  
  28.  
  29. 2. Vendor Extensions (draft-ietf-pppext-vendor-00.txt) 
  30.  
  31. Bill Simpson explained the rationale of this draft. He explained that 
  32. this cannot be standards track document due to no possibility of 
  33. interoperable versions, but noted that CCP already has the same 
  34. vendor-specific option, which is standards-track. Bill asked what do 
  35. people think about going standards track? Area Director Jeff Burgan 
  36. said he thought it would be Informational. 
  37.  
  38. Resolution is that this draft will be sent as Informational RFC by Bill 
  39. Simpson to the IESG.
  40.  
  41. 3. SONET (RFC 1619)
  42.  
  43. Bill Simpson explained that there are already commercial 
  44. implementations of this RFC. Bill explained that PPP has been 
  45. designed to run from very low speeds to very high speeds, and briefly 
  46. explained SONET, which runs at 155 Mbits/sec, with 622 Mbs and 2 
  47. Gbps in development. He explained that although ATM runs over 
  48. SONET, it has a larger overhead than PPP. He noted that one major 
  49. chip vendor has admitted not conforming to SONET spec in loss of state. 
  50. The chip only detects 72 bit sequences of zeros.
  51. Bill proposed to add two sentences and an appendix to PPP over SONET 
  52. which will describe a settable third byte and how to escape long 
  53. sequences of zeros. This text will provide a workaround for the chip 
  54. problem. 
  55.  
  56. 4. Multilink Protocol(MP) (draft-ietf-pppext-multilink-12.txt) 
  57.  
  58. Karl Fox led a discussion of Multilink, RFC 1717. Karl said MP has been 
  59. sent to Draft Standard. 
  60.  
  61. Karl recalled a discussion which took place on the list to the effect 
  62. that the caller being responsible for initiating bringup of links (with 
  63. respect to dialed lines and bandwidth-on-demand). Resolution of this 
  64. issue was that there would be no change to MP. It is on desk of RFC 
  65. editor and will have a new RFC number assigned to it. There was 
  66. discussion as to whether there should be an informational RFC 
  67. describing current practices in this area. It was decided that there is 
  68. sufficient interest, and Dan Brennan volunteered to head up the effort 
  69. to write the informational RFC. 
  70.  
  71. 5. Extensible Authentication Protocol(EAP) 
  72. (draft-ietf-pppext-eap-auth-02.txt and draft-ietf-pppext-eaprsa-
  73. 02.txt) 
  74.  
  75. Karl Fox noted the main document fell off the six month timer. Since 
  76. there are two interoperable implementations the main document will 
  77. be resubmitted. There was interest by three to four vendors in working 
  78. on this extension.
  79.  
  80. 6. Protocol Spoofing Control Protocol(PSCP) (draft-ietf-pppext-spoof-
  81. 00.txt) 
  82.  
  83. The author was not present.
  84. A discussion of the merits of this approach occurred. A representative 
  85. from one vendor mentioned they had done some work on retaining 
  86. context while spoofing, when zero links (retaining context across 
  87. disconnects). One benefit is that a client can retain its dynamically 
  88. assigned IP address.
  89. There was a proposal that doing a spoofing protocol was not 
  90. worthwhile in and of itself.
  91. Long discussion occurred about persistent state, suspend/resume notion, 
  92. spoofing.
  93. Group rejected idea of putting spoofing capabilities into BACP. At least 
  94. one vendor has implemented PSCP. 
  95.  
  96. Resolution was that Dana Blair would work with Ian Puleston (draft 
  97. author) to describe current practices.
  98.  
  99. 7. STAC compression (draft-ietf-pppext-stacker-09.txt) 
  100.  
  101. It was agreed that draft 10 will consist of draft .09 plus fixed typos. 
  102. Draft 10 will then be sent to the IESG for upgrade to proposed standard. 
  103.  
  104. One questioner asked whether anyone has gone ahead w/ Motorola 
  105. license agreement? Only one company said they had executed the 
  106. license agreement. 
  107.  
  108. Hands showed there were about 10 implementers of Stacker. A 
  109. representative from Stac said that there is a deal where you can get 
  110. access to Motorola license proposal from Stac. It contains terms of 
  111. license agreement.
  112.  
  113. 8. Status of other work by PPP WG.
  114.  
  115. CHAP and LQM are now approved Draft Standards, and will get RFC 
  116. numbers soon. Netbios CP is at Proposed Std status.
  117.  
  118. Other drafts:
  119. Status of WCP (draft-ietf-pppext-wcp-00.txt) was discussed. Ed Allen 
  120. explained that WCP can be negotiated using CCP, and is thus not a 
  121. standard which competes with WCP.
  122.  
  123. draft-ietf-pppext-dataencap-03.txt has expired, and as there is no 
  124. interest from the WG, will be allowed to die. 
  125.  
  126. draft-ietf-pppext-encryption-04.txt is at Proposed Standards draft-
  127. ietf-pppext-des-encrypt-01.txt is an informational. draft-ietf-pppext-
  128. frame-relay-03.txt is stds track, and is at PS and will receive an RFC 
  129. number from the RFC editor at some point in the future. 
  130.  
  131. draft-ietf-pppext-snacp-01.txt has been implemented by one vendor, 
  132. and will become and informational RFC.
  133.  
  134. 11. PacBell bakeoff
  135.  
  136. Anita Freeman of PacBell stated there will be another interoperability 
  137. bakeoff either Oct 20-25 or Nov 17-22.
  138. (The October choice was chosen by the WG.) Anita stated that there 
  139. will be a max. of 68 tables. There will be up to 8 PRI interfaces and 136 
  140. BRIs 1st couple days are remedial testing for MP, followed by testing 
  141. for CCP and BACP.
  142. Location is San Ramon, San Ramon Marriott was suggested for advance 
  143. reservations.
  144. bob@Larribeau.com is organizer of the bakeoff. 
  145.  
  146. 12. Assorted other PPP extensions.
  147. Bill Simpson asked the working group about assorted other PPP 
  148. extensions. 
  149.  
  150. IPXCP
  151. Bill Simpson asked the WG if there were any changes need to IPXCP. 
  152. Twelve vendors said they had implemented IPXCP. The WG agreed to 
  153. send IPXCP to IESG as draft standard. 
  154.  
  155. PPP over ISDN (RFC 1618)
  156. Bill said there have questions and comments about this draft. Dana 
  157. Blair will solicit list for comments. 
  158.  
  159. PPP over X.25
  160. A (non) show of hands revealed , nobody in room had implemented this 
  161. one Bill knows of 3 vendors shipping this.
  162.  
  163. There will be an effort to get a number of protocols either to draft std 
  164. status or to kill them.
  165.  
  166.  
  167. ---------------------
  168.  
  169. Thursday meeting
  170.  
  171. 13. BACP - Craig Richards
  172.  
  173. Current draft is draft-ietf-pppext-bacp-03.txt, is based on comments 
  174. from LA IETF meeting and experiences at May Pacbell bakeoff. The 
  175. draft is now in last call status.
  176. Craig said the most recent changes were the removal of Link Drop 
  177. request, Bundle Drop request and 2 other msgs.
  178. He said he improved & clarified phone number format, he noted other 
  179. changes as well.
  180.  
  181. Craig noted there was successful interoperability at PacBell bakeoff. 
  182. All were alpha or beta code.
  183.  
  184. There were questions and suggestions for rewording regarding: 
  185. o section 6.2 Phone-Delta Unique Digits suboption o substituting 
  186. transmitter/receiver for peer. o Link-Drop-query request wording.
  187. o sect 2.1 Link Discriminator, description of wrapping. o discussion re: 
  188. Callback-request value and concern of is value. o link-type option only 
  189. being 8 bits.
  190. Craig indicated he would clarify the wording where necessary. 
  191.  
  192. Karl Fox polled the WG to find out the WG opinion of BACP. A show of 
  193. hands revealed there are 4 BACP implementations and 8 more planned. 
  194. 25 hands indicated they thought BACP was valuable, while zero 
  195. hands thought BACP was not valuable. 
  196.  
  197. 14. Point-to-Point Tunneling Protocol(PPTP) - draft-ietf-pppext-pptp-
  198. 00.txt 
  199.  
  200. Gurdeep Singh Pall presented concepts, terminology, design goals and 
  201. protocol details of PPTP.
  202. He presented Incoming Call states for each end of a tunnel. He also 
  203. presented a comparison between PPTP and L2F. Gurdeep stated future 
  204. goals for PPTP, which included the following: 
  205. o Converge with L2F
  206. o Include new features which have been identified, but which 
  207. are not in PPTP today.
  208. o Leverage other IETF efforts, including IPSEC. Gurdeep provided the 
  209. following URL for PPTP source code: 
  210. http://ftp.microsft.com/developer/drg/pptp/src 
  211.  
  212. Here are some of many questions/discussions following Gurdeep's 
  213. presentation:
  214. o How does PPTP go thru firewall
  215. o How handle shared credentials, and other security issues. 
  216.  
  217.  
  218. 15. Level Two Forwarding(L2F) - draft-ietf-pppext-l2f-02.txt 
  219.  
  220. Andy Valencia discussed a number of detailed L2f issues that are 
  221. outstanding. Some are included here:
  222. o out of seq recovery
  223. o uniform len-type-value encoding
  224. o mandatory/optional flag
  225. o vendor specific fields
  226. o outbound calling
  227. There was a lot of discussion on question of whether to use IP instead of 
  228. UDP. Resolution was to use GRE, which has its own IP protocol number. 
  229. Coulduse and IP prot # instead, and sve 20 bytes pkt hdr. AV has 
  230. concern that if eeveryone did this, all IP #s would be used up Concern 
  231. that firewalls would not be able to filter on IP prot #. Pat asks why not 
  232. use GRE, which has prot number Disc of Ipv6
  233.  
  234. There was discussion of various other issues, such as: 
  235. o how IPv6 fits in
  236. o MTU issues
  237. o clear text passwords across tunnel when PAP or SLIP is used o pre-
  238. encrypted passwords
  239. o other possible security attacks
  240. o the second negotiation of LCP, and how client LCP 
  241. implementations handle LCP going down.
  242. o minimal or no L2f header
  243.  
  244. A discussion of the LCP options recommended for use with L2F suggested 
  245. the following options:
  246. o Multilink
  247. o 1500 byte MTU
  248. o others to be solicited from the PPP WG list. 
  249.  
  250. Andy presented L2F status as this:
  251. 1. holding up well in IETF
  252. 2. interoperable implementations
  253. 3. L2F and PPTP folks have been talking
  254.  
  255. Andy categorized commonalities between L2F and PPTP and also 
  256. aspects unique to each.
  257.  
  258. 16. Combine PPTP and L2F
  259.  
  260. After discussion a goal was stated to combine PPTP and L2F before the 
  261. next IETF meeting.
  262. Proponents of each will work together to come up with a new draft, 
  263. tentatively called L2TP.
  264.  
  265. Andy Valencia made some suggestions as to what L2TP would inherit 
  266. from PPTP and L2F.
  267. L2TP would:
  268. Keep layer 2 tunnel
  269. keep GRE format
  270. Adopt uiformat content format
  271. L2TP would inherit from PPTP:
  272. media semantics (BACP)
  273. calling (but modularize)
  274. optional flow control
  275. L2TP would inherit from L2F:
  276. optional ID
  277. optional LCP
  278. others were mentioned
  279.  
  280. Andy also highlighted some L2TP futures as being: 
  281. encryption
  282. integration with BACP
  283. multicasting
  284. fancy queuing issues
  285.  
  286. There was a discussion of using a reliable channel for data. 
  287.  
  288. Ian Duncan agreed to set up a mailing list for discussions related to L2TP 
  289. and to send the email address to the PPP list. 
  290.  
  291. 17. Secure Dynamic Tunneling Protocol(SDTP) Pat Calhoun and Ellis 
  292. Wong 
  293.  
  294. Pat Calhoun and Ellis Wong presented concepts of SDTP. The following 
  295. are some SDTP concepts:
  296. o can be used as a router to router tunneling protocol o can be used as a 
  297. NAS to gateway tunneling protocol o PPP is terminated at the NAS for 
  298. dial-up access. o security for the tunnel uses IPSEC
  299. o high scalability due to multiple tunnel capability o multiple protocol 
  300. support (any level 2 and level 3) o some SDTP concepts are borrowed 
  301. from Mobile IP 
  302.  
  303. Questions/discussion followed regarding how SDTP is different from 
  304. ATMP. Ellis Wong agreed to send a path to slides to the mailing list. 
  305.  
  306. Some participants expressed the opinion that SDTP concepts should be 
  307. combined into L2TP.
  308.