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

[Pekka Savola <pekkas@netcore.fi>]

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?

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

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

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