Re: [secdir] SecDir review of draft-ietf-ospf-prefix-hiding-04

["Retana, Alvaro" <[e-mail]>]

Julien:

Hi!

[Thanks for forwarding.]

In short, avoiding installation of the routing information (even if still carried in the LSAs) means that the routers don't have forwarding information to reach a specific transit interface.  IOW, even if you know my IP address you can't send me a packet (if you're more than one hop away).  

We'll expand on the security considerations.

Thanks!!

Alvaro.

> -----Original Message-----
> From: Julien Laganier [mailto:[e-mail]]
> Sent: Friday, July 06, 2012 4:00 PM
> To: Retana, Alvaro
> Subject: Fwd: SecDir review of draft-ietf-ospf-prefix-hiding-04
> 
> FYI.
> 
> 
> ---------- Forwarded message ----------
> From: Julien Laganier <[e-mail]>
> Date: Fri, Jul 6, 2012 at 12:44 PM
> Subject: SecDir review of draft-ietf-ospf-prefix-hiding-04
> To: [e-mail], [e-mail],
> The IESG <[e-mail]>
> 
> 
> 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