Danvers PPP Minutes

[Fred Baker <[e-mail]>]

The working group met to discuss several issues.

Gerry Meyer:
    Encryption Control Protocol
    draft-ietf-pppext-encryption-03.txt

    The ECP document was returned to the working group by the IESG for
    the following changes:
        - Clarification of some text
        - Provide a means in addition to the use of IEEE 802 OUIs for
          vendor-specific encryption technologies (through IANA)
        - 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.

Steve Coya: ECP/CCP Patent Status Report
    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 VP Technology of
    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.

Keith Sklower: Multilink Procedures RFC 1717

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

    We discussed the use of Endpoint Identifiers. Some implementors
    chose to assume that any multilink implementation would implement
    EIDs, and didn't 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.
    We 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 doesn't
    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.

    We chose to forbid asymmetric bundling of links.

Larry Blunk: Extensible Authentication Protocol
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.

Badari Narayana:
    Public Key Authentication Proposal
    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.

Glenn McGregor and Gurdeep Singh Pall
    IP Control Protocol
    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 doesn't 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 didn't 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.

Respectfully submitted,
Fred Baker
Chair

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
computers run on smoke, it if leaks out they won't run