home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
pppext
/
pppext-minutes-95jul.txt
< prev
next >
Wrap
Text File
|
1995-10-18
|
5KB
|
147 lines
CURRENT_MEETING_REPORT_
Reported by Fred Baker/cisco Systems
Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT)
Agenda
o Intellectual Property Rights -- Frank Kastenholtz
o Implications for Compression -- Fred Baker
o Encryption/DES -- Gerry Meyer and Keith Sklower
o Multilink Procedure -- Keith Sklower
o Authentication Protocols -- Dave Carrels
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.
Actions: Dave Rand to modify the CCP draft accordingly. The authors of
the compression algorithm drafts to update drafts if necessary. Gerry
Meyer to modify the ECP draft accordingly.
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 was to 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 do
not particularly want to get into defining the key exchange; the
objective is to enable a key exchange defined by the IPSEC Working 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.
Actions: 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 to Proposed Standard and DESE to
Informational RFC.
Keith Sklower: PPP Multilink Revision
Keith reported that the California Multilink/ISDN interoperability
testing prior to the Danvers meeting indicated the desirability 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 RFC 1717bis for inclusion of any such
protocol.
Revisions that the current draft embodies:
o Clarify: must use MMRU or MMRU+SSNHF: cannot use SSNHF alone to
negotiate M/L
o Sequence numbers start from zero
o No default for MMRU; implementations MUST support MMRU=1500
o No NAK of EID
o Must use same SNHF on all links to same peer; other links may use
same or different SNHF
Revisions needed:
o OK to stop using M/L headers if only one link up in certain cases.
o When second link passes LCP and Authentication, must use M/L
headers and assign next fragment number to new link.
o Draft specifies one anonymous bundle to be used in the case of no
authentication and no EID provided. RK Hariram commented 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 did not actually say
this. The draft should be changed to make this clear.
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.
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.
Action: This will be taken to the list.