home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-97aug.txt < prev   
Text File  |  1997-10-10  |  15KB  |  436 lines
  1. IETF PPPEXT WG 
  2. August 11, 1997 - Day One
  3. Chair - Karl Fox    karl@ascend.com
  4. Reported by - Matt Holdrege        matt@ascend.com
  5. 89 attendees.
  6.  
  7. IP Header Compression over PPP
  8.         draft-engan-ip-compress-00.txt
  9.         Stephen Casner <casner@precept.com> 
  10.  
  11. Proposed changes to IPCP and IPv6CP
  12. Allow multiple instances of IP-Compression-Protocol option
  13. Need nine PPP packet types assigned. Five can be 16-bit. Avoids problem of
  14. negotiating inconsistent settings between Ipv4 & Ipv6.
  15.  
  16. Option Format
  17. FULL_HEADER (uncompressed)    16-bit
  18. COMPRESSED_NON_TCP        8-bit
  19. COMPRESSED_TCP            8-bit
  20. COMPRESSED_TCP_NODELTA    16-bit
  21. COMPRESSED_UDP            8 & 16
  22. COMPRESSED RTP            8 & 16
  23. CONTEXT_STATE            16-bit
  24.  
  25. Option Flags
  26.  [R] RTP_COMPRESSION
  27. [N] NON_TCP_COMPRESSION
  28. [T] TCP_COMPRESSION
  29. [S] COMP_SLOT_ID
  30. [V] VJ_COMPRESSION 
  31. The Expect Reordering flag was struck since order is a PPP requirement.
  32.  
  33. Craig Fox noted that since we are running out of 8-bit protocol ID's, we
  34. should allow even numbers. Implementations should negotiate the ability to
  35. handle even numbered ID's. Karl Fox noted that we have currently used 75%
  36. of the 8 bit numbers. This needs to be discussed on the list.
  37.  
  38. Steve will submit a new draft with 1) IPCP option exclusive with VJ
  39. compression, and 2) eliminating as many of the option flag bits as possible
  40. for use with PPP.  Karl will support Steve sending an announcement to the
  41. list for assigning the 9 needed ID's.  If no one complains, it will be
  42. approved.
  43.  
  44.  
  45. L2TP Security Extensions for Non-IPSEC networks
  46.         draft-ietf-pppext-l2tp-sec-01.txt
  47.         Pat Calhoun
  48.  
  49. Benefits:
  50. Increased security
  51. Reduces L2TP Denial of Service attack
  52. - injection of stop-ctl-req
  53. - L2TP "syn" attack (really a sccrq attack)
  54. - Injection of set-link-info
  55.  
  56. IV support increases randomness
  57. Supports replay protection
  58. Lightweight but good algorithm. (HMAC-MD5-96)
  59.  
  60. Costs:
  61. Larger header sizes
  62. Additional processing
  63. No encryption
  64.  
  65. Issues:
  66. Should TID & CID be random? Not if you are hashing on your TID
  67. Encryption should be end-to-end
  68.  
  69. Motivation:
  70. A single authentication scheme which is not a link layer specific
  71. It is still not clear that IPsec will scale in an L2TP network
  72.  
  73. It was noted that this draft needs a way to negotiate a way to handle this
  74. scheme on the control messages but not the data.
  75.  
  76.  
  77. PPP LCP CallBack
  78.         draft-ietf-pppext-callback-ds-01.txt
  79.         Discussion of interoperability experience
  80.  
  81. Only Cisco seems to supports it.
  82.  
  83. PPP LCP Self Describing Padding
  84.         draft-ietf-pppext-padding-ds-00.txt
  85.         Discussion of interoperability experience
  86.  
  87. No one supports this.
  88.  
  89. PPP LCP Extensions
  90.         draft-ietf-pppext-lcpext-ds-02.txt
  91.         Discussion of interoperability experience
  92.  
  93. Cisco, IBM, and SCO support ID's. IBM and SCO support time remaining.
  94. Should ID's be shipped on as default?
  95.  
  96.  
  97. L2TP Remaining Issues
  98. It was pointed out that implementers are coding to draft -04 for the
  99. September 14th interoperability testing. Yet there are so many significant
  100. changes to draft -04 that it doesn't seem worthwhile to do interoperability
  101. testing until we produce draft 5. It was suggested that we strive to
  102. complete draft -05 immediately so that implementers could code it in time
  103. for the September 14 interoperability testing.
  104.  
  105. L2TP draft -05 issues:
  106. UDP port number: In the first packet, the source port can be anything,
  107. including 1701. The destination port must be 1701. In the next packet (the
  108. first reply packet), the destination port must match the first packet's
  109. source port, but the source port can be anything.  In all following
  110. packets, the same two port numbers must be used. This works just like
  111. existing UDP protocols such as TFTP.
  112.  
  113. Consensus was that we won't change anything from draft -04 regarding security.
  114.  
  115. Consensus was that tunnel ID MUST be present in every packet.
  116.  
  117. Double secret authentication stays the same as draft -04.
  118.  
  119. Bill Palter will become the Cisco representative as draft editor with help
  120. from Mark Townsley of IBM. They will collect all the recommended changes to
  121. draft -04 and produce draft -05 of L2TP ASAP.
  122.  
  123.  
  124. PPPEXT WG Day Two
  125. Tuesday, August 12, 1997
  126. Chair: Karl Fox <karl@ascend.com>
  127. Reported by: Matt Holdrege <matt@ascend.com>
  128.  
  129. Scott Petrak <petrak@vocaltec.com> spoke briefly about V.8ia in ITU SG16.
  130. The "ia" stands for "internet access". Under V.8ia, a few extra bytes can
  131. be sent before the modems begin to train. It may  be possible to send some
  132. PPP messages before the modem finishes training., thus reducing the initial
  133. connect time.
  134.  
  135.  
  136. PPP over AAL5
  137.     draft-ietf-pppext-aal5-01.txt
  138.     George Gross <gmg@garage.lucent.com>
  139.  
  140. PPP over FUNI
  141.     draft-ietf-pppext-funi-01.txt
  142.     George Gross <gmg@garage.lucent.com>
  143.  
  144. Since April, the draft was split into two. LLC encapsulated PPP MAY now be
  145. used by bilateral agreement to permit RFC 1973 interworking. VC multiplexed
  146. PPP is mandatory. Other changes include tests for SVC's, expanded
  147. references, reworking section 7 for clarity, new text stating defaults for
  148. LCP options as in RFC 1662 Appendix A, and numerous other editorial changes.
  149.  
  150. The authors want to be in alignment with the ADSL forum and vice versa.
  151.  
  152. A comment was made requesting that certain LCP options like MRU would take
  153. precedence over any Q.931 signaling. Also it should be specified that PPP
  154. would be the only protocol that used the VC.
  155.  
  156. The document will be revised and posted to the list. Consensus was that the
  157. drafts will remain as two documents.
  158.  
  159. Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI
  160.     draft-ietf-pppext-aal5-01.txt
  161.  
  162. No work has been done on this draft. It was not discussed.
  163.  
  164. Secure PPP using Fortezza
  165. James Zmuda <jzmuda@spyrus.com>
  166. William Nace <wanace@missi.ncsc.mil>
  167. draft-ietf-pppext-eapdss-00.txt
  168. draft-ietf-pppext-eapkea-00.txt
  169. draft-ietf-pppext-feep-00.txt
  170. draft-ietf-pppext-crtxchg-00.txt
  171.  
  172. 4 protocol extensions:
  173. - DSS Authentication (EAP/DSS)
  174. - KEA Authentication (EAP/KEA)
  175. - Skipjack encryption encapsulation
  176. - Certificate exchange
  177.  
  178. It was noted that KEA algorithm is currently classified by the U.S.
  179. Department of Defense. It is hoped that it will be released into the public
  180. domain soon and not patented. Until that time, this draft cannot be
  181. advanced to anything other than Informational. The current intention of
  182. this draft is to get official PPP numbers assigned to prevent clashing of
  183. ID's on real networks.
  184.  
  185. Three new EAP type values:
  186. - DSS uses value 10
  187. - KEA uses value 11
  188. - KEA-Validate uses value 12
  189.  
  190. 1 new ECP type:
  191. - Skipjack uses value 2
  192.  
  193. 1 new protocol number:
  194. - CRTXCHG needs a number
  195.  
  196. More L2TP Issues
  197. Diffs between draft -04 and draft -05 were discussed. The biggest change is
  198. the restructuring of the state machine.
  199.  
  200. It is intended that a draft -06 will immediately follow the
  201. interoperability testing in September. The testing is expected to aid
  202. "tightening up" of the draft. Any comments on the new state machine should
  203. be posted IMMEDIATELY to the L2TP list.
  204.  
  205.  
  206. Matt Holdrege  -  http://www.ascend.com  -  matt@ascend.com
  207. From - Wed Sep 10 08:45:50 1997
  208. Received: from ietf.org by ietf.org id aa27071; 13 Aug 97 2:34 EDT
  209. Received: from drawbridge.ascend.com by ietf.org id aa27067; 13 Aug 97 2:34 EDT
  210. Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) 
  211.     by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP 
  212.     id XAA05891 for <minutes@ietf.org>; Tue, 12 Aug 1997 23:29:57 -0700
  213. Received: from ascend.com by ascend.com with ESMTP
  214.     id XAA25158 for <minutes@ietf.org>; Tue, 12 Aug 1997 23:29:56 -0700
  215. Received: from ascend.com by ascend.com
  216.     id XAA26051; Tue, 12 Aug 1997 23:28:00 -0700
  217. Message-Id: <3.0.3.32.19970812232800.00ba3eb4@darla>
  218. X-Sender: mhold@darla
  219. X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
  220. Date: Tue, 12 Aug 1997 23:28:00 -0700
  221. To: minutes@ietf.org
  222. Sender:minutes-request@ietf.org
  223. From: Matt Holdrege <matt@ascend.com>
  224. Subject: PPPEXT WG minutes (Munich)
  225. Mime-Version: 1.0
  226. Content-Type: text/plain; charset="us-ascii"
  227. Status:   
  228. X-Mozilla-Status: 8001
  229.  
  230. IETF PPPEXT WG 
  231. August 11, 1997 - Day One
  232. Chair - Karl Fox    karl@ascend.com
  233. Reported by - Matt Holdrege        matt@ascend.com
  234. 89 attendees.
  235.  
  236. IP Header Compression over PPP
  237.         draft-engan-ip-compress-00.txt
  238.         Stephen Casner <casner@precept.com> 
  239.  
  240. Proposed changes to IPCP and IPv6CP
  241. Allow multiple instances of IP-Compression-Protocol option
  242. Need nine PPP packet types assigned. Five can be 16-bit. Avoids problem of
  243. negotiating inconsistent settings between Ipv4 & Ipv6.
  244.  
  245. Option Format
  246. FULL_HEADER (uncompressed)    16-bit
  247. COMPRESSED_NON_TCP        8-bit
  248. COMPRESSED_TCP            8-bit
  249. COMPRESSED_TCP_NODELTA    16-bit
  250. COMPRESSED_UDP            8 & 16
  251. COMPRESSED RTP            8 & 16
  252. CONTEXT_STATE            16-bit
  253.  
  254. Option Flags
  255.  [R] RTP_COMPRESSION
  256. [N] NON_TCP_COMPRESSION
  257. [T] TCP_COMPRESSION
  258. [S] COMP_SLOT_ID
  259. [V] VJ_COMPRESSION 
  260. The Expect Reordering flag was struck since order is a PPP requirement.
  261.  
  262. Craig Fox noted that since we are running out of 8-bit protocol ID's, we
  263. should allow even numbers. Implementations should negotiate the ability to
  264. handle even numbered ID's. Karl Fox noted that we have currently used 75%
  265. of the 8 bit numbers. This needs to be discussed on the list.
  266.  
  267. Steve will submit a new draft with 1) IPCP option exclusive with VJ
  268. compression, and 2) eliminating as many of the option flag bits as possible
  269. for use with PPP.  Karl will support Steve sending an announcement to the
  270. list for assigning the 9 needed ID's.  If no one complains, it will be
  271. approved.
  272.  
  273.  
  274. L2TP Security Extensions for Non-IPSEC networks
  275.         draft-ietf-pppext-l2tp-sec-01.txt
  276.         Pat Calhoun
  277.  
  278. Benefits:
  279. Increased security
  280. Reduces L2TP Denial of Service attack
  281. - injection of stop-ctl-req
  282. - L2TP "syn" attack (really a sccrq attack)
  283. - Injection of set-link-info
  284.  
  285. IV support increases randomness
  286. Supports replay protection
  287. Lightweight but good algorithm. (HMAC-MD5-96)
  288.  
  289. Costs:
  290. Larger header sizes
  291. Additional processing
  292. No encryption
  293.  
  294. Issues:
  295. Should TID & CID be random? Not if you are hashing on your TID
  296. Encryption should be end-to-end
  297.  
  298. Motivation:
  299. A single authentication scheme which is not a link layer specific
  300. It is still not clear that IPsec will scale in an L2TP network
  301.  
  302. It was noted that this draft needs a way to negotiate a way to handle this
  303. scheme on the control messages but not the data.
  304.  
  305.  
  306. PPP LCP CallBack
  307.         draft-ietf-pppext-callback-ds-01.txt
  308.         Discussion of interoperability experience
  309.  
  310. Only Cisco seems to supports it.
  311.  
  312. PPP LCP Self Describing Padding
  313.         draft-ietf-pppext-padding-ds-00.txt
  314.         Discussion of interoperability experience
  315.  
  316. No one supports this.
  317.  
  318. PPP LCP Extensions
  319.         draft-ietf-pppext-lcpext-ds-02.txt
  320.         Discussion of interoperability experience
  321.  
  322. Cisco, IBM, and SCO support ID's. IBM and SCO support time remaining.
  323. Should ID's be shipped on as default?
  324.  
  325.  
  326. L2TP Remaining Issues
  327. It was pointed out that implementers are coding to draft -04 for the
  328. September 14th interoperability testing. Yet there are so many significant
  329. changes to draft -04 that it doesn't seem worthwhile to do interoperability
  330. testing until we produce draft 5. It was suggested that we strive to
  331. complete draft -05 immediately so that implementers could code it in time
  332. for the September 14 interoperability testing.
  333.  
  334. L2TP draft -05 issues:
  335. UDP port number: In the first packet, the source port can be anything,
  336. including 1701. The destination port must be 1701. In the next packet (the
  337. first reply packet), the destination port must match the first packet's
  338. source port, but the source port can be anything.  In all following
  339. packets, the same two port numbers must be used. This works just like
  340. existing UDP protocols such as TFTP.
  341.  
  342. Consensus was that we won't change anything from draft -04 regarding security.
  343.  
  344. Consensus was that tunnel ID MUST be present in every packet.
  345.  
  346. Double secret authentication stays the same as draft -04.
  347.  
  348. Bill Palter will become the Cisco representative as draft editor with help
  349. from Mark Townsley of IBM. They will collect all the recommended changes to
  350. draft -04 and produce draft -05 of L2TP ASAP.
  351.  
  352.  
  353. PPPEXT WG Day Two
  354. Tuesday, August 12, 1997
  355. Chair: Karl Fox <karl@ascend.com>
  356. Reported by: Matt Holdrege <matt@ascend.com>
  357.  
  358. Scott Petrak <petrak@vocaltec.com> spoke briefly about V.8ia in ITU SG16.
  359. The "ia" stands for "internet access". Under V.8ia, a few extra bytes can
  360. be sent before the modems begin to train. It may  be possible to send some
  361. PPP messages before the modem finishes training., thus reducing the initial
  362. connect time.
  363.  
  364.  
  365. PPP over AAL5
  366.     draft-ietf-pppext-aal5-01.txt
  367.     George Gross <gmg@garage.lucent.com>
  368.  
  369. PPP over FUNI
  370.     draft-ietf-pppext-funi-01.txt
  371.     George Gross <gmg@garage.lucent.com>
  372.  
  373. Since April, the draft was split into two. LLC encapsulated PPP MAY now be
  374. used by bilateral agreement to permit RFC 1973 interworking. VC multiplexed
  375. PPP is mandatory. Other changes include tests for SVC's, expanded
  376. references, reworking section 7 for clarity, new text stating defaults for
  377. LCP options as in RFC 1662 Appendix A, and numerous other editorial changes.
  378.  
  379. The authors want to be in alignment with the ADSL forum and vice versa.
  380.  
  381. A comment was made requesting that certain LCP options like MRU would take
  382. precedence over any Q.931 signaling. Also it should be specified that PPP
  383. would be the only protocol that used the VC.
  384.  
  385. The document will be revised and posted to the list. Consensus was that the
  386. drafts will remain as two documents.
  387.  
  388. Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI
  389.     draft-ietf-pppext-aal5-01.txt
  390.  
  391. No work has been done on this draft. It was not discussed.
  392.  
  393. Secure PPP using Fortezza
  394. James Zmuda <jzmuda@spyrus.com>
  395. William Nace <wanace@missi.ncsc.mil>
  396. draft-ietf-pppext-eapdss-00.txt
  397. draft-ietf-pppext-eapkea-00.txt
  398. draft-ietf-pppext-feep-00.txt
  399. draft-ietf-pppext-crtxchg-00.txt
  400.  
  401. 4 protocol extensions:
  402. - DSS Authentication (EAP/DSS)
  403. - KEA Authentication (EAP/KEA)
  404. - Skipjack encryption encapsulation
  405. - Certificate exchange
  406.  
  407. It was noted that KEA algorithm is currently classified by the U.S.
  408. Department of Defense. It is hoped that it will be released into the public
  409. domain soon and not patented. Until that time, this draft cannot be
  410. advanced to anything other than Informational. The current intention of
  411. this draft is to get official PPP numbers assigned to prevent clashing of
  412. ID's on real networks.
  413.  
  414. Three new EAP type values:
  415. - DSS uses value 10
  416. - KEA uses value 11
  417. - KEA-Validate uses value 12
  418.  
  419. 1 new ECP type:
  420. - Skipjack uses value 2
  421.  
  422. 1 new protocol number:
  423. - CRTXCHG needs a number
  424.  
  425. More L2TP Issues
  426. Diffs between draft -04 and draft -05 were discussed. The biggest change is
  427. the restructuring of the state machine.
  428.  
  429. It is intended that a draft -06 will immediately follow the
  430. interoperability testing in September. The testing is expected to aid
  431. "tightening up" of the draft. Any comments on the new state machine should
  432. be posted IMMEDIATELY to the L2TP list.
  433.  
  434.  
  435. Matt Holdrege  -  http://www.ascend.com  -  matt@ascend.com
  436.