RE: Comments on draft-ietf-opsec-current-practices-05.txt

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

Remarks/comments in response to your comments marked with DJS>

Our IDS reports a false negative rate of 0 (Dr J).
Donald.Smith@qwest.com giac   

> -----Original Message-----
> From: Merike Kaeo [mailto:merike@doubleshotsecurity.com] 
> Sent: Tuesday, July 11, 2006 7:43 PM
> To: Smith, Donald
> Cc: gmj@pobox.com; opsec@ops.ietf.org
> Subject: Re: Comments on draft-ietf-opsec-current-practices-05.txt
> 
> My replies marked with mmk>
> 
> On Jul 11, 2006, at 1:52 PM, Smith, Donald wrote:
> 
> > A few questions/comments marked with djs>
> >
> > Protocol Vulnerability Exploitation: An attack which takes advantage
> > of known protocol deficiencies to cause inappropriate behavior.
> >
> > djs>Is that protocol definitation vulnerabilities
> > djs>(ie udp can be trivially spoofed due to its connectionless based
> > defination)
> > djs> or is it vulnerablities in implmentation
> > djs>(ie protos snmp tool found nearly all snmp v1 
> implementations had
> > some flaws in them).
> 
> mmk> it is really both.....protocols have a combination of either  
> insecure design and/or insecure implementation.
> mmk> you think it necessary to explicitly say that? (I guess I  
> thought it was obvious but perhaps not)
DJS> I was not sure if it was both but thought it might be.
DJS> I see them as very different classes of vulnerabilities so it
DJS> might be worth mentioning. How about:
DJS> "known protocol vulnerabilities due to design or implementation
flaws"
> 
> > 2.1.2.  Security Practices
> >
> >    For physical device security, equipment is kept in highly  
> > restrictive
> >    environments.  Only authorized users with card key badges have  
> > access
> >    to any of the physical locations that contain critical network
> >    infrastructure devices.  These card-key systems keep track of who
> > accessed which location and at what time.
> >
> > djs>Most cardkey systems have a fail back "master key"
> > djs>in case the cardkey system is down for some reason.
> > djs>Do we need to address limiting the use of the master key
> > djs>AND logging any time it is uses while the card key system is on
> > line/funtional?
> 
> mmk> This is/was a survey so if you or other larger ISPs feel 
> that is  
> relevant because
> mmk> of how you do things operationally I am more than willing to  
> add.  It is easy enough to
> mmk> add a sentence like "Most cardkey systems have a  fail back  
> "master key"
> mmk> in case the cardkey system is down.  This "master key" usually  
> has limited access and its
> mmk> use is also carefully logged (which should only happen if the  
> cardkey system in NOT online/functional).

DJS> It is an area that is sometimes missed in the cardkey system
auditing/implementation.

> >
> >
> >
> > 2.2.1.1.  Confidentiality Violations
> >
> >    Confidentiality violations can occur when a miscreant intercepts
> >    confidential data that has been sent in cleartext.  This includes
> >    interception of usernames and passwords with which an 
> intruder can
> >    obtain unauthorized access to network devices.  It can 
> also include
> >    other information such as logging or configuration information  
> > if an
> >    administrator is remotely viewing local logfiles or configuration
> >    information
> >
> > djs> cleartext or weak encryption.
> 
> mmk> I can add that
> 
> >
> >
> > 2.2.3
> > Data Origin Authentication - Management traffic is strictly
> >       filtered to allow only specific IP addresses to have access  
> > to the
> >       infrastructure devices.  This does not alleviate risk from  
> > spoofed
> >       traffic.  Using SSH for device access ensures that noone can  
> > spoof
> >       the traffic during the SSH session.
> >
> > djs> if you combine on system filtering (acls) with bcp38 
> on the edges
> > then the risk
> > djs> of spoofing is mitigated baring a compromised internal system.
> 
> mmk> OK, I can change sentence to "This does not alleviate risk from
> mmk> spoofed traffic from a trusted compromised internal system"  I
> mmk> think perhaps I will also add the bcp38 on edges just so people  
> see it more
> mmk> and perhaps it will get a few more people using it :)
DJS> "This does not alleviate risk from ..." is part of the original
text.
DJS> I cut and pasted that portion.
DJS> the bcp38 reference is probably a good addition. There is another
related bcp
DJS> but the number escapes me right now:)

