CURRENT_MEETING_REPORT_ Reported by Fred Baker/ACC Minutes of the Open Shortest Path First IGP Working Group (OSPF) Fred Baker chaired the meeting in John Moy's absence. The slides presented in this meeting are located at ftp.acc.com:/pub/fbaker/*.ps. Each set is in a separate file. Authentication Scheme Christian Huitema points out that OSPF authentication is not compliant with the security model and subject to numerous attacks. The best form of security would be to secure the databases---the neighbor list and the link state database---with verifiable signatures. This is a major change to the protocol message format if nothing else, and is not suggested at this time. However, an improvement in basic authentication that would go a long way to assure the router that a message received from a neighbor is in fact from that neighbor would be a big improvement. His proposal, as discussed and agreed to in the working group meeting, is: In addition to ``no'' and ``password'' authentication, enable the use of an MD5-keyed authentication service. MD5 is defined in Rivest, R., ``The MD5 Message-Digest Algorithm,'' RFC 1321, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. The following MIB changes are generally required. An Internet-Draft of the algorithm and message format will be jointly written by Fred Baker and Christian Huitema and submitted to the working group. The following MIB changes are generally required: the MIB object ospfAuthType requires a new enumeration: md5 (2), and a ``secret'' MIB object must be defined. The existing objects ospfIfAuthKey and ospfVirtIfAuthKey will be used for the latter purpose, with a length of sixteen octets. Note that these are effectively write-only objects, and should only be written using secure SNMP or another secure facility. Scaling Testing performed at COS Paul Serice presented the testing performed at COS on 28 February - 4 March 1994. Point-to-MultiPoint Interface Fred Baker presented his proposal for dealing with OSPF on Frame Relay using point-to-multipoint links. This is an architectural change to the point-to-point interface model, in which the system with the interface may have more than one neighbor. Thomas Pusateri has implemented something very much like this in his OSPF implementation, and reports that it works correctly. The improvement of this approach over the NBMA or unnumbered point to point interface approaches suggested in RFC 1586 ``Guidelines for Running OSPF Over Frame Relay Networks'' is that it improves manageability and reduces the size and/or number of LSAs generated by a router which is implementing a large partial mesh network; it also circumvents an operational problem when a failure occurs within a Frame Relay network. Given the overview, the consensus was that the matter should be discussed on the list. However, the working group approved adding an enumeration to the MIB object ospfIfType describing pointToMultiPoint, for use when the approach is approved. OSPF MIB Given the addition of two enumerations of existing objects as noted in these minutes, the OSPF MIB is approved to advance to Draft Standard Status. IP Forwarding MIB/CIDR The IP Forwarding MIB (RFC 1354) has been updated to reflect CIDR. There was a discussion about the use of forwarding policy, and it was determined that forwarding policies addressed in this MIB should be limited to TOS values. Two other tables were discussed which had been proposed and discussed on the mailing list, dealing with the way one chooses which route to select when multiple routing protocols, or instances of a routing protocol, derive different routes to the same endpoint with the same TOS, and which routes one chooses to ``leak.'' The conclusion was that both of these require significantly more policy than the tables proposed, so the tables should not be included in the public standard. Attendees Fred Baker fbaker@acc.com Jeffrey Honig jch@nr-tech.cit.cornell.edu Sandra Murphy murphy@tis.com Julie Myers jmyers@network.com Jason Perreault jason@synoptics.com Benny Rodrig brodrig@rnd-gate.rad.co.il William Salkewicz bsalkewi@wellfleet.com