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

["Smith, Donald" <Donald.Smith@qwest.com>]

If its not done as a BCP it will be harder to get some ISPs to adopt.
Some of the features in this draft will prevent your network elements
from becoming reflectors in a dos attack and therefore general adoption
is better for the internet at large.


(coffee != sleep) & (!coffee == sleep)
Donald.Smith@qwest.com giac   

> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On 
> Behalf Of Pekka Savola
> Sent: Thursday, September 21, 2006 12:27 AM
> To: Paul Quinn
> Cc: Ross Callon; opsec@ops.ietf.org; Darrel Lewis (darlewis); 
> pcain@coopercain.com
> Subject: Re: draft-ietf-opsec--infrastructure-security-00.txt
> 
> 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.

When the protocols are seriously flawed or broken then we should not
adhere to them.
See https://www.kb.cert.org/vuls/id/222750 as an example of how pmtud is
flawed.

The rfc1918 sourced and non routed address space for infrastructor
hiding are just TWO possible additional methods to hide your
infrastructor. I wouldn't consider them to be best common practices but
they are not uncommon either.
"The following sections present different
   options for accomplishing infrastructure hiding." 


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

If you ignore dscp except for when its sourced from your own trusted
systems you don't have to rewrite or recolor.
 

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


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.