Skip to main content

Hiding Transit-Only Networks in OSPF
draft-ietf-ospf-prefix-hiding-07

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>,
    ospf mailing list <ospf@ietf.org>,
    ospf chair <ospf-chairs@tools.ietf.org>
Subject: Protocol Action: 'Hiding Transit-only Networks in OSPF' to Proposed Standard (draft-ietf-ospf-prefix-hiding-07.txt)

The IESG has approved the following document:
- 'Hiding Transit-only Networks in OSPF'
  (draft-ietf-ospf-prefix-hiding-07.txt) as Proposed Standard

This document is the product of the Open Shortest Path First IGP Working
Group.

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-hiding/


Ballot Text

Technical Summary

   A transit-only network is defined as a network connecting routers
   only.  In OSPF, transit-only networks are usually configured with
   routable IP addresses, which are advertised in Link State
   Advertisements (LSAs) but not needed for data traffic.  In addition,
   remote attacks can be launched against routers by sending packets to
   these transit-only networks.  This document presents a mechanism to
   hide transit-only networks to speed up network convergence and reduce
   remote attack vulnerability.

   In the context of this document, 'hiding' implies that the prefixes
   are not installed in the routing tables on OSPF routers. In some
   cases, IP addresses may still be visible when using OSPFv2.

   This document updates RFC 2328 and RFC 5340.

Working Group Summary

    The function is fairly straight-forward and the only discussion was
    related to OSPFv3 whether the DR should suppress advertisement of
    all prefixes on the link or whether it should be based on the
    individual link-LSA advertisements. After some discussion, we decided
    on the latter. 

Document Quality

    The document has gone through several WG review cycles and
    revisions. There is at least one implementation and another under
    development. 

Personnel
    Acee Lindem is the document shepherd and Stewart Bryant is the
    responsible AD. 



RFC Editor Note