2.3.10 Point-to-Point Protocol Extensions (pppext)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98

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

RFC1763

PS

The PPP Banyan Vines Control Protocol (BVCP)

RFC1764

PS

The PPP XNS IDP Control Protocol (XNSCP)

RFC1968

PS

The PPP Encryption Control Protocol (ECP)

RFC1969

 

The PPP DES Encryption Protocol (DESE)

RFC1973

PS

PPP in Frame Relay

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

RFC2290

PS

Mobile-IPv4 Configuration Option for PPP IPCP

RFC2284

PS

PPP Extensible Authentication Protocol (EAP)

RFC2363

PS

PPP Over FUNI

RFC2364

PS

PPP over AAL5

Current Meeting Report

PPPEXT WG
Chicago, IL
Chair: Karl Fox <karl@ascend.com>
Reported by: Matt Holdrege <matt@ascend.com>

Day One, August 25th 1998

Anita Freeman (afreema@cisco.com) spoke on the next interoperability workshop
covering IPSEC, IKE, L2TP and L2TP with IPSEC. It's in Binghamton,cNew York on
October 27-30 and announcements have been sent to the list.

Mark Townsley (townsley@cisco.com) and Bill Palter (palter@network-alchemy.com)
gave an L2TP update. L2TP is not yet at Proposed Standard. The IESG is reviewing the
standard and there will be a draft -12. The IESG is concerned with security and reserved
numbers for IANA.

IANA needs new section listing what numbers IANA should be concerned about 20

An IETF approved document must exist for the numbers to be assigned by IANA.

For security, the floating IP address is an issue. The IESG says that the security threats
outweigh the potential benefits. Text stating that an implementation MUST always
respond to the source IP address will be removed.

It was noted that if you use IPSEC, the problem with changing IP addresses is no longer
a concern.

It was asked whether IPSEC should be mandatory for L2TP, but the WG did not agree
to do that.

In congruence with no floating IP address, the UDP port will also remain fixed after
tunnel establishment.

In keeping with the TFTP model, the following exchanged is still permissible (x and y
can be any port number, including 1701):

=E0 SCCRQ (src=3Dx,dest=3D1701)
=DF SCCRP (src=3Dy, dest=3Dx)
=E0SCCCN (src=3Dx,dest=3Dy)

The IESG is worried about NAT and firewalls with this arrangement. There was some
discussion and it was resolved that we would take it to the list.

Paolo Crivellari <pcri@sebb.bel.alcatel.be>=20
draft-alcatel-pppext-l2tp-atmext-00.txt

This is a draft for L2TP access over ATM over media such as XDSL. The LAC performs
bridging of a PPP session between AAL5 and L2TP transport. A generic packet based
network would connect the LAC and LNS.

They need to add two extra bits to identify non-HDLC access network types. The other
bit is to identify Broadband bearer capabilities. This is under the framing type AVP and
the bearer type AVP

Also a minimum bit per second upstream AVP and a maximum bit per second upstream
AVP are needed. An ATM cause code AVP is needed to determine failure conditions.
And the dial number AVP should be binary encoded. A Maximum Receive Unit AVP
is also added.

Bill Simpson <wsimpson@greendragon.com> covered the following drafts

draft-ietf-pppext-lcpext-ds-03.txt
draft-ietf-pppext-callback-ds-02.txt
draft-ietf-pppext-padding-ds-01.txt
draft-ietf-pppext-conversion-01.txt
draft-ietf-pppext-framerelay-ds-01.txt
draft-ietf-pppext-x25-ds-01.txt
draft-ietf-pppext-ether-00.txt

Bill said the first six of these drafts had expired and he wanted the IESG to put them
forward. The LCP extensions draft had some comments from the IESG which Bill
added to a new draft.

SDP has zero implementations because it slows negotiation and because hardware
doesn't appear to exist anymore that requires it. Bill said that other protocols refer to
SDP. But he thinks it should be put out as proposed standard so people can use it in
the future.

PPP Framing conversion is waiting for the chair to forward the draft.

PPP in Frame Relay has multiple implementations. The chair and AD's will check up
on the status.

PPP in X.25 hasn't been implemented much. Bill asked if anyone cared about this
protocol. Someone said yes it is useful. Thomas Narten said to either advance it or
make it historic. It is also referenced in the AO/DI protocol.

PPP in Ether-like framing is new. The motivation behind this draft is to provide
something simpler than HDLC for high-speed networks. Everything is on 32-bit
boundaries to make it easier to implement in hardware. Bill wants this to go to
proposed standard.

Karl asked if this should go to ANSI since it seems to be about framing over Sonet.
Lucent noted that hardware framers at OC-48 exist today.
Rollins Turner rturner@eng.paradyne.com
L2TP over ATM
Draft-ietf-pppext-l2tp-atm-00.txt

Based on RFC 1483. How to use ATM for the link between LAC and LNS. The draft
suggests supporting large MTU's such as 9180 and the authors are looking for
suggestions. QoS is an implementation decision. Two encapsulation methods, LLC and
VC Mux. Method negotiated on SVC setup and pre-configured for PVC's.

SVC signaling is based on RFC 2364. A BLLI IE specified by originators the desired
encapulation. For detecting and recovering from unsolicited L2TP encaps transitions,
LLC encapsulated frames always begin with a fixed 8 byte sequence. Upon change in
encaps, tear down tunnel or if SVC terminate connection.=20

It was noted that this draft shouldn't reference a byte position but should follow the
L2TP spec.

It was asked what would happen if an intermediate ATM switch uses EPD or PPD. The
author didn't see how this is different from L2TP over IP, but he would look into it.

It was noted that RFC 1483 has been updated and it should be examined.

Day 2
August, 26th 1998

Evan Caves <evan@acc.com>
L2TP MIB
Draft-ietf-pppext-l2tp-mib-02.txt

The changes from -01 include:

- Added tunnel domain group (optional)
- Removed redundant objects
- More consistent object names
- L2TP notifications
- Removed UDP configuration table
- Updated MIB relationships section

Still to be done:

- Update L2TP UDP stats table
- Add shared secret to tunnel (and domain?) config tables
- Finalize indexing session table

This will be taken back to the list and updated over the next few weeks and then move
to WG last call.

Glen Zorn <glennz@microsoft.com>
LCP Internationalization Config Option
draft-ietf-pppext-charset-02.txt
New LCP option has character set and language specification. It uses an enumerated
value of updated country codes, but allows a string value for new languages.

Glen Zorn <glennz@microsoft.com>
MS-CHAP v2

This is the first public discussion of MS-CHAP v2 and it will result in a forthcoming draft.

Features:
- Mutual authentication
- Asymmetric keying
- Defeat of pre-computed dictionary attacks.
- New algorithm number of 0x81 from IANA
- 16 octet challenges
- Peer challenge in response

Authenticator authenticator in the success packet which is 40 hex digits in ASCII. It's
ASCII so it could be printable in an error message.

New password change protocol. It has a peer challenge in password change request.
Auth Auth in success packet.

The MPPE key derivation method is different. It's based on an NT password hash with
master send/receive keys. Keys are changed on every packet.

There should be a new Radius attribute to differentiate between MS-CHAP v1 and v2.

Bill Simpson <wsimpson@greendragon.com>
PPP over Sonet

This adds ATM style payload scrambling and a draft ITU-T PPP indicator value of
0x16. 0x17 is reserved in the draft for ppp in etherlike framing which is another draft.
For OC-48 and above, the default framing is etherlike. Below OC-48 can use octet
stuffing and scrambling.

The group debated whether to specify etherlike framing or HDLC for OC-48+. Most
people in the room who had direct interest preferred HDLC. At least a couple of people
wanted the option of using an alternative like etherlike framing if it becomes standardized.

It was noted that this draft should coordinate with MPLS over PPP/Sonet to specify the
location of the shim.

Several questions and comments related to Sonet/SDH were made and commentators
were urged to take their comments and questions to the main PPP list.

Bill's goal is to resolve the Sonet and SDH interoperability issues. Others said that all
we should do is document our issues with Sonet/SDH interoperability and that it is up
to other forums to resolve the interoperability issues.

Slides

None received.

Attendees List

go to list