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

[Julien Laganier <[e-mail]>]

Thank you Alvaro. With the new text it is much clearer to me how the
proposal improves security. I have no further concerns.

--julien

On Tue, Jul 10, 2012 at 10:37 AM, Retana, Alvaro <[e-mail]> wrote:
> Julien:
>
> To make sure that your concerns are clarified, I wrote in some new information in the Security Considerations section.   Please see below and let me know if you still have concerns.  We'll publish an update before the deadline on Monday (Jul/9).
>
> Thanks!!
>
> Alvaro.
>
> [Note: the 2 middle paragraphs are new.]
>
> 8. Security Considerations
>
> One motivation for this document is to reduce remote attack vulnerability by hiding transit-only networks.  The result should then be that fewer OSPF core networks will be exposed to un-authorized access.
>
> The mechanisms described above result in reachability information from transit-only networks not being installed in the routers' forwarding tables.  The effect is that even if the address of a transit-only network is known, the forwarding information is not present in the routers to reach the destination.  Also, in some cases the address information is completely omitted from the LSA.
>
> Some information in the LSA (such as the OSPF Router ID) cannot be omitted.  Even though the Router ID is usually taken from an IP address on the router, the configuration can be easily changed.  Note again that having an address doesn't guarantee reachability if the information is hidden from the forwarding tables.
>
> While the steps described in this document are meant to be applied to transit-only networks ONLY, they could be used to hide other networks as well.  It is expected that the same care that users put on the configuration of other routing protocol parameters is used in the configuration of this extension.
>
>
>> -----Original Message-----
>> From: Acee Lindem [mailto:[e-mail]]
>> Sent: Friday, July 06, 2012 9:33 PM
>> To: Retana, Alvaro
>> Cc: Julien Laganier; Yi Yang; Abhay Roy; [e-mail]; draft-ietf-
>> [e-mail]; [e-mail]
>> Subject: Re: SecDir review of draft-ietf-ospf-prefix-hiding-04
>>
>> Actually, with this draft, the OSPF LSAs do not necessarily contain any
>> IP addresses - only topology information. The OSPF Router ID certainly
>> doesn't have to be a routable IP address and can be explicitly
>> configured to avoid the default of configured address selection
>> supported by most implementations.
>> Thanks,
>> Acee
>>
>> On Jul 6, 2012, at 4:50 PM, Retana, Alvaro wrote:
>>
>> > 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], draft-ietf-ospf-prefix-
>> [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
>