RE: draft-ietf-opsec-infrastructure-security-01 additional comments

["Smith, Donald" <Donald.Smith@qwest.com>]

A few comments marked with DJS>
I will provide a small snippet of the original text and my
recommendations.
Some are just grammar type issues.




2.3.  Infrastructure Hiding

   Hiding the infrastructure of the network provides an elegant
   mechanism for protecting the network infrastructure.  If the
   destination of an attack is to an infrastructure address that is
   unreachable, attacks become far more difficult.  Infrastructure
   hiding can be achieved in several ways: i) MPLS techniques ii) IGP
   configuration iii) Route advertisement control.  Section 6 addresses
   these infrastructure hiding techniques in detail.
DJS> untargetable or not directly targetable not unreachable

3.1
   2.  Determine what traffic must be destined to the core devices from
       outside the AS.

DJS> and from which network addresses.

4.  Optionally, prior to implementing the deny action for all traffic
       destined to the core address block, a log action may be used and
       the results of the deny actions evaluated.
DJS> Log or count man be used instead of deny to evaluate what or how
much would have been dropped.

3.3
  The potential impact on the device's performance must be taken into
   consideration when deploying EIACLs.

DJS> Which impacts? Cpu, memory and IO... Latency and jitter? % of line
rate?

5.5
This reduces the device's profile.  
DJS> reduces the device's exposure.

5.2.1.  IP Fragments

   Traffic destined to a router is not typically fragmented.  Use of
   mechanisms to deny fragments to the device are recommended.

DJS> or rate limit. Also non-initial fragments should be dropped
automatically if the initial fragment was not received prior to any
non-initial frag.


5.2.3.  Access Control Implementation Guide

   Implementing a complex set of access controls for all traffic going
   to and from a router is non trivial.  The following is a recommended
   set of steps that has been used successfully by many carriers.

   1.  Develop list of required protocols.
DJS> ports, icmp type/code and protocols.

   2.  Develop source address requirements: Determine destination
       interface on router Does the protocol access a single interface?
       Does the protocol access many interfaces?  Does the protocol
       access a virtual or physical interfaces?

DJS> Says source address requirement but talks to destination address.

   3.  Prior to implementing with a deny, it is recommended to test the
       behavior with the action of "log" and observe the results

   4.  Deployment should be an iterative process: Start with relatively
       open lists then tighten as needed

DJS> Continuous/regular monitoring/evaluation required as things like
BGP announced routes have increased 2x in the last year or so. So what
was reasonable last year may be too restrictive next.


6.  Infrastructure Hiding

   Hiding the infrastructure of the network provides one layer of
   protection to the devices that make up the network core.  By hiding
   those devices (making them unreachable) 

DJS> unaddressable externally or not directly targetable. If the packets
run through it then it is reachable.


6.2.  MPLS Techniques

   While it may not be feasible to hide the entire infrastructure of
   large networks, it is certainly possible to reduce exposure of
   critical core infrastructure by hiding the existence and complexity
   of that infrastructure using an MPLS mesh where TTL is not
   decremented as packets pass through it as described in RFC 3443
   [RFC3443].  In this manner the number, addresses, and even existence
   of intermediary devices can be hidden from traffic as it passes
   through the core.  As pointed out by RFC 4381 [RFC4381], not only can
   this method hide the structure, it simplifies access restrictions to

DJS> infrastructure
   core devices. e.g.  Core equipment addresses are inaccessible from
   the "Public Internet" VPN.  The fact that this technique is
   transparent from a layer-3 viewpoint recommends it to providers of

DJS> makes it attractive to (instead of recommends it to)
 public services.  Because basic external troubleshooting and presents
   to all external views a simplified network structure with few
   potential target addresses exposed it offers a better balance of
   security against effort than most techniques for public networks.

DJS> Basic external troubleshooting and all other external views are
presented with a 
DJS> simplified network structure with fewer potentially targetable
addresses exposed 
DJS> it offers a better balance of security verses effort then most
infrastructure hiding 
DJS> techniques.

6.4.1.  Route Announcement Filtering

   Inasmuch as it is unavoidable that some network elements must be
DJS> In as much
   configured with IP addresses, it may be possible to assign these
   address out of netblocks for which the routing advertisement can be
DJS> no routing is not advertised external to the AS.

   filtered out, thereby limiting possible sources of traffic to core
   netblocks down to customers for whom you provide a default route, or
   direct peers who would make the effort to create a static route for
   your core netblock into your AS.  By assigning address for network
   infrastructure out of a limited number of address blocks which are
   well known to internal network administrators, the operator can
   greatly simplify EIACL configuration.  This can also minimize the
   frequency with which ACLs need to be updated based on changes in the
   network.  This can also have performance implications, especially for
DJS> This approach can also improve performance, especially for
equipment
DJS> where ACL's length is very limited. 



6.4.2.  Address Core Out of RFC 1918 Space

   In addition to filtering the visibility of core addresses to the
   wider Internet, it may be possible to use private RFC 1918 [RFC1918]
   netblocks for numbering infrastructure when IP addresses are required
   (eg, loopbacks).  This added level of obscurity takes prevention of
   wide distribution of your infrastructure address space one step
   further.  
DJS> This addition level of obscurity makes targeting your
infrastructure 
DJS> even more difficult.




7.  IPv6

   IPv6 Networks contain the same infrastructure security risks as IPv4.

DJS> Plus others that are IPv6 specific.




10.  Acknowledgements

   Don Smith provided invaluable comments and suggestions.  Pat Cain,
   Ross Callon, Vince Fuller, Barry Greene, George Jones, David Meyer,
   Peka Savola reviewed this document and provided feedback.

DJS> David Meyer and Peka Savola reviewed ...




if( sent(protocol= 1, type=8) && 
!((received()=(protocol=1,type=0))))
then plz reping.
Donald.Smith@qwest.com giac 


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.