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