Internet Draft Igor Bryskin (Movaz Networks) Category: Standards Track Alex Zinin (Alcatel) Expiration Date: October 2006 Lou Berger (LabN Consulting, LLC) April 2006 Validation of OSPF AS-scope opaque LSAs draft-bryskin-ospf-lsa-type11-validation-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a mechanism enabling an OSPF node to validate AS-scope opaque LSAs (LSAs type-11, [RFC2370]) originated outside of the node's OSPF area. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Bryskin, Zinin, Berger [Page 1] Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006 1. Introduction [RFC2370] introduces a mechanism for the distribution of application specific information using the OSPF ([RFC2328]) protocol (i.e. OSPF advertising, Link State Data Base (LSDB) synchronization and flooding procedures). Link State Advertisements (LSAs) that carry such information are called opaque LSAs. According to [RFC2370] the distribution of opaque LSAs is limited to: a) only immediate neighbors of the originator (LSAs type-9); b) only OSPF nodes located within the originator's OSPF area (LSAs type-10); c) all OSPF nodes within the originator's OSPF domain/AS (LSAs type-11) One issue related to AS scoped Opaque LSAs is that there is no way for OSPF nodes in remote areas to check availability of the LSA originator. Specifically, if an OSPF node originates an LSA type-11 and, after that, goes out of service, OSFP nodes located outside of the originator's OSPF area have no way of detecting this fact and may use the stale information for a considerable period of time (up to 60 minutes). This could prove to be suboptimal for some applications, and may result in others not functioning. Opaque LSAs type-9 and type-10 do not have this problem as the fact that the LSA originator has ceased functioning can be immediately detected by the received LSA processing node due to the loss of the OSPF adjacency (case LSA type-9) or the sequence of OSPF adjacencies (case LSA type-10) connecting the LSA receiving and originating nodes. There is a parallel issue in OSPF for the AS scoped AS-external-LSAs (type-5 LSAs). This issue is addressed by using AS border information advertised in ASBR-summary-LSAs (type-4 LSAs), see [RFC2328] Section 16.4. This memo proposes a simple way for validating AS-scope opaque LSAs originated outside of the OSPF area where they are processed. This solution reuses mechanisms defined in [RFC2328] used for validation of type-5 LSAs. Bryskin, Zinin, Berger [Page 2] Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006 2. Solution The problem described in the previous section is solved by reusing The ASBR advertisement and summary mechanisms defined in [RFC2328]. The basic solution is for nodes that generate type-11 opaque LSAs to advertise themselves as ASBRs. This will enable nodes to track the reachability of the LSA originator either directly via the SPF calculation (for nodes in the same area) or indirectly via type-4 LSAs originated by ABRs (for nodes in other areas). It is important to note that this solution is not applicable for OSPF stub areas as neither type-11 LSAs are flooded nor type-4 LSAs are originated into such areas. The specific solution is: 1) An OSPF node that is configured to originate AS-scope opaque LSAs MUST set E-bit in the Options field of every originated OSPF Hello packet; 2) Such nodes also MUST set the E-bit in the Options field of the header of every LSA it injects into the network; 3) When processing a received type-11 Opaque LSA, the node MUST look up the routing table entries (potentially one per attached area) for the AS boundary router (ASBR) that originated the LSA. If no entries exist for router ASBR (i.e., ASBR is unreachable), the node MUST do nothing with this LSA. It also MUST discontinue using all Opaque LSAs injected into the network by the same originator whenever it is detected that the originator is unreachable. 3. Backward compatibility The solution proposed in this memo introduces no interoperability issues. Note, that OSPF nodes that do not implement this specification, will continue using stale type-11 LSAs even if the LSA originator implements it and announces itself as an ASBR. 4. Stub Area Considerations While the extension defined in this document does not present any interoperability issues, there are two issues related to OSPF stub areas. As previously stated, the extension defined in this document MUST NOT be used in stub networks. If the E-bit is set in the Options field of Hello packets in a stub area, the ExternalRoutingCapability check will fail and the adjacency will not be established. Bryskin, Zinin, Berger [Page 3] Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006 Additionally, the extension defined in this document does not overcome the fact that (according to [RFC2370]) type-11 LSAs originated outside of stub areas are not flooded into stub areas. Even if the flooding would have been allowed the validation of the LSAs using the mechanism described in this memo would not be possible because (according to [RFC2328]) ABRs do not originate type-4 LSAs into stub areas. 5. Security Considerations This document reuses an ASBR tracking mechanism that is already employed in basic OSPF for type-5 LSAs. Applying it to type-11 Opaque LSAs does not create any threats that are not already known for type-5 LSAs. 6. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Bryskin, Zinin, Berger [Page 4] Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". 7. Acknowledgement We would like to thank Acee Lindem for the useful discussion on the matter during IETF65. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC2328] Moy, J., " OSPF Version 2 ", RFC 2328, April 1998. [RFC2370] Coltun, R., " The OSPF Opaque LSA Option ", RFC 2730, July 1998. 9. Authors' Addresses Igor Bryskin Movaz Networks, Inc. Email: ibryskin@movaz.com Alex Zinin Alcatel, Email: zinin@psg.com Lou Berger LabN Consulting, LLC Email: lberger@labn.net 10. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bryskin, Zinin, Berger [Page 5] Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006 11. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.