2.3.15 Point-to-Point Protocol Extensions (pppext)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 03-Nov-97

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:

Note: A separate list has been set up for L2TP discussions

L2TP Discussions:l2tp@zendo.com To Subscribe: l2tp-request@zendo.com Archive: http://bodhi.zendo.com/vandys/l2tp-mail

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:

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

Current Meeting Report

Minutes of the PPP Extensions (pppext) Working Group

Chair - Karl Fox - karl@Ascend.com

Reported by: Matt Holdrege - matt@ascend.com

The PPP Triple-DES Encryption Protocol (3DESE)
Draft-ietf-pppext-3des-encrypt-00.txt
Sent to IESG on Dec. 3rd. Informational RFC

PPP over AAL5
draft-ietf-pppext-aal5-03.txt
Draft Status
Last Call until Dec. 10th
Andy Malis and George Gross discussed LLC encapsulation. No resolution.

PPP over FUNI
draft-ietf-pppext-funi-03.txt
Draft Status
Last Call until Dec. 10th

PPP LCP Extensions
draft-ietf-pppext-lcpext-ds-02.txt
Draft Status
Sent to IESG

PPP LCP CallBack
draft-ietf-pppext-callback-ds-01.txt
Call for Interoperability Experience

PPP LCP Self Describing Padding
draft-ietf-pppext-padding-ds-00.txt
Call for Interoperability Experience
No one has claimed to have implemented this protocol.

Multi-link Multi-node PPP
Draft-ietf-pppext-mmp-discovery-00.txt
Gary Malkin - gmalkin@baynetworks.com
Gary discussed certain points of his draft.
Mechanism needed to randomize the bundle head. The point was brought up that different vendors handle LCP negotiation differently and remote peers may have difficulties. Security was brought up since a big denial of service hole exists. Packets need to be authenticated to prevent this. Multicast should be required for efficiency. IANA would need to issue a multicast number.

Next CIUG Interoperability Workshop - Week of February 23rd
Anita Freeman - anfreema@cisco.com
Park Plaza Motel - San Francisco
Fee of $300 per person.
EAP, CCP, BACP and L2TP will be tested.

PPP Consistent Overhead Byte Stuffing (COBS)
Draft-ietf-pppext-cobs-00.txt
James Carlson - jcarlson@andr.ub.com
Stuart Cheshire - cheshire@dsg.stanford.edu
Stuart presented his draft. There are no intellectual property restrictions (patents) for COBS.

L2TP MIB
Draft-ietf-pppext-l2tp-mib-01.txt
Pat Calhoun - pcalhoun@usr.com
Pat presented his draft.

L2TP Security Extensions for Non-IP networks
Draft-ietf-pppext-l2tp-sec-02.txt
Pat Calhoun - pcalhoun@usr.com
Many changes were to simplify the implementation.

L2TP
Draft-ietf-pppext-l2tp-08.txt
Mark Townsley - townsley@cisco.com
Congestion Control will be clarified in draft -09 which will be out before the end of 1997. The next interoperability workshop in February will be based on draft -09. Should sequence numbers be MUST or SHOULD? Mark will put text in the next draft for MUST but allow for it to be administratively disabled.

L2TP Header Compression
Draft-ietf-pppext-l2tphc-00.txt
Mark Townsley - townsley@cisco.com
Mark described the draft and answered questions.

L2TP Alternate Data Channel
Draft-ietf-pppext-l2tpadc-00.txt
Bill Palter - palter@cisco.com
Bill presented his draft.

