Securing Your OSPF Network

Previous Table of Contents Next


Abstract

This document defines an optional extension to OSPF that enables routers to distribute IP to link-layer address resolution information. An OSPF Address Resolution Advertisement (ARA) may include media-specific information, such as a multipoint-to-point connection identifier along with the address resolution information to support media-specific functions. The ARA option can be used to support router-to-router inter-subnet shortcut architectures such as those described in the draft titled, “Intra-area IP unicast among routers over legacy ATM.”

Draft Summary

This draft was written to enable OSPF to begin taking advantage of new characteristics of switching at the second layer of the OSI reference model. This type of switching is more commonly known as switched Layer 2 technologies.

The specific new characteristic this draft is concerned with is the new ability to provide inter-subnet shortcut data switching. This switching bypasses the Layer 3 forwarding intervention, which is where switching has traditionally been performed. For this Layer 2 switching to take place, the ingress device(s) must have the link-layer address of the egress device(s). This can either be accomplished through configuration or by dynamically resolving an IP address to a link-layer address.

This draft introduces a method for IP address to link-layer address resolution between routers and router-to-network inter-subnet shortcuts as previously discussed:

“Address Resolution Advertisements (ARAs) are used to distribute the link-layer associations of routers (Router ARAs) and their directly connected networks (Network ARAs) within and between OSPF areas. Distribution of ARAs is performed using standard OSPF flooding mechanisms. ARA information is encapsulated in Opaque LSAs (as defined in the Opaque LSA Draft) and flooded using the mechanisms defined in in the Opaque LSA Draft).”

This draft does not define an ARA architecture, instead it is meant to be used with the architecture as described in the draft titled, “Intra-area IP unicast among routers over legacy ATM.” The ARA option is designed to support the following types of operations:

  Shortcuts between core or access routers within ISP Backbones
  Shortcuts in enterprise networks between routers in the same OSPF autonomous system, between OSPF internal routers and autonomous system border routers (ASBR), or between routers and servers
  Distributed router architectures
  Interoperation with ION NHRP and ATMF MPOA
  Inter-subnet multicast shortcuts using LIJ or Point-to-MultiPoint procedures

OSPFv2 Domain of Interpretation (DOI) for ISAKMP

Date Published: October 1997

Author: Atkinson

Expiration Date: May 1998

File Name: draft-ietf-ospf-doi-00.txt

Abstract

The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the OSPFv2 Domain of Interpretation, which is defined to cover the use of ISAKMP to negotiate Security Associations for the OSPFv2 routing protocol.

Draft Summary

This Internet Draft details the requirements necessary for using the cryptographic authentication method and operation to provide data authentication for OSPFv2. This Internet Draft is required because OSPF authentication is only on the routing information between participating routers; it does not protect data! If this draft becomes a standard, there will be a means of protecting the data OSPF carries that is very tightly coupled within OSPF.

OSPF NSSA Option

Date Published: December 1997

Author: Coltun, Fuller, & Murphy

Expiration Date: June 1998

File Name: draft-ietf-ospf-nssa-update-03.txt

Abstract

This Internet Draft documents an optional type of OSPF area, which is somewhat humorously referred to as a not-so-stubby area (NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion.

The OSPF NSSA Option was originally defined in RFC 1587. All functional differences between this memo and RFC 1597, while expanding capability, are backward compatible in nature. Implementations of this memo and of RFC 1587 are interoperable.

Draft Summary

As previously discussed, NSSAs remove some of the topological limitations of regular stub areas by enabling the limited importing of external routes. This draft details some enhancements to NSSAs, with the most important change being an addition to the NSSA data structure and the operation of a OSPF router when configured as an NSSA Router. This data structure change is reflected by adding NSSATranslateState. This parameter enables you to control whether the NSSA Border Router performs translation of Type-7 LSAs into Type-5 LSAs and floods the translated Type-5 LSA. There are three settings possible:

  Enabled. Translation is always performed.
  Elected. Translation is performed because the router is the OSPF DR.
  Disabled. Translation is not currently being performed; this is the default setting.

This is not the only change being proposed, but it is the most fundamental. There are several other changes being performed as well, and they are as follows:

  Flooding of summary Type-3 LSAs into an NSSA will become optional
  External route calculations have been revised
  Multiple routers will be able to translate Type-7 LSAs into Type-5 LSAs
  When a new NSSA router begins translating LSAs, the previous translator, if elected by default, will cease translating

OSPF Opaque LSA

Date Published: February 1998

Author: Coltun

Expiration Date: August 1998

File name: draft-ietf-ospf-opaque-04.txt

Abstract

This memo defines enhancements to the OSPF protocol to support a new class of LSAs called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field might be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.


Previous Table of Contents Next




OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net