Editor's note:  These minutes have not been edited.

Date: Thu, 20 Jul 1995 08:47:18 -0700
From: Fred Baker <fred@cisco.com>

Minutes of PPPEXT WG 33 IETF

Reported by Fred Baker, Chair

1) Frank Kastenholtz: Motorola Patent Claim

Motorola has not met the requirements of RFC 1602; they have not given the
IESG a blanket license for the use of their patent claims. Within the
context of RFC 1602, the working group has two choices: continue to hope
that the situation will change, or change the CCP and ECP drafts so that
they do not infringe on the patent claims.

The consensus of the working group is to remove references to the HISTORY
RESET REQUEST and HISTORY RESET RESPONSE from the CCP and the ECP, and
indicate that CCP SHOULD run over reliable PPP (LAPB). Removing all
reference to resetting the history buffer is believed to obviate any claim
Motorola has regarding these drafts.

Action:
        Dave Rand to modify the CCP draft accordingly

        Authors of compression algorithm drafts to update drafts if
        necessary.

        Gerry Meyer to modify the ECP draft accordingly.

2) Keith Sklower: DES Electronic Codebook Encryption Algorithm

Keith described his draft; the consensus was that the draft was acceptable
and standardization of ECP should continue based on it. DESE is an
informational draft supporting ECP.

Keith indicates that the key is "derived" from the authentication/EID
information; it is "derived" in the sense that one of some number of
perviously configured keys is selected on the basis of that information.
Consensus: change the word to "selected". If there are no other more
substantive changes required (and at this point there does not appear to
be) this can be handled by the RFC editor.

Dave Carrel suggested that we need a way to specify and perhaps execute a
key exchange algorithm in ECP; we discussed an option of the general form:

        +-------+-------+-------+-------
        | Type  | Length| Code  | 0 or more bytes of data
        +-------+-------+-------+-------

        Code = 1     use hard coded keys, perhaps selected via
                     authentication/EID information (default)

        Code = 2     key exchange algorithm involving the data

If there are several possible key exchange algorithms, they should be
enumerated. This detail to be clarified in list discussion.

The draft explicitly does NOT define a key exchange algorithm, and we don't
particularly want to get into defining the key exchange; the objective is
to enable a key exchange defined by the IP Security Group to be used.

There is some belief that the EBC Mode is inadequate, that Cypher Block
Feedback should be used or at least defined. This will be discussed on the
list.

Action:
        Dave to discuss key exchange on the list; if favorable consensus
        is formed, Gerry to update draft appropriately

        Upon closure of this item,
                Updated ECP draft ==> Proposed Standard,
                DESE              ==> Informational

3) Keith Sklower: PPP Multilink Revision

Keith reported that the california Multilink/ISDN interoperability testing
prior to the Danvers indicated the desireability of a call-back control
protocol to mitigate line-flapping when different systems have different
criteria of when a second B-channel is needed.  (Keith had volunteered to
participate in such work, but not do it unilaterally).  No progress has
been made. Vern Schryver, in a private communication, suggested to Keith
that Ascend be contacted to see if they would be willing to disclose their
protocol to be used (even if only as a basis for discussion).

Consensus was not to hold up RFC1717bis for inclusion of any such
protocol.

Revisions that the current draft embodies:

        Clarify: must use MMRU or MMRU+SSNHF: cannot use SSNHF alone to
        negotiate M/L

        Sequence numbers start from zero

        No default for MMRU; implementations MUST support MMRU=1500

        No NAK of EID

        Must use same SNHF on all links to same peer; other links may use
        same or different SNHF.

Revisions needed:

        OK to stop using M/L headers if only one link up in certain cases

        When second link passes LCP and Authentication, must use M/L
        headers and assign next fragment number to new link.

        Draft specifies one anonymous bundle to be used in the case of no
        authentication and no EID provided.  RK Hariram comented on the
        list that this would fail in the case of one system connected to
        two others.  The consensus already had been to allow (multiple)
        manually configured bundles, but the draft didn't actually say this.
        The draft should be change to make this clear.

4) Kevin Pierce's MP ISDN modes comment

Kevin sent a longish note to the list asking for clarification of certain
operating modes in PPP M/L. Some of the modes are problematic, and there
seems to be no reason to include the discussion in the draft itself.

Action:
        Keith and Kevin to correspond and settle issues.

5) Dave Carrel: EAP Draft

An EAP draft was posted too late to discuss at the IETF, and the relevant
people were for the most part not present. Discuss on the list.

Action:
        Take to the list