NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Karl Fox <karl@ascend.com>
Internet Area Director(s):
Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>
Internet Area Advisor:
Jeffrey Burgan <burgan@home.net>
Mailing Lists:
General Discussion: ietf-ppp@merit.edu
To Subscribe: ietf-ppp-request@merit.edu
Archive: ftp://merit.edu/pub/ietf-ppp-archive
Description of Working Group:
The Point-to-Point Protocol (PPP) was designed to encapsulate multiple protocols. IP was the only network layer protocol defined in the original documents. The working group is defining the use of other network layer protocols and options for PPP. The group will define the use of protocols including: bridging, ISO, DECNET (Phase IV and V), XNS, and others. In addition, it will define new PPP options for the existing protocol definitions, such as stronger authentication and encryption methods.
No Goals and Milestones
Internet-Drafts:
· PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol
· The PPP Internet Protocol Control Protocol (IPCP)
· PPP Extensible Authentication Protocol (EAP)
· PPP EAP RSA Public Key Authentication Protocol
· PPP LCP Extensions
· Point-to-Point Tunneling Protocol--PPTP
· Layer Two Tunneling Protocol 'L2TP'
· Mobile-IPv4 Configuration Option for PPP IPCP
· Semi Connected Mode for PPP links
· Proposal for a PPP Network Layer Entity Selection Protocol
· PPP over AAL5
· Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI
· PPP LCP CallBack
· Layer Two Tunneling Protocol "L2TP" Security Extensions for Non-IPSEC networks
· The PPP DES Encryption Protocol, Version 2 (DESE-bis)
· The PPP Triple-DES Encryption Protocol (3DESE)
· PPP Over FUNI
· PPP LCP Self Describing Padding
Request For Comments:
RFC |
Status |
Title |
RFC1332 |
PS |
The PPP Internet Protocol Control Protocol (IPCP) |
RFC1378 |
PS |
The PPP AppleTalk Control Protocol (ATCP) |
RFC1377 |
PS |
The PPP OSI Network Layer Control Protocol (OSINLCP) |
RFC1473 |
PS |
The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol |
RFC1472 |
PS |
The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol |
RFC1471 |
PS |
The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol |
RFC1474 |
PS |
The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol |
RFC1553 |
PS |
Compressing IPX Headers Over WAN Media (CIPX) |
RFC1552 |
PS |
The PPP Internetwork Packet Exchange Control Protocol (IPXCP) |
RFC1547 |
Requirements for an Internet Standard Point-to-Point Protocol | |
RFC1570 |
PS |
PPP LCP Extensions |
RFC1598 |
PS |
PPP in X.25 |
RFC1618 |
PS |
PPP over ISDN |
RFC1619 |
PS |
PPP over SONET/SDH |
RFC1638 |
PS |
PPP Bridging Control Protocol (BCP) |
RFC1663 |
PS |
PPP Reliable Transmission |
RFC1662 |
S |
PPP in HDLC-like Framing |
RFC1762 |
DS |
The PPP DECnet Phase IV Control Protocol (DNCP) |
RFC1764 |
PS |
The PPP XNS IDP Control Protocol (XNSCP) |
RFC1763 |
PS |
The PPP Banyan Vines Control Protocol (BVCP) |
RFC1968 |
PS |
The PPP Encryption Control Protocol (ECP) |
RFC1973 |
PS |
PPP in Frame Relay |
RFC1969 |
The PPP DES Encryption Protocol (DESE) | |
RFC1977 |
PPP BSD Compression Protocol | |
RFC1975 |
PPP Magnalink Variable Resource Compression | |
RFC1979 |
PPP Deflate Protocol | |
RFC1967 |
PPP LZS-DCP Compression Protocol (LZS-DCP) | |
RFC1974 |
PPP Stac LZS Compression Protocol | |
RFC1976 |
PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) | |
RFC1963 |
PPP Serial Data Transport Protocol (SDTP) | |
RFC1990 |
DS |
The PPP Multilink Protocol (MP) |
RFC1989 |
DS |
PPP Link Quality Monitoring |
RFC1978 |
PPP Predictor Compression Protocol | |
RFC1993 |
PPP Gandalf FZA Compression Protocol | |
RFC1994 |
DS |
PPP Challenge Handshake Authentication Protocol (CHAP) |
RFC2043 |
PS |
The PPP SNA Control Protocol (SNACP) |
RFC2097 |
PS |
The PPP NetBIOS Frames Control Protocol (NBFCP) |
RFC2118 |
Microsoft Point-To-Point Compression (MPPC) Protocol | |
RFC2125 |
PS |
The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) |
RFC2153 |
PPP Vendor Extensions |
Minutes of the PPPEXT WG Minutes
Chair - Karl Fox <karl@ascend.com>
Reported by - Matt Holdrege <matt@ascend.com>
I. IP Header Compression over PPP, draft-engan-ip-compress-00.txt,
Stephen Casner <casner@precept.com>
Proposed changes to IPCP and IPv6CP:
Allow multiple instances of IP-Compression-Protocol option Need nine PPP packet types assigned. Five can be 16-bit. Avoids problem of negotiating inconsistent settings between Ipv4 and Ipv6.
Option Format:
FULL_HEADER (uncompressed) 16-bit
COMPRESSED_NON_TCP 8-bit
COMPRESSED_TCP 8-bit
COMPRESSED_TCP_NODELTA 16-bit
COMPRESSED_UDP 8 & 16
COMPRESSED RTP 8 & 16
CONTEXT_STATE 16-bit
Option Flags:
[R] RTP_COMPRESSION
[N] NON_TCP_COMPRESSION
[T] TCP_COMPRESSION
[S] COMP_SLOT_ID
[V] VJ_COMPRESSION
The Expect Reordering flag was struck since order is a PPP requirement.
Craig Fox noted that since we are running out of 8-bit protocol ID's, we should allow even numbers. Implementations should negotiate the ability to handle even numbered ID's. Karl Fox noted that we have currently used 75% of the 8-bit numbers. This needs to be discussed on the list.
Steve will submit a new draft with 1) IPCP option exclusive with VJ compression, and 2) eliminating as many of the option flag bits as possible for use with PPP. Karl will support Steve sending an announcement to the list for assigning the 9 needed ID's. If no one complains, it will be approved.
II. L2TP Security Extensions for Non-IPSEC networks, draft-ietf-pppext-l2tp-sec-01.txt, Pat Calhoun
Benefits:
· Increased security
· Reduces L2TP Denial of Service Attack
- Injection of stop-ctl-req
- L2TP "syn" attack (really a sccrq attack)
- Injection of set-link-info
· IV support increases randomness
· Supports replay protection
· Lightweight but good algorithm. (HMAC-MD5-96)
Costs:
· Larger header sizes
· Additional processing
· No encryption
Issues:
· Should TID & CID be random? Not if you are hashing on your TID Encryption should be end-to-end
Motivation:
· A single authentication scheme that is not a link layer specific. It is still not clear that IPsec will scale in an L2TP network
It was noted that this draft needs a way to negotiate a way to handle this scheme on the control messages but not the data.
PPP LCP CallBack
draft-ietf-pppext-callback-ds-01.txt
Discussion of interoperability experience
Only Cisco seems to supports it.
PPP LCP Self Describing Padding
draft-ietf-pppext-padding-ds-00.txt
Discussion of interoperability experience
No one supports this.
PPP LCP Extensions
draft-ietf-pppext-lcpext-ds-02.txt
Discussion of interoperability experience
Cisco, IBM, and SCO support ID's. IBM and SCO support time remaining. Should ID's be shipped on as default?
III. L2TP Remaining Issues
It was pointed out that implementers are coding to draft -04 for the September 14th interoperability testing. Yet there are so many significant changes to draft -04 that it doesn't seem worthwhile to do interoperability testing until we produce draft 5. It was suggested that we strive to complete draft -05 immediately so that implementers could code it in time for the September 14 interoperability testing.
IV. IL2TP draft -05 issues
UDP port number: In the first packet, the source port can be anything, including 1701. The destination port must be 1701. In the next packet (the first reply packet), the destination port must match the first packet's source port, but the source port can be anything. In all following packets, the same two port numbers must be used. This works just like existing UDP protocols such as TFTP.
Consensus was that we won't change anything from draft -04 regarding security. Consensus was that tunnel ID MUST be present in every packet. Double secret authentication stays the same as draft -04.
Bill Palter will become the Cisco representative as draft editor with help from Mark Townsley of IBM. They will collect all the recommended changes to draft -04 and produce draft -05 of L2TP ASAP.
PPPEXT WG Day Two, Tuesday, August 12, 1997
Chair: Karl Fox <karl@ascend.com>
Reported by: Matt Holdrege <matt@ascend.com>
Scott Petrak <petrak@vocaltec.com> spoke briefly about V.8ia in ITU SG16. The "ia" stands for "internet access". Under V.8ia, a few extra bytes can be sent before the modems begin to train. It may be possible to send some PPP messages before the modem finishes training., thus reducing the initial connect time.
PPP over AAL5
draft-ietf-pppext-aal5-01.txt
George Gross <gmg@garage.lucent.com>
PPP over FUNI
draft-ietf-pppext-funi-01.txt
George Gross <gmg@garage.lucent.com>
Since April, the draft was split into two. LLC encapsulated PPP MAY now be used by bilateral agreement to permit RFC 1973 interworking. VC multiplexed PPP is mandatory. Other changes include tests for SVC's, expanded references, reworking section 7 for clarity, new text stating defaults for LCP options as in RFC 1662 Appendix A, and numerous other editorial changes.
The authors want to be in alignment with the ADSL forum and vice versa.
A comment was made requesting that certain LCP options like MRU would take precedence over any Q.931 signaling. Also it should be specified that PPP would be the only protocol that used the VC.
The document will be revised and posted to the list. Consensus was that the drafts will remain as two documents.
I. Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI, draft-ietf-pppext-aal5-01.txt
No work has been done on this draft. It was not discussed.
Secure PPP using Fortezza
James Zmuda <jzmuda@spyrus.com>
William Nace <wanace@missi.ncsc.mil>
draft-ietf-pppext-eapdss-00.txt
draft-ietf-pppext-eapkea-00.txt
draft-ietf-pppext-feep-00.txt
draft-ietf-pppext-crtxchg-00.txt
Four Protocol Extensions:
· DSS Authentication (EAP/DSS)
· KEA Authentication (EAP/KEA)
· Skipjack encryption encapsulation
· Certificate exchange
It was noted that KEA algorithm is currently classified by the U.S. Department of Defense. It is hoped that it will be released into the public domain soon and not patented. Until that time, this draft cannot be advanced to anything other than Informational. The current intention of this draft is to get official PPP numbers assigned to prevent clashing of ID's on real networks.
Three new EAP type values:
· DSS uses value 10
· KEA uses value 11
· KEA-Validate uses value 12
One new ECP type:
- Skipjack uses value 2
One new protocol number:
- CRTXCHG needs a number
More L2TP Issues:
Diffs between draft -04 and draft -05 were discussed. The biggest change is the restructuring of the state machine. It is intended that a draft -06 will immediately follow the interoperability testing in September. The testing is expected to aid "tightening up" of the draft. Any comments on the new state machine should be posted IMMEDIATELY to the L2TP list.
None Received