> 
> >
> >
> > 2.4.4.  Additional Considerations
> >
> >    For layer 2 devices, MAC address filtering and 
> authentication is  
> > not
> >    used.  This is due to the problems it can cause when  
> > troubleshooting
> >    networking issues.  Port security becomes unmanageable at a large
> >    scale where 1000s of switches are deployed.
> >
> >    Rate limiting is used by some ISPs although other ISPs believe  
> > it is
> >    not really useful since attackers are not well behaved and it  
> > doesn't
> >    provide any operational benefit over the complexity.  Some ISPs  
> > feel
> >    that rate limiting can also make an attacker's job easier by
> >    requiring the attacker to send less traffic to starve legitimate
> >    traffic that is part of a rate limiting scheme.  Rate limiting  
> > may be
> >    improved by developing flow-based rate-limiting capabilities with
> >    filtering hooks.  This would improve the performance as 
> well as the
> >    granularity over current capabilities.
> >
> >
> > djs> In the case of syn floods ratelimiting done correctly
> > djs> will limit the effects of the attack.
> > djs> The flooder will only send SYNs while the
> > djs> real clients will send syns until they get connected
> > djs> or quit trying and THEN they will become an estabilished
> > djs> connection (syn/ack, ack, ack/push, ack/urg ...)
> > djs> I am not sure how to capture that idea well in a single  
> > paragraph:(
> 
> mmk> not sure I get this.....are you saying that ratelimiting will  
> limit effect
> mmk> of SYN attack since some SYNs from real client will still get  
> through
> mmk> based on some probability? (or the real client will quit  
> trying)?  But how
> mmk> does this actually limit effect of attack?   What if no real  
> client SYNs
> mmk> get through?  Maybe I'm not getting what it
> mmk> means to do rate limiting 'correctly' here?
DJS> I think we can drop this comment as it doesn't 
DJS> really add to the subject much. However
DJS> yes some client syn's get through and then they
DJS> are no longer just SYNs so communication can take place.
DJS> assuming there are system resources available.
DJS> "correctly" is not easy to define. You have to have some idea
DJS> of how many SYNs /second the site would normally see. How many
DJS> SYNs /second the site can handle without full resource exaustion
etc...

> 
> > Generalized TTL Security Mechanism
> > djs> Not supported by most commercial network element vendors.
> > djs> Ask your vendor but I only know of one vendor
> > djs> that has implemented it and they only support it for bgp.
> 
> mmk> I should probably specifically say that it's used for BGP...it's
> mmk> what I meant,  And I thought 2 vendors supported it........for  
> bgp....

DJS> I thought only cisco implemented it in production code
DJS> and then only for BGP a few protocols (OSPF, EIGRP, NTP)
DJS> but there may be some other vendors that did. Last I heard
DJS> Juniper did NOT support it and has no plans to do so:(
> 
> > 2.6.  Software Upgrades and Configuration Integrity / Validation
> > djs> Is this intended to be limited to intra-ISP communication.
> > djs> It doesn't appear to address the actual download from 
> the vendor.
> 
> mmk> true....downloading from a vendor did not come into any 
> discussion.
> mmk>  should that be added?
DJS> I think so.
> 
> > 2.6.6.  Man-In-The-Middle
> >
> >    A man-in-the-middle attack attacks the identity of a 
> communicating
> >    peer rather than the data stream itself.  The attacker intercepts
> >    traffic that is sent between the infrastructure device 
> and the host
> >    used to upload/download the system image or 
> configuration file.   
> > He/
> >    she can then act on behalf of one or both of these systems.
> >
> >    If an attacker obtained a copy of the software image being  
> > deployed,
> >    he could potentially exploit a known vulnerability and gain  
> > access to
> >    the system.  From a captured configuration file, he could obtain
> >    confidential network topology information or even more damaging
> >    information if any of the passwords in the configuration 
> file were
> >    not encrypted.
> > djs> MIM can be used to attack the data stream.
> > djs> Commands can be inserted that would allow an
> > djs> attacker to add a local account with any password they choose.
> > djs> some of the exploit tools for cisco routers change the 
> config to
> > djs> provide admin access.
> >
> > djs> if any of the encrypted password can be decrypted 
> (such as cisco
> > type 7)
> 
> mmk> I was trying to keep this generic...do you think your 
> more specific
> mmk> examples are not covered by existing paragraphs?  I have no
> mmk> problem adding if concensus is that more detail is needed....
DJS> I am not sure we need the specific examples.
DJS> I am a bit concerned with the basic statement 
DJS> "A man-in-the-middle attack attacks the 
DJS> identity of a communicating
DJS>  peer rather than the data stream itself."
DJS> But I have honestly never seen an MIM attack
DJS> in the wild that attacked the datastream during 
DJS> configureation or image downloading. I can theorize how
DJS> to do one but have not attempted it.

> 
> > 2.8.3.  Routing Control Plane Filtering
> >
> >    Routing filters are used to control the flow of routing  
> > information.
> >    In IPv6 networks, some providers are liberal in accepting /48s  
> > due to
> >    the still unresolved multihoming issues.  Any 
> announcement received
> >    that is longer than a /48 for IPv6 routing and a /24 for IPv4  
> > routing
> >    is filtered out of eBGP.  Note that this is for non-customer  
> > traffic.
> >    Most ISPs will accept any agreed upon prefix length from its
> >    customer(s).
> >
> > djs> I see no mention of COPP/RE ratelimiting
> > djs> we have tested and implemented some reliable limiting.
> > djs> without that ratelimiting some very simple attacks can consume
> > djs> the NE's cpu.
> > djs> perhaps that is too new or belongs somewhere else?
> 
> mmk> This is newer than from when the survey was started but 
> I have been
> mmk> adding info as people have updated on their current practices.  I
> mmk> know of a few people that have been 'playing' with it 
> but need more
> mmk> details on actual deployment to incorporate effectively into  
> here (and
> mmk> I think this is the section to add it to)

DJS> I can share concepts with you.
DJS> I would have to get permission to share any
DJS> actual numbers. We have tested and implemented copps/RE ratelimits.
DJS> We discovered some of the recommended numbers needed adjusting to
limit 
DJS> the effects of certain attacks.

> 
> 
> Thanks for the thorough read.
> 
DJS> Your welcome, I am sorry I didn't 
DJS> get involved earlier.
DJS> Keep up the good work!!


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.