PPPEXT WG Dec. 7th, 1998 Meeting Chair Matt Holdrege - matt@ascend.com Reported by Don Grosser - grosser@us.ibm.com L2TP draft status - Mark Townsley ================================= -Poll: about 50% of attendees monitor the L2TP mailing list -Poll: most of those who monitor the L2TP mailing list saw the email from the IESG (Thomas Narten) -Mark pointed out that the authors have been working hard to advance L2TP. Mark read the following statement: The Layer 2 Tunneling Protocol, which began 2 years ago as the merging of the L2F and PPTP specifications, is currently in its 12th state of Internet Draft revision. In March of this year, the Working Group requested that the 10th revision of L2TP be promoted to RFC Proposed Standard. To date, the Working Group is aware of over 20 independently developed, interoperable L2TP implementations. In reaction to substantial customer demand, several vendors have announced general availability of L2TP in their products and have begun the initial stages of widespread deployment. One could say with clear conscience that L2TP has been in a ôde factoö Proposed Standard phase for many months. The high level of endorsement for L2TP by the industry places additional weight on every decision to alter the specification as well as increased demands for an expeditious advancement through the IETF process. In fact, as time has marched forth, the L2TP specification has become less of a static proposal to base new implementations off of, and more of a report on the details of implementations have already been developed. The Editors consider the L2TP draft as the ôsource codeö for which developers have created many L2TP implementations. As with any product which has been in widespread use in the field, every change made is applied with great scrutiny as each invariably run the risk of causing unintentional side affects. In our case, the side affects are the possible introduction of contradictions or ambiguities that may hinder interoperability of future L2TP implementations using the L2TP specification. This state of affairs has created a setting that to the IESG has seemed rigid and closed minded. In fact, this behavior has been a simple effort to balance protection of both the installed base of implementations and hard-earned consensus that the Working Group had already achieved, together with the necessary changes required in order to move the official status of the document forward in a swift manner. It seems, however, that this hard-lined conservative approach has hindered the IETF process more than it helped. Over the past 9 months, the Area Directors and IESG have made a total of 57 specific suggestions for alteration of the L2TP specification. With so many other items on its plate, the IESG must truly be commended for such a thorough review. These items have ranged from simple typos, to operational changes in protocol itself. 23 of the 57 items presented were incorporated into draft 11 and 12. The rest were resisted by the Editors on grounds that they were general misunderstandings, were not backward compatible with the multitude of existing implementations and did not provide enough benefit to outweigh the costs, or would require additional implementation experience in the field to properly address. The latter is something we argue could be taken care of during the Proposed Standard phase. At the IESGÆs request, we recently re-evaluated the suggestions that were originally rejected or missed. Of these, 8 were still considered unnecessary and 8 were accepted with the necessary changes to the text applied. The final 18 items were each affiliated in one way or another with the optional flow control feature of L2TP. The Editors have been unable to reconcile each of these issues in a manner that we believe would not require additional review by the Working Group and another round of consensus attained. Therefore, it is the recommendation of the Editors that the portion of the L2TP specification that handles the optional Flow Control mechanism be isolated and moved to its own Internet Draft, leaving the base specification for approval by the IESG without this hindrance. The purpose of this action is NOT to alter the L2TP protocol itself. The express intent is to enhance the clarity and readability of the L2TP specification, properly address all of the concerns of the IESG, and still allow for a swift promotion of the base specification to Proposed Standard. To this end, no new functionality to the new L2TP specification will be permitted during this phase, beyond any necessary items for the clean separation of the Flow Control capability. Of primary concern is that the new draft be backwards compatible to the previous specification, and thus to the many existing L2TP implementations that have already been deployed. Any proposed changes solely for increased clarity and readability will be graciously accepted and evaluated for inclusion into the new specification. However, please remember that when trying to improve the overall clarity of a document, removing words is often more effective than adding them. This ôLess is Moreö principal will certainly apply here. -It is the recommendation of the authors to remove L2TP flow control from the base specification in order to advance the L2TP draft. They propose a new draft to describe L2TP flow control. -It was noted that the new flow control draft should be backwards compatible with existing implementations. -Focus will be on advancing the L2TP base spec *then* the flow control draft. -Mark is targeting Dec. 17 to present base L2TP to the IESG. -Mark requested a document review group to be held later in the week at the IETF to review the changes. -It was noted that the base L2TP spec should always set the R-bit for the benefit of existing implementations which "stick" after dropping a packet. L2TP Link Extensions (Bill Palter/Mark Townsley) ================================================ -Need a way to communicate negotiated LCP options from LNS to LAC. -Need a way for the LAC to provide the LNS with LCP options suggestions/limitations. -LAC to LNS: -LCP want options AVP (format is similar to existing proxy LCP AVPs). A table is provided in the draft giving LCP option meaning in the context of this new AVP. -LCP allow options AVP (format is similar to existing proxy LCP AVPs). A table is provided in the draft giving per LCP option meaning in the context of this new AVP. -It was noted that some LCP options (like auth. protocol) should not be included in the new AVP because the LAC shouldn't have any input as to which auth. protocol the LNS uses. -LNS to LAC: -Bill described a method to communicate LNS negotiated LCP options to the LAC. -The L2TP SLI message can include the LCP-Conf-Req and last- received-LCP-Config-Req AVPs. L2TP MIB - Evan Caves ===================== -Changes from draft -02: -Sessions are no longer logical sub-interfaces represented in the ifTable. -The session table is indexed by tunnel ifIndex and Local CallID. -Mapping tables have been added by request. -A tunnel shared secret object has been added to the Domain and tunnel config tables. -The address and port change counters have been removed in response to the L2TP draft removing these features. -The addressing change notification has been removed. -It was noted that the L2TP MIB draft may need to be separated into an L2TP base MIB and an L2TP flow control MIB draft in light of the proposed L2TP draft split. Framework for L2TP Message Extensions - Richard Shea ==================================================== -This draft describes a generic approach to signal support for an L2TP protocol extension. For example: -new message types -new AVPs -existing AVPs in new messages -A bitmask would be used to indicate support for various extensions - one bit per extension. -It was noted that there should be a way to "reserve" bits. -This approach also serves to minimize new AVPs which signal support for an L2TP protocol extension. L2TP Dynamic Data Window Adjustment - Richard Shea ================================================== -After session establishment the LNS can modify its receive window based on which network control protocols were negotiated. -The LAC can also change its window after receiving window adjustment from LNS Mobile PPP - Mooi Choo Chuah/Don Grosser ======================================== -Goal is to provide uninterrupted VPN service to vanilla mobile nodes without having to renegotiate the PPP link during handovers. -no client software changes -minimize handover messaging/delay on expensive wireless WAN -Clients can have allocated IP addresses from a pool rather than using fixed IP addresses since IPCP will not be renegotiated. -This draft leverages L2TP. -3 models: -Simple AVP Approach - The new "serving LAC" starts a L2TP call (and possibly a tunnel) to the existing LNS. During call setup a new AVP (User AVP) identifies a PPP session on the LNS which is being replaced. The original LAC-LNS call is subsequently dropped. -Independent Tunnel Approach - The end-to-end PPP session is carried over a 2 separate L2TP tunnels. -Concatenated Tunnel Approach - This method expands the L2TP session into a 2-hop L2TP session with end-to-end flow control. -There were comments and concerns regarding its applicability and relationship to other work. L2TP over ATM - Yves ==================== -Removed from the draft: -"raw" PPP framing over L2TP -MRU indication from LAC to LNS -Modified: -extension for assymmetric bw -indication of bearer capabilities/type -indication of framing capabilities/type -ATM cause code -Rx minimum bps (OCRQ) -Rx Maximum bps (OCRQ) -NSAP based dialed number if b bit -A request will be made to the PPPEXT chair to make this draft part of the PPPEXT. PPTP - Glenn Zorn ================= -Someone asked what the delta was for the latest draft. -Glenn noted that the main differences were: -The security considerations section is much larger. -References to Karn's algorithm were removed. -Various format changes were made. -Appendices were moved to the the draft body. MPPE - Glenn Zorn ================= -It was noted that the naming of the associated "key" documents is confusing. Day Two: Session chair: Matt Holdrege Reported by: Andy Malis Mark Townsley announced that there is going to be an L2TP editing session immediately following this meeting. Shahrukh Merchant (Cimaron) presented his PPP over SONET from STS-1 to STS-192 draft (draft-merchant-pppext-sonet-sdh-00.txt). Purpose: ¸ Document existing practice on previous technology (STS-3c, STS-12c) ¸ Document what appears to be consensus and/or current practice on current technology (STS-48c) ¸ Proposed extension for future technology (STS-192c and above). For STS1, STS-3c, and STS-12c, use HDLC per RFC 1662 and revised ANSI T1.105.02 or Revised G.707 for SONET mapping: C2 = 0x16, x^43 + 1 payload scrambling, FCS-16 is the default and FCS-32 is optional. For STS-48c, the same as above, except that FCS-32 is the default (FCS-16 is not a defined option). For STS-192C, he proposed moving from a byte-oriented HDLC to HDLC-32, a 32-bit oriented HDLC that uses 32-bit alignment in the SONET payload for easier implementation at 10 Gbps speeds. The HDLC-32 payload scrambling (X^29 + 1) prevents potential malicious bandwidth expansion. It supports FCS-32 only. His motivation for HDLC-32 is that byte-wise HDLC is extremely complex and hard to implement at STS-192c and faster speeds. The flag sequences are: Flag0=E7 81 CA 34 Flag1=E7 81 CA 35 Flag2=E7 81 CA 36 Flag3=E7 81 CA 37 The escape sequence is Esc32=EB 8D C6 38 HDLC-32 uses four-octet flags as frame delimiters and as fill when idle. There are four defined 32-bit flag sequences and one escape sequence. The abort sequence is Esc32 + Flag0. Additions he will made to the next version of the draft: ¸ No FCS is not an option for STS/1/3C/12c ¸ FCS-16 is not an option for STS-48c. ¸ ACCM is not used (although an HDLC decode would always decode it properly anyway). Next steps: ¸ Incorporate comments, discussion, and suggestions ¸ Fill in Appendix A, B, and C (clarifying bit ordering of scrambling and CRC calculations) ¸ Fill in Appendix D (PPP over DS3) and expand to include DS1-DS3 and E1-E3 Chuck Benz from Nexabit suggested an intra-packet idle for under run situations for HDLC-32. Shahrukh does not believe that Cimaron intends to patent HDLC-32. He will confirm that. Andy Hebb said that it looks like you could send (worst case) up to an additional 6 bytes of overhead per frame (3 extra bytes of flag and at worst padding to a four-octet boundary) compared to byte-wide HDLC. Shahrukh added that the average was actually 4.5 bytes extra; however, this would be reduced relative to byte-wide HDLC by the fact that the presence of Escape sequences would be a negligible factor (vs. about 1% for byte-wide HDLC with random data) since the probability of needing escapes in the data goes down exponentially with word size, and packets are scrambled before HDLC-32 insertion, so scrambling will also prevent malicious insertion. Matt Holdrege wrote a draft on Always On/Dynamic ISDN (draft-ietf-ppext-aodi-00.txt), and he asked for comments for the intent of moving it on the standards track. There are multiple interoperable implementations. Anita Freeman announced two upcoming interoperability workshops on L2TP/IPsec, MS-Chapv2, MPPE and perhaps other protocols. Details will be sent to the pppext and ipsec email lists.