[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on: draft-ietf-opsec-infrastructure-security-01
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:
RFCs 2267 and 3704 -- can this be changed to standard quoting syntax?
"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
"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
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
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.
"Because IPv6 uses a longer address space the scaling, and
performance characteristics of ACLs maybe lower for IPv6 vs IPv4." --
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
It is impossible to sharpen a pencil with a blunt axe. It is equally
to try to do it with ten blunt axes instead
-- E.W Dijkstra, 1930-2002