Securing L2TP using IPSEC
Draft-ietf-pppext-l2tp-security-00.txt
Baiju Patel - baiju@ideal.jf.intel.com
Baiju presented his draft.
ISAKMP/Oakley for authentication and key management. IPSEC ESP for protection of traffic. Integrity using ESP with NULL encryption. Confidentiality using ESP with DES (or others). The objective is to provide adequate protection for L2TP control traffic. Integrity is MUST. Confidentiality is SHOULD. Provide protection for L2TP data traffic. Integrity is SHOULD. Confidentiality is MAY. For L2TP over non-IP networks, non-IP networks must transport packets. They must carry UDP packets of ISAKMP/Oakley in band or out of band (need to specify in media specific document). Carry ESP payload (no need for IP header). Next header of ESP is 0 (or we can require a new protocol type). In summary, one protocol for securing L2TP traffic over IP and non-IP networks. Proven solution. Must comply with this document to claim L2TP security requirement compliant implementation. Pat Calhoun said that Ipsec shouldn't be mandated for non-ip. Some questioned that this method is a proven solution. Bill Simpson said that null ESP may not be desirable.

RTP Compression
Carsten Borman - Steve Casner
Changes suggested in Munich have been made. Minutes said request would be approved if no objections. They have a set of numbers to propose and are seeking approval.
FULL_HEADER 0061
COMPRESSED_TCP 0063
COMPRESSED_NON_TCP 0065
COMPRESSED_UDP_8 0067
COMPRESSED_RTP_8 0069

COMPRESSED_TCP_NODELTA 8063
CONTEXT_STATE 8065
COMPRESSED_UDP_16 8067
COMPRESSED_RTP_16 8069

ISSLOW also requests LCP options, 25 Multilink Header Format (different from 18 as it has a parameter), 26 Prefix elision option

I draft-ietf-issll-isslow-02.txt (In WG last call)
PS draft-ietf-issll-isslow-mcml-02.txt (In WG last call)
PS draft-ietf-issll-isslow-rtf-02.txt (to go to WG last call after IETF)

Bill Simpson said to use the 8000 range rather than 2000. Craig Fox said that the 4000 range would be better to handle old code. 8000 range was the rough consensus.

PPP EAP TLS Authentication Protocol
draft-ietf-pppext-eaptls-02.txt
Bernard Aboba <bernarda@microsoft.com>
Bernard discussed the draft. Bill said that EAP doesn't have a good match as a key negotiation protocol. Bill is against fragmentation here. This will be taken to the list.

PPP with Framing Conversion
draft-ietf-pppext-conversion-00.txt
Bill Simpson <wsimpson@greendragon.com>
This is to cover async/sync converters. Recommended to go forward as BCP.

PPP in Frame Relay
draft-ietf-pppext-framerelay-ds-00.txt
Bill Simpson <wsimpson@greendragon.com>
Same as RFC 1973 except it adds a reference to frame conversion. Need to get a list of implementers to advance to draft standard. Cisco and Ascend were noted as the only current implementers present.

PPP in X.25
draft-ietf-pppext-x25-ds-00.txt
Bill Simpson <wsimpson@greendragon.com>
Simplification of wording in current RFC. Bill will ask on the list for implementations.

PPP for Asynchronous PAD to Synchronous X.25 access

draft-rfced-info-khana-01.txt
Bill Simpson <wsimpson@greendragon.com>
Bill said this work should fall under the domain of the ITU since it involves ITU numbers. Bill said details of PPP through PAD's should be handled as an appendix to the PPP in X.25 RFC. Bill also suggested that we submit this to the ITU Study Group 7.

PPP EAP KEA Public Key Authentication Protocol
Draft-ietf-pppext-eapkea-01.txt
Jim Zmuda - jzmuda@spyrus.com
Pat Calhoun raised a possible IBM patent issue.

PPP Certificate Exchange Protocol
Draft-ietf-pppext-crtxcgh-01.txt
Jim Zmuda - jzmuda@spyrus.com
Bernard asked why anyone would use EAP if they had this protocol.

PPP Fortezza Encryption Encapsulation Protocol
Draft-ietf-pppext-feep-01.txt
Jim Zmuda - jzmuda@spyrus.com
Fortezza is currently classified. Bill Simpson said that ISAKMP was originally designed for Fortezza and that we should use ISAKMP rather than Fortezza. Jim said he would look into it.

Slides

None Received

Attendees List

go to list

Previous PageNext Page