Comments on: draft-ietf-opsec-infrastructure-security-01

[Warren Kumari <warren@kumari.net>]

Hi,

Thank you for writing this --  I feel that having this published  
would go a long way towards helping people secure their  
infrastructure -- all to often operators are not really aware of the  
improtance of this, or, if they are, are not sure where to begin.

I did have some comments on the draft, here are some of my thoughts:

Abstract:
RFCs 2267 and 3704 -- can this be changed to standard quoting syntax?

--------
1.  Introduction
"take many forms, including bandwidth saturation to crafted packets"  
-- including -> from

"non spoofed" -> "non-spoofed"

The introduction section is a little tricky to read -- the "The  
techniques outlined" sentence in particular is a run-on.

------
2.  Overview of Infrastructure Protection Techniques

I like this overview....

2.3.  Infrastructure Hiding
"If the destination of an attack is to an infrastructure address that  
is unreachable, attacks become far more difficult. "
perhaps this could be changed to:
"Attacks to infrastructure addresses that are unreachable are much  
more dofficult"
or
"It is much more difficult to attack infrastructure addresses that  
are unreachable" ?

----------------
4. Edge Rewrite/Remarking

To me this seems to be a bad approach -- unless a transit network is  
providing some sort of prioritization on traffic I do not feel that  
it should be touching DSCP bits. Apart from certain bits that are  
required to change (TTL, checksum) I like my packets to look the same  
when they pop out as they did when I put them in. If you are only  
rewriting packets that are destined to network infrastructure this  
isn't as much of a concern for me, but if you have some way to  
identify those packets, you can deal with them in other ways (as you  
already outline). Yes, many networks already scribble over DSCP, but  
unless that is do provide differentiated service I feel that it is  
bad form.

-------
5.2.1.  IP Fragments

This scares me somewhat -- in some cases traffic *is* fragmented (eg,  
Multihop BGP sessions, some SNMP, etc) for example:

show system statistics | match fra
        228832 fragments received
        0 fragments dropped (dup or out of space)
        0 fragments dropped (queue overflow)
        211 fragments dropped after timeout
        0 fragments dropped due to over limit
        158065 output datagrams fragmented
        0 fragments created
  [SNIP]
        0 fragmentation prohibited
        8823235 fragmented packets received
        0 fragments dropped
        1 fragment reassembly queue flushes
        1365293 fragmented packets sent
        0 fragments dropped


blocking fragments would cause fun troubleshooting issues.

------------------
6.  Infrastructure Hiding

Unless infrastructure hiding is implemented VERY VERY carefully it  
can lead to severe unhappiness -- numbering out of RFC1918 space can  
break traceroute in fun ways (peers won't accept your ICMP messages),  
path MTU discovery breaks, etc. In fact, I would suggest that it is  
much harder to correctly implement infrastructure hiding than it is  
to correctly block traffic at the border.

6.3.  IGP Configuration
Many (most?) providers using IS-IS still number their point-to-point  
links, primarily for monitoring / troubleshooting.

6.5.  Further obfuscation
"Should they find access to the infrastructure equipment in some  
way." -- fragmented sentence.
Possibly it is just me, but I feel that this is very much security  
through obscurity and is more likely to give a false sense of  
security than actually prevent exploits -- I also do not know of  
anyone who does this (although I suspect that wouldn't advertise if  
if they did), so I do not think it sounds as a Best CURRENT Practice.

--------
7: IPv6
"Because IPv6 uses a longer address space the scaling, and  
performance characteristics of ACLs maybe lower for IPv6 vs IPv4." --  
extra comma.


I read the draft a few times before noticing (under 5.2) "Many  
vendors leverage this simplified view to allow for the policy to be  
implemented in hardware, protecting the device's control plane.". I  
feel that receive / loopback ACLs are one of the MOST important tools  
in protecting infrastructure -- could they be given a little more  
recognition?


W

--
It is impossible to sharpen a pencil with a blunt axe.  It is equally  
vain
to try to do it with ten blunt axes instead
    --  E.W Dijkstra, 1930-2002