Re: draft-ietf-opsec--infrastructure-security-00.txt

[Peter Schoenmaker <pds@lugs.com>]

Resending from the subscribed address because of maillist issues.  Sorry for the dup.

As one of the authors, and an operator...

In the operator space this document does show the Best common practices.
-  EIACLs provide a high level of protection and work effectively in real
networks.  They are used in real networks.  Many devices support EIACLs at
line rate without service impact.  Just because hardware may not be able to
support EIACLs, change the fact that they should be implemented.
-  Remarking provides a level of protection against giving malicious traffic
a higher forwarding priority than other traffic, and the same priority as 
control traffic.  The recommendation is to change the default in order to
increase security.  There are many other techniques that can be used other than
rewriting the DSCP bits, some of which are mentioned in the document.  Rewriting
DSCP/IP Precedence bits (6/7) is easy, effective, and low impact on traffic.
-  Fragments should be dropped that are to the device, not through the device.  
There should not be any cases where traffic to the device uses fragmented packets.

Operators are already using the recommendations from the document, and have been
for many years.   What this document is saying is that all the techniques should
be used together to create a stronger network infrastructure.  Existing limitations
in provider networks should not change the desire of providers to implement all
the recommendations.  This document help show providers what limitations need to
be overcome, whether that be hardware/software/non technical, in order to create 
a secure infrastructure.

more below.


On Wed, Sep 13, 2006 at 09:38:20AM +0300, Pekka Savola wrote:
> On Mon, 11 Sep 2006, Ross Callon wrote:
> >We would like to ask the working group for comments regarding
> >whether this document should be "informational" or "BCP".
> 
> I don't think this is BCP material for two reasons: (1) making it a 
> BCP doesn't seem to send a much stronger signal than Informational 
> (all ingress filtering RFCs are BCPs...), and (2) it includes some 
> recommendations that at least I find questionable.  Specifically: 
> EIACLs seems fine though mostly redundant if you can do ingress 
> filtering, edge DSCP rewrite is a bit questionable (networks should 
> support transparency unless there are strong reasons not to), not sure 
> if there is enough proof that dropping IP fragments is safe, 
> infrastructure hiding by RFC1918 or unrouted address space has issues.
> 
> Some detailed comments below,
> 
> substantial
> -----------
> 
> - abstract and introduction seem to start in a bit long-winded 
> fashion, discussing at length BCPs related to ingress filtering.  I'd 
> change the order of the text a bit -- start by focusing on what this 
> document is about rather than what it isn't.
> 
> - what's the definition of 'core device' in section 3.1?  To some 
> 'core device' means everything in the network that the network 
> operator controls, to some others only P devices (border devices don't 
> count), etc.
> 
> - "Routing traffic received from customer- and peer-facing
>    interfaces can safely have the IP Preference bits rewritten because
>    only a limited number of protocols are transmitted beyond the first
>    PE router."
> 
>  ==> I'm not quite sure what this means, but it might have issues. 
> Let's say you run a BGP session to a peer, and someone sends a DoS 
> attack from that peer to you.  As you rewrite all the packets, the BGP 
> sessions drop.  If you hadn't rewritten the BGP session traffic, it 
> would not have dropped as it has precedence bits set.  Is this good?

What it is saying is that Multihop BGP is used in only a few operationally
critical places.  (The only one i can think of is multihop sessions from
customers to blackhole servers.)  Most congestion control is done on egress
no on ingress.  By rewriting ingress BGP packets there is little impact 
on the session, as the congestion would occur at the customer's egress
interface.

From an operator point of view it is more desireable to have single 
customer ebgp session drop vs. an ibgp session.

> 
> - "To offer fully transparent service, a provider may not
>    wish to modify the IP precedence on transit traffic through the
>    network.  If a provider has alternate means of applying different
>    prioritization to router management and control traffic and transit
>    traffic then rewriting IP precedence bits is not required."
> 
>  ==> this seems backwards.  The de-facto way has been to provide 
> transparent Internet service.  Unless you use DSCP values for 
> something else, rewriting doesn't seem justified.  This seems like a 
> dirty hack to address shortcomings in border filtering.

This is a easy, effective, low impact solution to a very complicated problem.
RFC 1812 makes a reasonible recommendation to provide a mechanism to give
routing, management, and control traffic a higher forwarding priority.  It
does not give a method for validating routing, management, and control 
traffic.  The recommedation in this document is best common practice for most 
providers.

> 
> - section 5.2.1 recommands dropping all the fragments destined to a 
> router.  This seems to call for reference.  I'm not sure if this is 
> completely safe in all the contexts i.e., is there proof that this has 
> been sufficiently widely implemented to make it a good advice in all 
> the scenarios?  (E.g., with tunnel decaspsulation?)

The evidence seems to indicate fragments cause performance and security
problems on most exiting routers.  In order to create a strong infrastructure
fragements should not be supported to the router.   I can think of one 
example where legitimate traffic would be fragmented.  The case is when
GRE tunnels are used to send "clean" traffic to the customer using a GRE
header.  Even in this example the recommendation remains that fragments
should not be supported to devices because of performance and security
issues.  In this case the desire should be to increase the MTU, and 
configure GRE to no be fragmented.



> 
> - "Using a non-IP control plane for the core routing protocol can
>    substantially reduce the number of IP addresses that comprise (and
>    therefore, expose) the core."
> 
>   ==> you don't spell out how this reduces exposure.  I guess you're 
> assuming that if you use IS-IS, there is no need to give IP addresses 
> to point-to-point links in the backbone?  That has drawbacks as well. 
> Many operators that use IS-IS still number the p2p links.
> 
> - Section 6 describes infrastructure hiding.  I'm not against that if 
> it's transparent to the outsiders meaning that you don't place other 
> networks or users any burden by your actions.  For example, if you 
> number your network from RFC1918 space, you break traceroute by 
> sending RFC1918-sourced junk to your peers.  That's not good.  You 
> could just very well filter that out at your borders.  If you have a 
> MTU decrease anywhere in your network, the result is also extremely 
> bad for PMTUD.  So, I'd be extremely hesitant to recommend RFC1918 to 
> anyone.  Similar applies to unrouted address space because that's 
> really not very well distinguishable from spoofed address space, so it 
> breaks filtering under same scenarios.  As such, I would not call 
> infrastructure hiding (especially these two variants) an 'elegant 
> solution'.
> 
> editorial
> ---------
> 
> - there seemed a couple of instances of text where obviously markup 
> language has disappeared (a result of switching formats?) e.g. in 
> section 2, 2.3, 3.2
> - section 3, "infrastructureequipment"
> - section 5 "coem"
> - section 5.1, "widly", "serivce", 5.1.1: "serive"
> (I guess a spell check wouldn't hurt :-)
> - section 7.4, difficult to parse around "other combinations"
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

peter