INTERNET ENGINEERING STEERING GROUP (IESG) March 12, 1998 Reported by: Steve Coya, IETF Executive Director ATTENDEES --------- Baker, Fred / cisco Bradner, Scott / Harvard Burgan, Jeff / @home Carpenter, Brian / IBM (IAB Liaison) Coya, Steve / CNRI Curran, John / GTE Internetworking Elz, Robert / U of Melbourne (IAB Liaison) Halpern, Joel / Newbridge Networks Moore, Keith / U of Tennessee Narten, Thomas / IBM Reynolds, Joyce / ISI Romanow, Allyn / MCI Schiller, Jeff / MIT Sittin' In ---------- Rob Coltun / Fore Systems Marcus Leech / Nortel April Marine / Sterling Software Vern Paxson / Lawrence Berkeley Laboratory Regrets ------- Alvestrand, Harald / Maxware O'Dell, Mike / UUNET Minutes ------- 1. The minutes of the February 26, 1998 Teleconference were approved. Steve to place in public archives. 2. The IESG tentatively publication of Protection of BGP Sessions via the TCP MD5 Signature Option as a Proposed Standard (when announced). The new version is to include the following with the addition of the following: 1. Add a Section titled "Key Configuration" to the document. The text of the section is: It should be noted that the key configuration mechanism of routers may restrict the possible keys that may be used between peers. Implementors should consider this issue in their design. 2. Change the text of Security Consideratins to read: This document defines a weak but currently practiced security mechanism for BGP. It is anticipated that future work will provide different stronger mechanisms for dealing with these issues. 3. Insert the following IESG Note: IESG Note: This document describes currrent existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks. The author will submit a revised I-D with this text. Once announced, and both Keith and Harald state their concerns have been addressed, Steve to send announcement. 3. The IESG tentatively approved publication of Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 as a Proposed Standard, but an RFC note needs to be added: In Section 3.1.5, replace the first two paragraphs with the following: An entry in the ipoaVcTable is created after the InATMARP reply is successfully received for an ipoaConfigPvcEntry during its activation. InATMARP should return the IP Address of the other end of the PVC in order to have the needed indexes to create an ipNetToMediaEntry and an ipoaVcEntry. The corresponding ARP Cache entry SHOULD be deleted whenever a PVC becomes unusable. 4. The IESG approved publication of OSPF Version 2 as a Standard. In the same action, the IESG approved publication of OSPF Standardization Report as an Informational RFC. Steve to send announcement 5. The IESG tentatively approved publication of Virtual Router Redundancy Protocol as a Proposed Standard, once the following is incorporated into the Protocol Action Announcement: section 5.3.6.2, add text at end saying: Note that there are security implications to using the choice for authentication, and one should see the Security Considerations section. In Security Considerations, 10.2, add: The user should be aware that this clear text password is sent frequently, and therefore should not be the same as any security significant password. Add an IESG Note pointing to the IPR Page. 6. The IESG approved publication of IP Payload Compression Protocol (IPComp) as a Proposed Standard, but Steve is NOT to send a Protocol Action Announcement until the following two documents are approved: draft-ietf-ipsec-ipsec-doi-06.txt draft-ietf-ipsec-isakmp-08.txt 7. The IESG approved publication of IP Version 6 over PPP as a Proposed Standard, but Steve is NOT to send a Protocol Action Announcement until the following are approved: draft-ietf-ipngwg-ipv6-spec-v2-01.txt draft-ietf-ipngwg-addrconf-v2-02.txt draft-ietf-ipngwg-addr-arch-v2-02.txt draft-narten-canonical-ordering-00.txt 8. The IESG tentatively approved publication of IMAP4 Namespace as a Proposed Standard, but only if the author clarifies what "MAY NOT" means (assumed to be MUST NOT). Keith to contact author and provide information to IESG. Steve will request RFC Editor to make change prior to publication. 9. The IESG approved publication of the following Internet-Drafts as Proposed Standards: NBMA Next Hop Resolution Protocol (NHRP) NHRP Protocol Applicability Statement A Distributed NHRP Service Using SCSP Server Cache Synchronization Protocol (SCSP) as well as the publication of Classical IP to NHRP Transition as an Informational RFC. However, the following text needed to be added: The Security Considerations text in draft-ietf-ion-nhrp-appl-02.txt hould be replaced with the following: NHRP is an address resolution protocol, and SCSP is a database synchronization protocol. As such, they are possibly subject to server (for NHRP) or peer (for SCSP) spoofing and denial of service attacks. They both provide authentication mechanisms to allow their use in environments in which spoofing is a concern. Details can be found in sections 5.3.4 in [1] and B.3.1 in [8]. There are no additional security constraints or concerns raised in this document that are not already discussed in the referenced sections. The title of draft-ietf-ion-transition-02.txt be changed to: Classical IP and ARP over ATM to NHRP Transition Section C of draft-ietf-ion-scsp-05.txt be replaced with: Any and all requests for value assignment from the various number spaces described in this document require proper documentation. Possible forms of documentation include, but are not limited to, RFCs or the product of another cooperative standards body (e.g., the MPOA and LANE subworking group of the ATM Forum). Other requests may also be accepted, under the advice of a "designated expert" (Contact the IANA for the contact information of the current expert.) And add a note that the IANA designated expert as mentioned in Section C of draft-ietf-ion-scsp-05.txt is James V. Luciani . 10. The IESG approved creation of the IP Over the Vertical Blanking Interval (ipvbi) Working Group in the Internet Area of the IETF. Steve to send announcement. 12. The IESG approved publication of Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM as an Experimental Protocol. Steve to send announcement. 13. The IESG approved publication of The Safe Response Header Field as an Informational RFC with the following change: Note to RFC Editor: the text in the 4th paragraph of section 3 currently reads: they must be assumed unsafe by default. This document adds a mechanism to HTTP, the Save header field, for telling if a POST request is safe. the text should read they must be assumed unsafe by default. This document adds a mechanism to HTTP, the Safe header field, for telling if a POST request is safe (i.e. change Save to Safe). 14. The IESG approved publication of IP Payload Compression Using DEFLATE as an Informational RFC, but Steve NOT to send announcement until draft-ietf-ippcp-protocol-xx is approved. 15. The IESG approved publication of IP Payload Compression Using LZS as an Informational RFC, but Steve NOT to send announcement until the following are approved: draft-ietf-ippcp-protocol draft-ietf-ipsec-auth-header draft-ietf-ipsec-ipsec-doi-06 16. The IESG approved publication of Framework for IP Performance Metrics as an Informational RFC. 17. The IESG had no problem with the publication of Recommendations on Queue Management and Congestion Avoidance in the Internet as an Informational RFC. Steve to inform RFC Editor. 18. The IESG had no problem with the publication of WAVE and AVI Codec Registries as an Informational RFC. Steve to inform RFC Editor. 19. The IESG felt that The IP Network Address Translator (NAT) should be remanded to the NAT Working Group. Steve to inform RFC Editor. 20. The IESG could find no reason to publish Domain names for part-time Internet hosts , though a number of reasons NOT to publish were identified. Steve will so inform the RFC Editor. 21. The IESG could find no reason to publish The Ted.Net protocol for messaging based business interchanges . Steve to inform the RFC Editor. 22. The IESG had no problem with the publication of The text/css Media Type as an Informational RFC. Steve to inform RFC Editor. 23. The IESG feels that publication of Layer Two Forwarding (Protocol) "L2F" draft-valencia-12f-00.txt would serve no real purpose, other than for history majors. IF the RFC Editor wishes to publish, the IESG recommends it be published as Historic, not as Informational (as submitted). Furthermore, the IESG will request that CISCO be the first word of the Title. This is the last Teleconference before the 41st IETF Meeting in LA.