Skip to main content

Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols
draft-ietf-ccamp-rfc5787bis-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    ccamp mailing list <ccamp@ietf.org>,
    ccamp chair <ccamp-chairs@tools.ietf.org>
Subject: Protocol Action: 'ASON Routing for OSPFv2 Protocols' to Proposed Standard (draft-ietf-ccamp-rfc5787bis-06.txt)

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/


Ballot Text

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

RFC Editor Note