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

[Paul Quinn <paquinn@cisco.com>]

Hi Pekka,

Thanks for your feedback.  Building on Peter's comments, mine are  
inline prefaced by PQ>.

Paul


On Sep 12, 2006, at 11:38 PM, 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.

PQ>  Do you have examples (other than the comments below) of thing  
you find "questionable"?  The recommendations have been reviewed by  
many large operators and overwhelmingly the feedback has been  
positive wrt the applicability/deployment of the techniques.

> Specifically: EIACLs seems fine though mostly redundant if you can  
> do ingress filtering,

Please define ingress filtering.  EIACLs are simply a refinement of  
the general filtering concepts with specific intent: limit traffic  
destined to the infrastructure.  They have been widely deployment by  
many large carriers and have proven benefits.


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

Do you have suggested text that you feel would work better?


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

Point taken, for the next rev, we'll include a formal definition  
section that defines P, PE and CE devices and their roles.


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