IETF PPPEXT WG 
August 11, 1997 - Day One
Chair - Karl Fox	karl@ascend.com
Reported by - Matt Holdrege		matt@ascend.com
89 attendees.

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


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


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.

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

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

4 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

1 new ECP type:
- Skipjack uses value 2

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


Matt Holdrege  -  http://www.ascend.com  -  matt@ascend.com
From - Wed Sep 10 08:45:50 1997
Received: from ietf.org by ietf.org id aa27071; 13 Aug 97 2:34 EDT
Received: from drawbridge.ascend.com by ietf.org id aa27067; 13 Aug 97 2:34 EDT
Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) 
	by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP 
	id XAA05891 for <minutes@ietf.org>; Tue, 12 Aug 1997 23:29:57 -0700
Received: from ascend.com by ascend.com with ESMTP
	id XAA25158 for <minutes@ietf.org>; Tue, 12 Aug 1997 23:29:56 -0700
Received: from ascend.com by ascend.com
	id XAA26051; Tue, 12 Aug 1997 23:28:00 -0700
Message-Id: <3.0.3.32.19970812232800.00ba3eb4@darla>
X-Sender: mhold@darla
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 12 Aug 1997 23:28:00 -0700
To: minutes@ietf.org
Sender:minutes-request@ietf.org
From: Matt Holdrege <matt@ascend.com>
Subject: PPPEXT WG minutes (Munich)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status:   
X-Mozilla-Status: 8001

IETF PPPEXT WG 
August 11, 1997 - Day One
Chair - Karl Fox	karl@ascend.com
Reported by - Matt Holdrege		matt@ascend.com
89 attendees.

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


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


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.

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

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

4 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

1 new ECP type:
- Skipjack uses value 2

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


Matt Holdrege  -  http://www.ascend.com  -  matt@ascend.com