CURRENT_MEETING_REPORT_
Reported by Fred Baker/cisco Systems
Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT)
Encryption Control Protocol -- Gerry Meyer
draft-ietf-pppext-encryption-03.txt
The ECP document was returned to the working group by the IESG for the
following changes:
o Clarify some text.
o Provide a means in addition to the use of IEEE 802 OUIs for
vendor-specific encryption technologies (through IANA).
o Specify a encryption technology that most vendors will supply.
Keith Sklower will write a draft describing DES Cipher Block Chaining
Encryption. Default: ECP implementations should implement DES Cipher
Block Chaining Encryption. If encryption requested and not successfully
negotiated, the implementation should take down the connection as in the
authentication specification.
ECP/CCP Patent Status Report -- Steve Coya
draft-ietf-pppext-encryption-03.txt
draft-ietf-pppext-compression-04.txt with related procedure definition
drafts
The IESG has received a letter of intent from the Vice President of
Technology at Motorola Codex to provide ``fair, reasonable, and
non-discriminatory'' licensing of its patent claims. There is
considerable sense in the working group that specific prior art can be
cited for the technology in question, but the procedures specified in
RFC 1602 require the IETF to wait for that letter before publishing the
documents, quite apart from the validity of the claims.
Multilink Procedures RFC 1717 -- Keith Sklower
The group considered the result of an interoperability test of the
Multilink Procedure.
Clarification appears to be required concerning the meaning of
``Protocol ID Compression.'' Implementors please note that when one
system indicates a willingness to receive PID compressed messages, there
is no obligation imposed on the sender to send them. The fact that the
CCP presumes the negotiation of PID compressed messages in the payload
therefore does not imply that the first octet of the message cannot be
zero: an IP datagram might start with 0x21 or with 0x00-21.
The group discussed the use of Endpoint Identifiers. Some implementors
chose to assume that any multilink implementation would implement EIDs,
and did not operate correctly without them; others made the same
assumption about Authentication. Major interoperation problems occurred
between the two implementation types. Some means of identifying that
two lines should or should not be in the same bundled is required, but
either mechanism is a reasonable choice. It was decided to add a usage
note identifying the dilemma, and indicating that EIDs should always be
ACKed on a configure request even if the other system does not use them,
much as synchronous implementations ACK ACCM. Also, a new EID type will
be generated which is only used in NAKs when requesting that the other
end identify itself; this is the only valid value in a NAK (request for
EID of peer). Implementations should note that a valid response to such
a request is the NULL EID.
Implementations also had problems when they assumed that one system was
always the authenticator and the other the authenticated system.
Implementors please note: either system or both may choose to
authenticate the other.
A problem arose in managing the number of connections open between two
systems; systems often each took down a line simultaneously, and then
simultaneously tried to bring up a line when they detected the total
loss of connectivity.
Generally, it should be the responsibility of the guy who brings up a
link to take it down. Note, however, that there are cases when the
called party validly takes the call down, or the call fails.
An advisable procedure is that when there is more than one link open and
a system takes one down, it should hold it down for a random period of
time.
Scott Wasson and Keith Sklower took action items to collaborate in
developing a call management protocol. This may either be an NCP (8xxx)
or a control protocol (Cxxx). The purpose of this protocol is to:
Negotiate maximum number of channels open Negotiate bringing up new
channel or taking one down. When negotiating, Multilink implementations
must negotiate MRRU, and may negotiate SSNHF.
Keith changed default MRU to 1500, for consistency with other
procedures. Note that negotiating MRU = MRRU + Multilink Header Size is
advisable for any protocols that one really does not want fragmented.
The packet loss procedure is too restrictive; Keith will improve the
description and add examples. Implementations should discard message
fragments that can be determined to be up to or including portion of
frame lost.
The group chose to forbid asymmetric bundling of links.
Extensible Authentication Protocol -- Larry Blunk
ftp://merit.edu/pub/ppp/eap-draft.txt
Larry made a general presentation of his Extensible Authentication
Protocol. There was some discussion of this, but mostly for clarity of
understanding.
It was decided that the MD5 Challenge procedure would be a default
algorithm, as the password is not sent in the clear, and implementation
code is unencumbered and not very onerous.
It was also decided that an RSA and an ISO 9798-3 extension should be
written; Todd Palgut agreed to write them.
There was widely-held feeling that one did not need versions with a
password, clear text to be echoed, and clear text to not be echoed.
Echoing is a local display option, to be left to the user interface.
The recommendation was to reduce this to one of the above, and use that
for both simple password and one time password procedures.
Implementations should note, however, that simple password procedures
are insecure and very much not recommended.
Public Key Authentication Proposal -- Badari Narayana
ftp://ftp.cisco.com/fred/draft-ietf-pppext-public-key-00.txt
Fred Baker presented the draft in the absence of Badari Narayana.
Novell here is developing an RSA Public Key approach; unfortunately, the
draft does not point this out, and does not identify the control
protocol used to achieve this. For this reason, an interoperable
authentication procedure cannot be implemented. Further, concern was
expressed by members of the security community that had read the draft
that it did not in fact describe a public key approach, but rather a
shared secret approach that perhaps uses RSA software to scramble its
messages.
The consensus is that the draft is either poorly worded or fundamentally
incorrect; in either case, it requires a great deal of work to be
useful.
IP Control Protocol -- Glenn McGregor and Gurdeep Singh Pall
draft-ietf-pppext-ipcp-00.txt
Fred Baker presented this draft in the absence of its authors.
This draft has as its fundamental objective taking the IPCP from
Proposed Standard status to Draft Standard. IPCP was originally written
as RFC 1172 in 1990, and cycled at Proposed Standard when updated (1992)
as RFC 1332. With upwards of 20 mature, interoperable implementations,
it seems that the protocol should be able to become something we
consider stable and ready for widespread implementation.
The effects of this update are:
The Type 1 IP Address option (defined in RFC 1772 and deprecated in
1332) was removed.
The Type 2 IP-Compression-Protocol option (which is capable of selecting
the use of Van Jacobson header compression) remains unchanged.
The Standard and Van Jacobson header compression data messages remain
unchanged.
The Type 3 IP-Address Option (Type 3) has been used in practice in
describing unnumbered links, and there was an attempt to normalize the
procedures having to do with this. The normalization contains two
errors, which the authors are to correct in an updated draft.
When the IPCP announces an address (``I am using address a.b.c.d as my
source address on this link''), there are four possible responses
defined in the draft:
Ack: ``OK, you are that address''
Nak with address: ``No, use this one''
Nak with 0.0.0.0: ``I consider this an unnumbered link''
Reject: ``huh?''
Nak with 0.0.0.0 is not a useful response. If the system is considering
the link an unnumbered interface, then it does not care what address the
peer uses. It should treat the announcement as interesting but
superfluous information, and Acknowledge it.
When the IPCP requests an address assignment (announcement of the
invalid address 0.0.0.0), the draft defines two possible responses:
Ack with 0.0.0.0: ``I consider this an unnumbered link''
Nak with address: ``use this one''
There is an additional possible response:
Reject: ``I am not prepared to assign an address''
Ack with 0.0.0.0 is not a useful response; it signals to the other end
acceptance of the address it has chosen, which is an address the
RFC 1716 and the current Router Requirements draft preclude in the
section describing ``Martian Filters.'' If the requester has asked for
an address assignment, it is very probably because he needs one. The
better response would be to reject the option, leaving the requester
with the decision to either terminate IPCP (done when operation in the
absence of an address is impossible or not implemented - for example, in
an end system) or to treat the interface as an unnumbered interface and
use its Router ID. In the latter case, the system rejecting the option
may be presumed to not care.
An additional case should be noted: if the receiver of an IPCP
Configure Request needs to know the address of its peer and the address
is not announced, it should Nak with the address 0.0.0.0. The next
Configure Request can be expected to either not have the Type 3
IP-Address option (the peer did not implement it) or to contain an
announcement of a valid address. In the latter case, it should be
Acknowledged.
The draft defines a new option, Type 4, the IP-Broadcast-Forwarding
Option. This is designed to provide a configuration negotiation for
legacy applications (such as NETBIOS/IP) which use the directed
broadcast rather than IP Multicast. Some of them, notably NETBIOS, can
be very noisy, and it would be nice to be able to dynamically reduce the
server or router's configuration from sending those to not forwarding
them when no application using them is active.
The option should not, in the collective opinion of the working group,
be expected to increase what the peer will forward; if a system requests
forwarding of subnet-directed broadcasts and network-directed
broadcasts, and the peer is only prepared to forward subnet-directed
broadcasts (which would probably be consistent with RFC 1716's
discussion of the forwarding algorithm), one would expect the peer to
Nak the option indicating the subset of the request it is prepared to
honor.
The option specifies a Bit Mask indicating the broadcast types requested
or approved. A request for several types of broadcasts is indicated by
the sum of their flag values:
00 No Broadcast forwarding (default)
01 IP Broadcast forwarding
02 IP Network Broadcast forwarding
04 IP Sub-Network Broadcast forwarding
The consensus was that, since the IETF Process Definition RFC indicates
that advancing a document to Draft Standard requires several
interoperable implementations of each part, the presence of this option
is inconsistent with the objective of advancement to Draft Standard.
The authors are therefore directed to create a separate IPCP Extensions
draft containing this option, permitting the remainder of the IPCP to
advance.
