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.