Skip to main content

Last Call Review of draft-ietf-ospf-prefix-hiding-
review-ietf-ospf-prefix-hiding-secdir-lc-laganier-2012-07-13-00

Request Review of draft-ietf-ospf-prefix-hiding
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-07-06
Requested 2012-06-28
Authors Yi Yang , Alvaro Retana , Abhay Roy
I-D last updated 2012-07-13
Completed reviews Genart Last Call review of -?? by Vijay K. Gurbani
Genart Telechat review of -?? by Vijay K. Gurbani
Genart Telechat review of -?? by Vijay K. Gurbani
Secdir Last Call review of -?? by Julien Laganier
Assignment Reviewer Julien Laganier
State Completed
Request Last Call review on draft-ietf-ospf-prefix-hiding by Security Area Directorate Assigned
Result Ready w/nits
Completed 2012-07-13
review-ietf-ospf-prefix-hiding-secdir-lc-laganier-2012-07-13-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Disclaimer: I am no routing or OSPF expert and might be missing
something obvious...

According to its abstract the draft describes a mechanism that allows
hiding transit-only networks in OSPF:

   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
   minimize remote attack vulnerability.

While the desire to speed up the network convergence is probably
obvious and not of concern, I think the document and its security
considerations section in particular could do a better job at
explaining what the mechanism achieves in terms of minimizing remote
attack vulnerability.

As per my understanding, the proposed mechanism essentially remove the
subnet / netmask information from Link State Advertisements, but these
still contain the routers' IP addresses.

It is not clear to me how removing the subnet / netmask information
actually minimizes the risk of remote attacks.

First of all, the type of remote attacks that minimized should be made
more explicit. What is the target of the remote attacks? Is it any
address in the subnet? Or the address of a router? If the latter, then
it is not clear how the mechanism actually improves -- the router's IP
addresses are still in the LSAs so presumably an attacker can still
launch remote attacks on these addresses, no? If the former, then it
is not clear how effective is omission of the subnet in avoiding
attacks avoid addresses within that subnet -- addresses in the
(unknown) subnet can still be inferred from addresses of the routers,
no? Or is it the case that the LSAs containing the IP addresses of the
routers will not be propagated outside of an area that the attacker
has no access to?

Expanding the security considerations might help answering these questions...

--julien