draft-ietf-ospf-rfc2370bis-03.txt   draft-ietf-ospf-rfc2370bis-04.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Obsoletes: 2370 Igor Bryskin (Adva) Obsoletes: 2370 Igor Bryskin (Adva)
Category: Standards Track Alex Zinin (Alcatel) Category: Standards Track Alex Zinin (Alcatel)
Expiration Date: October 24, 2008 Original Author: Expiration Date: October 28, 2008 Original Author:
Rob Coltun (Acoustra Productions) Rob Coltun (Acoustra Productions)
April 24, 2008 April 28, 2008
The OSPF Opaque LSA Option The OSPF Opaque LSA Option
draft-ietf-ospf-rfc2370bis-03.txt draft-ietf-ospf-rfc2370bis-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 24, 2008. This Internet-Draft will expire on October 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines enhancements to the OSPF protocol to support a This document defines enhancements to the OSPF protocol to support a
new class of link-state advertisements (LSA) called Opaque LSAs. new class of link-state advertisements (LSA) called Opaque LSAs.
Opaque LSAs provide a generalized mechanism to allow for the future Opaque LSAs provide a generalized mechanism to allow for the future
skipping to change at page 2, line 23 skipping to change at page 2, line 23
3 The Opaque LSA ............................................ 4 3 The Opaque LSA ............................................ 4
3.1 Flooding Opaque LSAs ...................................... 5 3.1 Flooding Opaque LSAs ...................................... 5
3.2 Modifications To The Neighbor State Machine ............... 6 3.2 Modifications To The Neighbor State Machine ............... 6
4 Protocol Data Structures .................................. 7 4 Protocol Data Structures .................................. 7
4.1 Additions To The OSPF Neighbor Structure .................. 8 4.1 Additions To The OSPF Neighbor Structure .................. 8
5 Inter-Area Considerations ................................. 8 5 Inter-Area Considerations ................................. 8
6 Management Considerations ................................. 9 6 Management Considerations ................................. 9
7 Backward Compatibility .................................... 9 7 Backward Compatibility .................................... 9
8 Security Considerations ................................... 10 8 Security Considerations ................................... 10
9 IANA Considerations ....................................... 11 9 IANA Considerations ....................................... 11
10 References ................................................ 11 10 References ................................................ 12
10.1 Normative References ...................................... 11 10.1 Normative References ...................................... 12
10.2 Informative References .................................... 11 10.2 Informative References .................................... 12
11 Author's Addresses ........................................ 12 11 Author's Addresses ........................................ 13
12 Appendix A: OSPF Data formats ............................. 13 12 Appendix A: OSPF Data formats ............................. 13
12.1 The Options Field ......................................... 13 12.1 The Options Field ......................................... 13
12.2 The Opaque LSA ............................................ 14 12.2 The Opaque LSA ............................................ 15
13 Full Copyright Statement .................................. 16 13 Full Copyright Statement .................................. 16
14 Intellectual Property ..................................... 16 14 Intellectual Property ..................................... 16
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
skipping to change at page 5, line 29 skipping to change at page 5, line 29
o If the Opaque LSA is type-9 (the flooding scope is link-local) o If the Opaque LSA is type-9 (the flooding scope is link-local)
and the interface that the LSA was received on is not the same and the interface that the LSA was received on is not the same
as the target interface (e.g., the interface associated with a as the target interface (e.g., the interface associated with a
particular target neighbor), the Opaque LSA MUST be discarded particular target neighbor), the Opaque LSA MUST be discarded
and not acknowledged. An implementation SHOULD keep track of and not acknowledged. An implementation SHOULD keep track of
the IP interface associated with each Opaque LSA having a the IP interface associated with each Opaque LSA having a
link-local flooding scope. link-local flooding scope.
o If the Opaque LSA is type-10 (the flooding scope is area-local) o If the Opaque LSA is type-10 (the flooding scope is area-local)
and the area associated with Opaque LSA (as identified during and the area associated with the Opaque LSA (as identified
origination or from a received LSA's associated OSPF packet during origination or from a received LSA's associated OSPF
header) is not the same as the area associated with the target packet header) is not the same as the area associated with the
interface, the Opaque LSA MUST be discarded and not target interface, the Opaque LSA MUST be discarded and not
acknowledged. An implementation SHOULD keep track of the OSPF acknowledged. An implementation SHOULD keep track of the OSPF
area associated with each Opaque LSA having an area-local area associated with each Opaque LSA having an area-local
flooding scope. flooding scope.
o If the Opaque LSA is type-11 (the LSA is flooded throughout the o If the Opaque LSA is type-11 (the LSA is flooded throughout the
AS) and the target interface is associated with a stub area or AS) and the target interface is associated with a stub area or
NSSA, the Opaque LSA MUST NOT be flooded out the interface. A NSSA, the Opaque LSA MUST NOT be flooded out the interface. A
type-11 Opaque LSA that is received on an interface associated type-11 Opaque LSA that is received on an interface associated
with a stub area or NSSA MUST be discarded and not acknowledged with a stub area or NSSA MUST be discarded and not acknowledged
(the neighboring router has flooded the LSA in error). (the neighboring router has flooded the LSA in error).
skipping to change at page 10, line 12 skipping to change at page 10, line 12
stale type-11 LSAs even when the LSA originator implements the Inter- stale type-11 LSAs even when the LSA originator implements the Inter-
area procedures described in Section 6 of this document. area procedures described in Section 6 of this document.
8. Security Considerations 8. Security Considerations
There are two types of issues that need be addressed when looking at There are two types of issues that need be addressed when looking at
protecting routing protocols from misconfigurations and malicious protecting routing protocols from misconfigurations and malicious
attacks. The first is authentication and certification of routing attacks. The first is authentication and certification of routing
protocol information. The second is denial of service attacks protocol information. The second is denial of service attacks
resulting from repetitive origination of the same router resulting from repetitive origination of the same router
advertisement or origination a large number of distinct advertisement or origination of a large number of distinct
advertisements resulting in database overflow. Note that both of advertisements resulting in database overflow. Note that both of
these concerns exist independently of a router's support for the these concerns exist independently of a router's support for the
Opaque option. Opaque option.
To address the authentication concerns, OSPF protocol exchanges are To address the authentication concerns, OSPF protocol exchanges are
authenticated. OSPF supports multiple types of authentication; the authenticated. OSPF supports multiple types of authentication; the
type of authentication in use can be configured on a per network type of authentication in use can be configured on a per network
segment basis. One of OSPF's authentication types, namely the segment basis. One of OSPF's authentication types, namely the
Cryptographic authentication option, is believed to be secure against Cryptographic authentication option, is believed to be secure against
passive attacks and provide significant protection against active passive attacks and provide significant protection against active
skipping to change at page 10, line 39 skipping to change at page 10, line 39
authentication option depends completely on the strength of the authentication option depends completely on the strength of the
message digest algorithm (MD5 is currently the only message digest message digest algorithm (MD5 is currently the only message digest
algorithm specified), the strength of the key being used, and the algorithm specified), the strength of the key being used, and the
correct implementation of the security mechanism in all communicating correct implementation of the security mechanism in all communicating
OSPF implementations. It also requires that all parties maintain the OSPF implementations. It also requires that all parties maintain the
secrecy of the shared secret key. None of the standard OSPF secrecy of the shared secret key. None of the standard OSPF
authentication types provide confidentiality. Nor do they protect authentication types provide confidentiality. Nor do they protect
against traffic analysis. For more information on the standard OSPF against traffic analysis. For more information on the standard OSPF
security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF]. security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF].
Repetitive origination of advertisements are addressed by OSPF by Repetitive origination of advertisements is addressed by OSPF by
mandating a limit on the frequency that new instances of any mandating a limit on the frequency that new instances of any
particular LSA can be originated and accepted during the flooding particular LSA can be originated and accepted during the flooding
procedure. The frequency at which new LSA instances may be procedure. The frequency at which new LSA instances may be
originated is set equal to once every MinLSInterval seconds, whose originated is set equal to once every MinLSInterval seconds, whose
value is 5 seconds (see Section 12.4 of [OSPF]). The frequency at value is 5 seconds (see Section 12.4 of [OSPF]). The frequency at
which new LSA instances are accepted during flooding is once every which new LSA instances are accepted during flooding is once every
MinLSArrival seconds, whose value is set to 1 (see Section 13, MinLSArrival seconds, whose value is set to 1 (see Section 13,
Appendix B and G.5 of [OSPF]). Appendix B and G.5 of [OSPF]).
Proper operation of the OSPF protocol requires that all OSPF routers Proper operation of the OSPF protocol requires that all OSPF routers
skipping to change at page 11, line 17 skipping to change at page 11, line 17
details a way of gracefully handling unanticipated database details a way of gracefully handling unanticipated database
overflows. overflows.
In the case of type-11 Opaque LSAs, this document reuses an ASBR In the case of type-11 Opaque LSAs, this document reuses an ASBR
tracking mechanism that is already employed in basic OSPF for type-5 tracking mechanism that is already employed in basic OSPF for type-5
LSAs. Therefore, applying it to type-11 Opaque LSAs does not create LSAs. Therefore, applying it to type-11 Opaque LSAs does not create
any threats that are not already known for type-5 LSAs. any threats that are not already known for type-5 LSAs.
9. IANA Considerations 9. IANA Considerations
There are no changes to the IANA number assignment requirements from This document updates the requirements for the OSPF Opaque LSA type
[RFC2370]. registry, see http://www.iana.org/assignments/ospf-opaque-types.
Three changes are requested. The first is for references to
[RFC2370] to be replaced with references to this document. The second
change is for the Opaque type values in the range of 128-255 to be
reserved for "Private Use" as defined in [RFC2434]. The final change
is for the reference for registry value 1, Traffic Engineering LSA,
to be updated to [RFC3630].
Following the policies outlined in [RFC2434], Opaque type values in With these changes integrated, the registry should read:
the range of 0-127 are maintained by the IANA and allocated through
IETF Consensus. Opaque type values in the range of 128-255 are Open Shortest Path First (OSPF) Opaque Link-State
reserved for Private Use. Advertisements (LSA) Option Types
Registries included below:
- Opaque Link-State Advertisements (LSA) Option Types
Registry Name: Opaque Link-State Advertisements (LSA) Option Types
Reference: [This document]
Range Registration Procedures Notes
-------- ------------------------------------------ --------
0-127 IETF Consensus
128-255 Private Use
Registry:
Value Opaque Type Reference
------- ------------------------------------------ ---------
1 Traffic Engineering LSA [RFC3630]
2 Sycamore Optical Topology Descriptions [Moy]
3 grace-LSA [RFC3623]
4 Router Information (RI) [RFC4970]
5-127 Unassigned
128-255 Private Use
10. References 10. References
10.1. Normative References 10.1. Normative References
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995. 1793, April 1995.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997. requirements levels", RFC 2119, March 1997.
[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs ", RFC 2434, October IANA Considerations Section in RFCs ", RFC 2434, October
1998. 1998.
[RFC4750] Joyal, D., et. al., "OSPF Version 2 Management Information [RFC4750] Joyal, D., et al., "OSPF Version 2 Management Information
Base", RFC 4750, November 2006. Base", RFC 4750, November 2006.
10.2. Informative References 10.2. Informative References
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994. 1994.
[NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option", [NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003. RFC 3101, January 2003.
skipping to change at page 12, line 19 skipping to change at page 12, line 43
draft-ietf-ospf-mt-, January 2007. draft-ietf-ospf-mt-, January 2007.
[OSPFv3] Coltun, R., et al. "OSPF for IPv6", [OSPFv3] Coltun, R., et al. "OSPF for IPv6",
draft-ietf-ospf-ospfv3-update-, April 2008. draft-ietf-ospf-ospfv3-update-, April 2008.
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998. July 1998.
[RFC4576] Rosen, E., et. al., "Using a Link State Advertisement [RFC3630] Katz, D., Kompella, K., Yeund, D., "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC4576] Rosen, E., et al., "Using a Link State Advertisement
(LSA) Options Bit to Prevent Looping in BGP/MPLS IP (LSA) Options Bit to Prevent Looping in BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4576, June 2006. Virtual Private Networks (VPNs)", RFC 4576, June 2006.
11. Author's Addresses 11. Author's Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Igor Bryskin Igor Bryskin
skipping to change at line 710 skipping to change at line 740
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Generated on: Thu Apr 24 13:31:15 EDT 2008 Generated on: Mon Apr 28 17:10:34 EDT 2008
 End of changes. 14 change blocks. 
23 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/