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

[Pekka Savola <pekkas@netcore.fi>]

Sorry for delay in responding, inline,

On Thu, 14 Sep 2006, Paul Quinn wrote:
> On Sep 12, 2006, at 11:38 PM, Pekka Savola wrote:
> > 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.

With 'questionable' I was only referring to the issues that were 
listed further down in the email, especially the most user-unfriedly 
forms of infrastructure hiding (breaking PMTUD, sending 
RFC1918-sourced junk to your peers, using non-routed address space 
which is indistinguishable from spoofing).  Again, I think it's fine 
to do infrastructure hiding, but we should not recommend forms which 
break protocols like PMTUD or place burden on the neighboring 
networks.

I'm also not yet sure about DSCP rewriting; if it was more explicit 
that only preferred-treatment DSCP values were to be rewritten unless 
properly authorized (leaving most of the DSCPs untouched), I could 
probably that the justification for rewriting is strong and harmless 
enough.

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

The document seems to be saying that instead of general ingress 
filtering (also for transit traffic) you {c,sh}ould do this form of 
filtering where you look at the destination addresses first and then 
at your source addresses.

I think this is missing applicability discussion, because if you are 
able to use EIACLs, that means you have line-rate filtering capability 
at the edge.  Which also means that you could do spoofing protection 
for _all_ the traffic, including transit at the edge -- at the very 
least denying source addresses which belong to your infrastructure or 
single-homed customers.  But the document seems to be assuming you 
don't want or can't implement "filter out your own addresses" at 
borders.

Don't get me wrong, EIACLs seem like an OK solution, but I have 
difficulty seeing a scenario with EIACLs where 1) you couldn't deploy 
a more complete spoofing protection at your borders, and 2) EIACLs 
would provide significant additional benefit after applying the 
spoofing protection.  The additional benefit seems to be dropping 
certain kinds of traffic targeted at your routers at the edge instead 
at the router itself.  But on the other hand, EIACLs has significant 
maintenance cost especially if the P2P interfaces and loopbacks are 
not from a contiguous netblocks (so you'd have to enumerate hundreds 
or even a thousand infrastructure prefixes) or it's difficult to 
figure out the accepted traffic.


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

For example, in the abstract you could just say (copy-pasting from the 
-00 version):

This
   document focuses solely on traffic destined to elements of the the
   network infrastructure itself.  This document presents techniques
   that, together with network edge ingress filtering and RFC 2267 and
   RFC 3704, provides a defense in depth approach for infrastructure
   protection.  This document does not present recommendations for
   protocol validation (i.e. "sanity checking") nor does it address
   guidelines for general security configuration.

.. and minor wordsmithing (e.g., remove "solely").

You could start in a similar way in Introduction also, but keep the 
discussion of ingress filtering RFCs in a later part of the 
introduction.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings