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

["Darrel Lewis \(darlewis\)" <darlewis@cisco.com>]

Warren Kumari wrote:
> 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.
>

Thanks, appreciate it.
 
> 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?
> 

Sure.


> --------
> 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.
>

Understood, we'll clean it up.

 
> ------
> 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" ?

The latter seems more readable, thanks. 

> 
> ----------------
> 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.
>

So we try to draw a distinction here.  Due to the way vendors implement
the handling packets sent to their equipment, packets with IP prec 6 & 7
can be a dos vector.  Many providers have implemented a policy to remark
these to something else.  

In the Draft we state:

   All packets received by customer- and peer-facing Provider Edge (PE)
   router interfaces with IP Preference values of 6 or 7 or DSCP bits of
   11xxxx, as specified in RFC2474 [RFC2474] Differentiated Services
   Field Definition, should have the IP Preference bits rewritten.

Do you disagree with this limited use of remarking?  

 
> -------
> 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.
>

I agree that in some (hopefully rare) cases fragments will be seen in
traffic sent to devices.  In this case following the advice for
deploying these filters (log and evaluate, only then deny), should catch
the exceptions.


> ------------------
> 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.
> 

I think we cover these potential troubleshooting problems and
Infrastructure Hiding's relationship to EIACLs in the text of the draft.

If you feel that we missed something, suggested text is welcome.


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

Its fine that a provider using IS-IS still number their point-to-point
links, however, there is no reason to announce these addresses outside
of the provider's network.  Our referenced NANOG presentation from Ryan
McDowell gives a lot of details.  It seems like we need to add some of
that detail in 1-2 more sentances here.


> 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.

I tend to agree with you here. I'll defer to my co-authors working in
providers who suggested this section to see what they think. James?
Peter?


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

Thanks, noted.

> 
> 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?

Receive/Loopback ACLs are a tricky subject to broach in a BCP.  They
definitely are very important!  We chose the term "Aggregate Device
Access Control" as a vendor independent way to represent this concept.
Perhaps adding an example or two would clarify what we're talking about.


Another way to increase the visibility of this topic is to move the
section so it is the first one talked about in section 5.  Does this
seem reasonable?

> 
> 
> W

Thanks again for the detailed comments, it is very much appreciated!

-D