2.3.16 Point-to-Point Protocol Extensions (pppext)

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:

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 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

· 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

PPP LCP Self Describing Padding

PPP LCP Extensions

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.

Slides

None Received

Attendees List

go to list

Previous PageNext Page