The IESG has approved the following document: - 'ASON Routing for OSPFv2 Protocols' (draft-ietf-ccamp-rfc5787bis-06.txt) as Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ Technical Summary The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. Working Group Summary This document received much attention and discussion in its early revisions. The document has been stable for quite some time, mainly needing revisions as part of the publication process for Standards Track. Document Quality There have been no public statements related to implementations, though significant interest was expressed when the working group was polled for interest in moving to standards track. Part of the motivation for the work is interest from the OIF which suggests that prototype implementations will be built. This document suffered^H^H^H^H benefited from an extensive AD review as the publication request was processed. There were a number of comments during IETF last call and as the result of a Routing Directorate review: these have been addressed. Personnel Deborah Brungard (db3546@att.com) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD RFC Editor Note Section 6.1, page 9, final paragraph: OLD: Identifier SHOULD NOT be set to 0. NEW: Identifier MUST NOT be set to 0. --- Section 9, pages 14-15, second and third paragraphs: OLD: Any mechanisms used for securing the exchange of normal OSPF LSAs can be applied equally to all TE LSAs used in the ASON context. Authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic authentication [RFC2328] and [RFC5709]) can be used to secure against passive attacks and provide significant protection against active attacks. [RFC5709] defines a mechanism for authenticating OSPFv2 packets by making use of the HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. If a stronger authentication were believed to be required, then the use of a full digital signature [RFC2154] would be an approach that should be seriously considered. Use of full digital signatures would enable precise authentication of the OSPF router originating each OSPF link-state advertisement, and thereby provide much stronger integrity protection for the OSPF routing domain. RCs implementing export/import of ASON routing information between RAs MUST also include policy control of both the maximum amount of information advertised between RAs and the maximum rate at which it is advertised. This is to isolate the consequences of an RC being compromised to the RAs to which that subverted RC is attached. NEW: Any mechanisms used for securing the exchange of normal OSPF LSAs can be applied equally to all TE LSAs used in the ASON context. Authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic authentication [RFC2328] and [RFC5709]) can be used to provide significant protection against active attacks. [RFC5709] defines a mechanism for authenticating OSPFv2 packets by making use of the HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. RCs implementing export/import of ASON routing information between RAs MUST also include policy control of both the maximum amount of information advertised between RAs and the maximum rate at which it is advertised. This is to isolate the consequences of an RC being compromised to the RAs to which that subverted RC is attached. The document [OSPF-SECURITY-ANALYSIS] provides a comprehensive analysis of OSPFv2 and OSPFv3 security relative to the requirements specified in [RFC6518]. --- Section 13.2, page 24 (remove [RFC2154] and add two new Informative References): OLD: [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. NEW: [OSPF-SECURITY-ANALYSIS] Hartman, S. and Zhang, D., Analysis of OSPF Security According to KARP Design Guide, draft-ietf-karp-ospf-analysis-05.txt, July 2012, work in progress [RFC6518] Lebovitz, G., and Bhatia, M., "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012
