From network-automation-owner@greatcircle.com Wed May 4 09:38:28 2005 X-Original-To: network-automation@greatcircle.com Received: from darksun.binsh.com (darksun.doomathon.com [64.232.216.23]) by mycroft.greatcircle.com (Postfix) with ESMTP id AAFCB32C4C9 for ; Wed, 4 May 2005 09:38:27 -0700 (PDT) Received: from darksun.binsh.com (localhost [127.0.0.1]) by darksun.binsh.com (8.12.6/8.12.6) with ESMTP id j44GdEs3022591 for ; Wed, 4 May 2005 09:39:14 -0700 (PDT) Received: from localhost (paxton@localhost) by darksun.binsh.com (8.12.6/8.12.6/Submit) with ESMTP id j44GdArQ022588 for ; Wed, 4 May 2005 09:39:14 -0700 (PDT) X-Authentication-Warning: darksun.binsh.com: paxton owned process doing -bs Date: Wed, 4 May 2005 09:39:10 -0700 (PDT) From: Paxton To: Subject: back to ACLs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200505/1 X-Sequence-Number: 99 Its been quiet for a couple of days! There were a couple of posts early on re: acl management. A few things mentioned there: * CiscoWorks ACL Manager (I heard cisco is dumping that? Anyone know anything about this?) * do-it-yourself-with-tftp (I'm not really sure if there was a more specific point here that I missed, but if everything everyone wanted could be done by just getting the config via tftp, editting the config, and pushing it back, we wouldn't be asking these questions, IMO) * the cosi collection of tools: http://cosi-nms.sourceforge.net/ I looked through the acl scripts/tools here and they seem pretty limited - a good start, though. Another vendor tool I've run across is Sol-Soft: http://www.solsoft.com/pages/home/home.php never tried it, so I have no idea what all it does, how much it costs, etc. Anyone have experience they want to share with any of the above or others? What's missing that you would want in acl management? For my part, I can't speak for ciscoworks/aclmanager or any other vendor tools. I have read the docs for aclmanager and on paper, it looks like it has (had?) some good features, but I've read its usability greatly maligned. I want something that lets me "slice and dice" access lists, like show me all the acl 101's that are different. Let me maintain a template for acl101 and then show me everywhere acl101 exists and doesn't match the template. Show me where I have acl101 defined, but not applied in any way (not just interface acls). Then actually look at the acl and tell me things like line 2 supercedes line 6 (line 6 is never used because of line 2). Or lines 5 and 6 can be combined into a single line for efficiency. Is there a reasonable use case for comparing acls across different vendors? thanks! oh, and I just want to share off-topic: http://news.com.com/AT38T%2C+Comcast+to+pay+340+million+in+Home+pact/2100-1036_3-5694270.html?tag=nefd.top From network-automation-owner@greatcircle.com Wed May 4 13:56:13 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id A0C0032C162 for ; Wed, 4 May 2005 13:56:12 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 4 May 2005 13:56:10 -0700 To: From: Brent Chapman Subject: Re: back to ACLs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200505/2 X-Sequence-Number: 100 At 9:39 AM -0700 5/4/05, Paxton wrote: >Its been quiet for a couple of days! There were a couple of posts early >on re: acl management. A few things mentioned there: > >* CiscoWorks ACL Manager (I heard cisco is dumping that? Anyone know >anything about this?) > >* do-it-yourself-with-tftp (I'm not really sure if there was a more >specific point here that I missed, but if everything everyone wanted could >be done by just getting the config via tftp, editting the config, and >pushing it back, we wouldn't be asking these questions, IMO) A key problem with this approach is, you don't know if the revised config is going to load properly. You might have typo'd one of the lines you added/changed/deleted. You might have added Just One More Line that pushes you beyond some internal limit of the device. Also, if you clear and redefine an access-list in place, you may have a short window of time during which you're unprotected (which might become a long window of time, if you get interrupted at just the wrong point). You just don't know... My usual "as safe as I can make it" approach to managing ACL's on Ciscos is to use a second access-list as a "temporary": 1) define a _new_ access-list that includes my changes 2) upload and execute the commands creating that new access-list 3) if and only if creating that new access-list succeeded, change the interface definition to refer to the new list instead of the old 4) if that works, then clean up by: a) clear/redefine the original list as a copy of the new one b) switch the interface back to the (updated) original list c) delete the new list (which was only used temporarily) So, for example, let's say that I currently had access-list 100 assigned to inbound packets on interface Ethernet0/0, and that there was no access-list 101 defined yet. I'd start by clearing and defining access-list 101: no access-list 101 access-list 101 permit ... access-list 101 permit ... access-list 101 deny ip any any Then, if and only if the commands above (to create access-list 101) succeeded, I'd do interface Ethernet0/0 ip access-group 101 in If that worked, I'd clean up by clearing and redefining access-list 100 to match the new access-list 101, and then switching the interface back to using the (now updated) access-list 100 and deleting the (now unused) access-list 101: no access-list 100 access-list 100 permit ... access-list 100 permit ... access-list 100 deny ip any any interface Ethernet0/0 ip access-group 100 in no access-list 101 You're left with an updated access-list 100, and with your interface config just what it was before, without ever having a time where you were unprotected. You've got to stop on errors after any command, obviously, and may need to do some cleanup (probably just "no access-list 101" or "no access-list 100", depending on where the error occurred). -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Wed May 4 14:11:40 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id 80C3632C30A; Wed, 4 May 2005 14:11:39 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 4 May 2005 14:11:36 -0700 To: Paxton , From: Brent Chapman Subject: Re: back to ACLs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200505/3 X-Sequence-Number: 101 At 9:39 AM -0700 5/4/05, Paxton wrote: >Its been quiet for a couple of days! There were a couple of posts early >on re: acl management. A few things mentioned there: > >* CiscoWorks ACL Manager (I heard cisco is dumping that? Anyone know >anything about this?) Cisco also has something called "SDM" (Security Device Manager); I've never used it (though I've had to clean up after it), but it appears to be a web-based interface which is built into certain products, specifically aimed at generating ACLs and other security-related parts of a config file. http://www.cisco.com/en/US/products/sw/secursw/ps5318/products_data_sheet0900aecd800fd118.html Like I said, I've never used it myself. One of my consulting clients has Cisco config files which are littered with remarks and ACLs and so forth that appear to have been generated by SDM (i.e., there are remarks in ACLs like "SCM_ACL Category=2", which I presume is some sort of marker for the SDM system). There are some broken things about these configs, which I'm fixing (ACLs defined but not used, ACLs applied inbound when they should be applied outbound, etc.; stuff like that). I don't know if SDM is the source of the brokenness, or whether the config was manually broken after SDM was used to set it up but before I inherited the configs, or what. -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Wed May 4 14:26:08 2005 X-Original-To: network-automation@greatcircle.com Received: from mail02.corp.tellme.com (mail02.corp.tellme.com [209.157.157.101]) by mycroft.greatcircle.com (Postfix) with ESMTP id A194132C307 for ; Wed, 4 May 2005 14:26:07 -0700 (PDT) Received: from mail02.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id D71383516 for ; Wed, 4 May 2005 14:26:06 -0700 (PDT) Received: from shell01.corp.tellme.com (shell01.corp.tellme.com [209.157.157.54]) by mail02.corp.tellme.com (Postfix) with ESMTP id B24CE3508 for ; Wed, 4 May 2005 14:26:06 -0700 (PDT) Received: by shell01.corp.tellme.com (Postfix, from userid 1440) id AA9CFA21; Wed, 4 May 2005 14:26:06 -0700 (PDT) Date: Wed, 4 May 2005 14:26:06 -0700 From: David Williamson To: network-automation@greatcircle.com Subject: Re: back to ACLs Message-ID: <20050504212606.GP1877@shell01.corp.tellme.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Archive-Number: 200505/4 X-Sequence-Number: 102 On Wed, May 04, 2005 at 01:56:10PM -0700, Brent Chapman wrote: > My usual "as safe as I can make it" approach to managing ACL's on > Ciscos is to use a second access-list as a "temporary": I think that's probably a very common approach. At one large site I'm familiar with, they actually don't swap back to using acl 100 immediately, and simply move between 100 and 101 as required, which saves a couple of steps. One neat thing they also do is to maintain a central acl numbering authority. This is really just a centrally maintained flat file with acl number pairs, the purpose of that specific acl, and which routers use that acl. Obviously, that has scaling issues with numbered lists, but the intent is very good, and helps to at least keep numbering clear and all of the lists well organized. My real problem with acls is also maintenance oriented. What I would really like is to take a written policy like "I want to never except netbios packets from the Internet", and convert that into a proper acl at any relevant security border point. That has historically been very hard. One usual approach to this seems to be to use some sort of meta-language to represent the policy, and to then generate the specific acl from that. This usually doesn't work real well, because the meta-language doesn't represent policy, but instead represents an abstraction of the underlying acl. In addition, the meta-language is usually as abtuse as the native acl language...which makes it just as hard to maintain in many cases. Perhaps an interesting approach would be to define a set of devices that represent borders between security zones, and then create a set of rules (i.e., policy) about the types of connections between the zones. Again, there's the problem of how to represent the policy in the correct acl language (which also varies considerably by platform, just to make it more fun.) In an ideal world, a change in the policy would be automatically pushed into a proper form for auto-configuration. Verification of the new config might be an interesting problem.... (My apologies if some of this has already been hashed out here...I'm still trying to find the time to read the archives of this list. :) -David From network-automation-owner@greatcircle.com Wed May 4 19:47:48 2005 X-Original-To: network-automation@greatcircle.com Received: from throat.webalive.biz (throat.webalive.biz [69.93.211.26]) by mycroft.greatcircle.com (Postfix) with SMTP id D5C0132C46F for ; Wed, 4 May 2005 19:47:47 -0700 (PDT) Received: (qmail 10813 invoked from network); 5 May 2005 02:46:15 -0000 Received: from unknown (HELO ?10.0.1.254?) (203.222.142.146) by 0 with SMTP; 5 May 2005 02:46:15 -0000 Date: Thu, 5 May 2005 12:49:35 +1000 (EST) From: architect@webalive.biz X-X-Sender: tnelson@tnelson.webalive.biz To: Brent Chapman Cc: network-automation@greatcircle.com Subject: Re: back to ACLs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Archive-Number: 200505/5 X-Sequence-Number: 103 On Wed, 4 May 2005, Brent Chapman wrote: >> * do-it-yourself-with-tftp (I'm not really sure if there was a more >> specific point here that I missed, but if everything everyone wanted could >> be done by just getting the config via tftp, editting the config, and >> pushing it back, we wouldn't be asking these questions, IMO) > > A key problem with this approach is, you don't know if the revised config is > going to load properly. You might have typo'd one of the lines you The only real solution I heard to this one was a computer* connected to the serial port of the router which would load the new config, and if specified tests failed, then it would back out to the old config. And even that wasn't perfect as it didn't preserve state. And that solution would require someone to sink some work into it; it's not done yet :). * It was suggested that "computer" could be eg. a mini mac or something. If it's in a rack with a bunch of others, there are devices with 12 serial ports that can be attached to the one computer. There may have been another suggestion that was good, but I don't recall if there was. :) -- Tim Nelson Server Administrator WebAlive Technologies Global Level 1 Innovation Building, Digital Harbour 1010 LaTrobe Street Docklands, Melbourne, Vic, 3008 Phone: +61 3 9934 0812 Fax: +61 3 9934 0899 E-mail: tim.nelson@webalive.biz http://www.webalive.biz/ "Your Business, Your Web, Your Control" From network-automation-owner@greatcircle.com Wed May 4 20:14:36 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 7460632C593; Wed, 4 May 2005 20:13:22 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 366791937E; Wed, 4 May 2005 23:13:21 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17017.36689.134439.128625@perdition.linnaean.org> Date: Wed, 4 May 2005 23:13:21 -0400 To: architect@webalive.biz Cc: Brent Chapman , network-automation@greatcircle.com Subject: Re: back to ACLs In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200505/6 X-Sequence-Number: 104 > * It was suggested that "computer" could be eg. a mini mac or something. > If it's in a rack with a bunch of others, there are devices with 12 > serial ports that can be attached to the one computer. You can cut down on the number of boxes. The multiport serial boxes at www.cyclades.com are flash based linux machines. As I recall, they don't have much flash, but higher end models can eat pcmcia cards. That will get you the serial ports and the computer in 1u. From network-automation-owner@greatcircle.com Wed May 4 22:18:55 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id C0C6132C595; Wed, 4 May 2005 22:18:54 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 4 May 2005 22:18:51 -0700 To: architect@webalive.biz From: Brent Chapman Subject: Re: back to ACLs Cc: network-automation@greatcircle.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200505/7 X-Sequence-Number: 105 At 12:49 PM +1000 5/5/05, architect@webalive.biz wrote: >On Wed, 4 May 2005, Brent Chapman wrote: > >>>* do-it-yourself-with-tftp (I'm not really sure if there was a more >>>specific point here that I missed, but if everything everyone wanted could >>>be done by just getting the config via tftp, editting the config, and >>>pushing it back, we wouldn't be asking these questions, IMO) >> >>A key problem with this approach is, you don't know if the revised >>config is going to load properly. You might have typo'd one of the >>lines you > > The only real solution I heard to this one was a computer* >connected to the serial port of the router which would load the new >config, and if specified tests failed, then it would back out to the >old config. That solves an important problem, but it's a different problem than what I was talking about. The problem that solves is "how do I ensure continued control access to the router?" The problem I was describing a solution to is "how do I make atomic changes to ACLs on a Cisco, given that Cisco access-list changes are line-by-line and definitely not atomic". The key idea behind what I suggested is that, while access-list changes aren't atomic, setting the "ip access-group NNN [in|out]" for a given interface _is_ atomic (approximately), and you can use that by defining a new access-list and then assigning it to the interface, rather than modifying the existing access-list. -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Wed May 4 23:05:08 2005 X-Original-To: network-automation@greatcircle.com Received: from linux.overloaded.net (overloaded.net [65.17.224.194]) by mycroft.greatcircle.com (Postfix) with ESMTP id F127632C5C7 for ; Wed, 4 May 2005 23:04:47 -0700 (PDT) Received: (qmail 14029 invoked by uid 210); 5 May 2005 02:04:46 -0400 Received: from 10.0.0.254 by linux.overloaded.net (envelope-from , uid 201) with qmail-scanner-1.25st (clamdscan: 0.83/866. f-prot: 4.5.3/3.16.1. spamassassin: 3.0.2. perlscan: 1.25st. Clear:RC:1(10.0.0.254):. Processed in 0.325499 secs); 05 May 2005 06:04:46 -0000 Received: from unknown (HELO speedy) (10.0.0.254) by 10.0.0.1 with SMTP; 5 May 2005 02:04:46 -0400 Message-ID: <007001c55138$55c094f0$0261a8c0@speedy> From: "Matt Buford" To: , "Brent Chapman" Cc: References: Subject: Re: back to ACLs Date: Thu, 5 May 2005 02:04:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Archive-Number: 200505/8 X-Sequence-Number: 106 Brent Chapman wrote: > The problem I was describing a solution to is "how do I make atomic > changes to ACLs on a Cisco, given that Cisco access-list changes are > line-by-line and definitely not atomic". The key idea behind what I > suggested is that, while access-list changes aren't atomic, setting the > "ip access-group NNN [in|out]" for a given interface _is_ atomic > (approximately), and you can use that by defining a new access-list and > then assigning it to the interface, rather than modifying the existing > access-list. Harass your Cisco reps about this. We bring this up every time we have a meeting with them. No matter how good the hardware might be and whatever other features they add to the OS, their interface is really becoming unmanagable. If everyone tells them this, perhaps they will eventually listen. To make things worse, they have taken to integrating the configuration of things like load balancers right into the main IOS config. For example, the CSM load-balancer card for the 6500 is configured through a section of the IOS config. "conf t; mod csm 2; ..." This makes it even harder to wade through the config to find the relevant sections. At this point, I've almost completely abandoned the "sh run" command in the routers. It is useless. Some of my routers have more than 11,000 lines in their configurations. I have to use rancid to "sh run" and write it to a temp file (or at least pipe it to less) if I want to actually be able to get anything useful out of it. From network-automation-owner@greatcircle.com Thu May 5 09:05:46 2005 X-Original-To: network-automation@greatcircle.com Received: from mail.inetlabs.net (pcp0010761769pcs.howard01.md.comcast.net [68.33.126.204]) by mycroft.greatcircle.com (Postfix) with ESMTP id DF9E332C5DB for ; Thu, 5 May 2005 09:05:44 -0700 (PDT) Received: from Spooler by mail.inetlabs.net (Mercury/32 v4.01b) ID MO00032B; 5 May 2005 11:58:09 -0400 Received: from spooler by mail.inetlabs.net (Mercury/32 v4.01b); 5 May 2005 11:58:05 -0400 Received: from hagal (162.129.44.17) by mail.inetlabs.net (Mercury/32 v4.01b) with ESMTP ID MG00032A; 5 May 2005 11:58:01 -0400 From: "Kevin Stone" To: "'Network Automation'" Subject: Re: back to ACLs Date: Thu, 5 May 2005 12:05:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVRMPMs4vnoc1tcQN2whohA9oJswwAVsKTA Message-ID: <465C14A629F2@mail.inetlabs.net> X-Archive-Number: 200505/9 X-Sequence-Number: 107 The behavior of access lists has changed in the latest versions of IOS, sort of... If you use named access lists you have ACL sequence numbering available. Basically each line of an access list is numbered and can be added/removed individually. We are in the process of reviewing all our access lists and converting them to named lists just for this reason. It doesn't solve all the problems with ACLs but it helps. You can get more details from this link: http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guid e09186a0080134a60.html -Kevin -----Original Message----- From: network-automation-owner@greatcircle.com [mailto:network-automation-owner@greatcircle.com] On Behalf Of Brent Chapman Sent: Thursday, May 05, 2005 1:19 AM To: architect@webalive.biz Cc: network-automation@greatcircle.com Subject: Re: back to ACLs At 12:49 PM +1000 5/5/05, architect@webalive.biz wrote: >On Wed, 4 May 2005, Brent Chapman wrote: > >>>* do-it-yourself-with-tftp (I'm not really sure if there was a more >>>specific point here that I missed, but if everything everyone wanted >>>could be done by just getting the config via tftp, editting the >>>config, and pushing it back, we wouldn't be asking these questions, >>>IMO) >> >>A key problem with this approach is, you don't know if the revised >>config is going to load properly. You might have typo'd one of the >>lines you > > The only real solution I heard to this one was a computer* connected >to the serial port of the router which would load the new config, and >if specified tests failed, then it would back out to the old config. That solves an important problem, but it's a different problem than what I was talking about. The problem that solves is "how do I ensure continued control access to the router?" The problem I was describing a solution to is "how do I make atomic changes to ACLs on a Cisco, given that Cisco access-list changes are line-by-line and definitely not atomic". The key idea behind what I suggested is that, while access-list changes aren't atomic, setting the "ip access-group NNN [in|out]" for a given interface _is_ atomic (approximately), and you can use that by defining a new access-list and then assigning it to the interface, rather than modifying the existing access-list. -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Thu May 5 09:14:19 2005 X-Original-To: network-automation@greatcircle.com Received: from mail01.corp.tellme.com (mail01.corp.tellme.com [209.157.157.98]) by mycroft.greatcircle.com (Postfix) with ESMTP id 2EC8032C53A for ; Thu, 5 May 2005 09:14:18 -0700 (PDT) Received: from mail01.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id 4176B937 for ; Thu, 5 May 2005 09:14:18 -0700 (PDT) Received: from shell01.corp.tellme.com (shell01.corp.tellme.com [209.157.157.54]) by mail01.corp.tellme.com (Postfix) with ESMTP id 2CB4F92C for ; Thu, 5 May 2005 09:14:18 -0700 (PDT) Received: by shell01.corp.tellme.com (Postfix, from userid 1440) id 13A7EA21; Thu, 5 May 2005 09:14:18 -0700 (PDT) Date: Thu, 5 May 2005 09:14:18 -0700 From: David Williamson To: 'Network Automation' Subject: Re: back to ACLs Message-ID: <20050505161417.GY1877@shell01.corp.tellme.com> References: <465C14A629F2@mail.inetlabs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465C14A629F2@mail.inetlabs.net> User-Agent: Mutt/1.4.2.1i X-Archive-Number: 200505/10 X-Sequence-Number: 108 On Thu, May 05, 2005 at 12:05:31PM -0400, Kevin Stone wrote: > If you use named access lists you have ACL sequence numbering available. > Basically each line of an access list is numbered and can be added/removed > individually. We are in the process of reviewing all our access lists and > converting them to named lists just for this reason. It doesn't solve all > the problems with ACLs but it helps. Named ACLs are great for keeping the identities of your lists organized, as you can easily run our of extended access list numbers in a large network. This also massively simplifies centralized control of your ACls, assuming you use unique names across your organization. Change control? Varies by platform. My current gig is all Juniper, which makes ACL changes very easy to manage. The problem I still have is how to get a stated policy into the correct form, and installed on the right routers (and the right interface in the right direction). That's still highly manual, even with good automation of the push and verification mechanisms that control configurations. At this point, someone still has to write the config.... Someone suggested privately cfengine for routers. While it wsa meant to be humerous, why not? I'm not a cfengine fan at all, but the intent is good: it intends to create a bridge between policy and configuration. That would make me happier. -David From network-automation-owner@greatcircle.com Thu May 5 21:04:23 2005 X-Original-To: network-automation@greatcircle.com Received: from throat.webalive.biz (throat.webalive.biz [69.93.211.26]) by mycroft.greatcircle.com (Postfix) with SMTP id 7899032C4BA for ; Thu, 5 May 2005 21:03:54 -0700 (PDT) Received: (qmail 7463 invoked from network); 6 May 2005 04:02:21 -0000 Received: from unknown (HELO ?10.0.1.254?) (203.222.142.146) by 0 with SMTP; 6 May 2005 04:02:21 -0000 Date: Fri, 6 May 2005 14:05:40 +1000 (EST) From: Tim Nelson X-X-Sender: tnelson@tnelson.webalive.biz To: David Williamson Cc: 'Network Automation' Subject: Re: back to ACLs In-Reply-To: <20050505161417.GY1877@shell01.corp.tellme.com> Message-ID: References: <465C14A629F2@mail.inetlabs.net> <20050505161417.GY1877@shell01.corp.tellme.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Archive-Number: 200505/11 X-Sequence-Number: 109 On Thu, 5 May 2005, David Williamson wrote: > Someone suggested privately cfengine for routers. While it wsa meant > to be humerous, why not? I'm not a cfengine fan at all, but the intent is > good: it intends to create a bridge between policy and configuration. That > would make me happier. I was the wag that suggested that :). cfengine still doesn't have a way of controlling ACLs (although I used editfiles for that on Linux). Let us know how you go at trying to get it running on a router :). You also said that, with cfengine, the learning curve for newcomers is steep (hope you don't mind me quoting you in public :) ). Really? I didn't find it that bad, but I was trained as a programmer :). One problem with network automation is that some of the people who have been doing everything by hand will not be used to writing things more programatically, and will have a steeper learning curve. But to my mind, the solution to that is to get the automation support level to a high enough level of quality that people new to the field can ignore the whole lower level :). > The problem I still have is how to get a stated policy into the correct > form, and installed on the right routers (and the right interface in > the right direction). That's still highly manual, even with good automation > of the push and verification mechanisms that control configurations. At > this point, someone still has to write the config.... Hmm. If I understand, you're saying you have a centralised repository for your network config, but it's still a pain to write the actual configuration. Maybe the thing to do would be to set up something like the following: template of type-config + generic config ==> generator(type) ==> actual config The "template of type-config" could start out as eg. the config for a cisco. The generic config could start out as a list of ACLs in ACL-lang (a new language we just invented). You could replace the ACL section of the template with a line saying "" or something, and then run it through a generator(cisco), which would generate actual cisco config from the template (non-ACL stuff) and the generic config (which would require an interpreter). The hard part of that is writing the generators. And that would only cover ACLs. But it would mean that you could automate various parts of your config as the generators were finished, rather than having to do it all at once. Probably all obvious stuff, but it might generate some useful discussion. :) -- Tim Nelson Server Administrator WebAlive Technologies Global Level 1 Innovation Building, Digital Harbour 1010 LaTrobe Street Docklands, Melbourne, Vic, 3008 Phone: +61 3 9934 0812 Fax: +61 3 9934 0899 E-mail: tim.nelson@webalive.biz http://www.webalive.biz/ "Your Business, Your Web, Your Control" From network-automation-owner@greatcircle.com Fri May 6 13:01:49 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id AC3F032C527; Fri, 6 May 2005 13:01:47 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <465C14A629F2@mail.inetlabs.net> <20050505161417.GY1877@shell01.corp.tellme.com> Date: Fri, 6 May 2005 13:01:44 -0700 To: Tim Nelson , David Williamson From: Brent Chapman Subject: Re: back to ACLs Cc: 'Network Automation' Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200505/12 X-Sequence-Number: 110 At 2:05 PM +1000 5/6/05, Tim Nelson wrote: >>The problem I still have is how to get a stated policy into the correct >>form, and installed on the right routers (and the right interface in >>the right direction). That's still highly manual, even with good automation >>of the push and verification mechanisms that control configurations. At >>this point, someone still has to write the config.... > > Hmm. If I understand, you're saying you have a centralised >repository for your network config, Yeah, they do; his name is "Rich"... ;-) >but it's still a pain to write the actual configuration. Maybe the >thing to do would be to set up something like the following: > >template of type-config + generic config > ==> generator(type) ==> actual config > > The "template of type-config" could start out as eg. the >config for a cisco. The generic config could start out as a list of >ACLs in ACL-lang (a new language we just invented). You could >replace the ACL section of the template with a line saying "insert_acls() ?>" or something, and then run it through a >generator(cisco), which would generate actual cisco config from the >template (non-ACL stuff) and the generic config (which would require >an interpreter). > > The hard part of that is writing the generators. And that >would only cover ACLs. But it would mean that you could automate >various parts of your config as the generators were finished, rather >than having to do it all at once. I'm not sure that's a feasible approach, because of the variation in ACL semantics and implementation details. The "least common denominator" across vendors is pretty low... I've frequently found it useful to create small tools to generate ACLs for particular vendors; however, the tools always end up having significant knowledge of the vendor semantics and implementation embedded within them. I haven't found a useful way to create a meta-language that would span multiple router vendors, though. That doesn't mean it couldn't be done; just that I've always found it more useful for my circumstances to create a small set of vendor-specific tools to generate ACLs, rather than an over-arching set. I'd love for somebody to demonstrate that this _is_ possible in a useful way. -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Sat May 7 08:43:01 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 5D8A132C54D; Sat, 7 May 2005 08:42:33 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id EC5EF19387; Sat, 7 May 2005 11:42:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17020.57827.844124.207634@perdition.linnaean.org> Date: Sat, 7 May 2005 11:42:27 -0400 To: Brent Chapman Cc: Tim Nelson , David Williamson , 'Network Automation' Subject: Re: back to ACLs In-Reply-To: References: <465C14A629F2@mail.inetlabs.net> <20050505161417.GY1877@shell01.corp.tellme.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200505/13 X-Sequence-Number: 111 > I'm not sure that's a feasible approach, because of the variation in > ACL semantics and implementation details. The "least common > denominator" across vendors is pretty low... It's a feasible approach, it's just work. If such things were not a feasible approach, it would be impossible for me to write a scheme interpreter that was a scheme interpreter on top of things with wildly different semantics and a very low least common denominator. That said, I'm usually targetting scheme interpreters for things that are at least turing complete. ACL interpreters usually aren't that expressive. ACL generation is a limited domain, compared to something like a scheme interpreter. Your doing language design and compiler writing if you want to solve this problem; obviously the enticement to Keep It Simple Stupid and avoid writing a domain language and compiler is high (been there, avoided that). A way to arrive at "how" is to figure out what the effect you are trying to produce is, and then, for each target language, work backwards from the effect to figure out what kind of objects you must be able to speak of in your source language in order to produce the desired effect in each target language. In the case of ACL generation, the effect you are trying to explain is roughly: you have an adirected, cyclic graph that represents your network in some fashion. at some level or another, you want to explain why some parts of the graph can't talk to one another. The sort of things you'll obviously need for IP and TCP/UDP type firewalling include IP addresses and port numbers. As you examine your target vendors, you will no doubt find many more concepts with wildly differing semantics. Interface names will obviously show up in many vendors concepts, but beyond that... Let's see: * Cisco IOS * Cisco PIX * Juniper * Netscreen * IPF * iptables * pf * ipfw and just for giggles: * squid leap to mind as a set of potential targets with wildly differing capabilities. In any such approach, there are plenty of times where a given source language expression and target language can produce "the target platform is TOO HEINOUSLY STOOPID to express that". However, it is also quite possible for a smart human to sit down, look at the source expression, and say "well, in fact, if I say these 27 ridiculous things, I can emulate that". The important point is to remember that all you really care about is effect. That vendors have differening ways of achieving effect is not of great concern until you are where the rubber hits the road. When the rubber does hit the road, the important thing becomes how to relate the platonic expression of effect to a given target's way of producing the effect. From network-automation-owner@greatcircle.com Sat May 21 09:00:42 2005 X-Original-To: network-automation@greatcircle.com Received: from mra02.ex.eclipse.net.uk (mra02.ex.eclipse.net.uk [212.104.129.89]) by mycroft.greatcircle.com (Postfix) with ESMTP id 8280C32C15B for ; Sat, 21 May 2005 08:00:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mra02.ex.eclipse.net.uk (Postfix) with ESMTP id 496474069F2 for ; Sat, 21 May 2005 16:00:02 +0100 (BST) Received: from mra02.ex.eclipse.net.uk ([127.0.0.1]) by localhost (mra02.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06853-01-27 for ; Sat, 21 May 2005 15:59:59 +0100 (BST) Received: from PackardBell.glomal.co.uk (unknown [82.152.149.139]) by mra02.ex.eclipse.net.uk (Postfix) with ESMTP id 256CE4069E1 for ; Sat, 21 May 2005 15:59:59 +0100 (BST) Message-Id: <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> X-Sender: ian.glossop@glomal.co.uk@mail.eclipse.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 21 May 2005 15:59:45 +0100 To: network-automation@greatcircle.com From: Ian Glossop Subject: Network Automation: An Architects View Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_133601968==_.ALT" X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk X-Archive-Number: 200505/14 X-Sequence-Number: 112 --=====================_133601968==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed My real problem with acls is also maintenance oriented. What I would really like is to take a written policy like "I want to never except netbios packets from the Internet", and convert that into a proper acl at any relevant security border point. That has historically been very hard. One usual approach to this seems to be to use some sort of meta-language to represent the policy, and to then generate the specific acl from that. This usually doesn't work real well, because the meta-language doesn't represent policy, but instead represents an abstraction of the underlying acl. In addition, the meta-language is usually as abtuse as the native acl language...which makes it just as hard to maintain in many cases. Perhaps an interesting approach would be to define a set of devices that represent borders between security zones, and then create a set of rules (i.e., policy) about the types of connections between the zones. Again, there's the problem of how to represent the policy in the correct acl language (which also varies considerably by platform, just to make it more fun.) In an ideal world, a change in the policy would be automatically pushed into a proper form for auto-configuration. Verification of the new config might be an interesting problem.... (My apologies if some of this has already been hashed out here...I'm still trying to find the time to read the archives of this list. :) -David Having lurked about on this list for a short while (and like David not really having the time to keep up let alone try to catch up), I have found the discussion quite interesting and was prompted by David's comments to describe my personal (somewhat utopian) ideal in the hope of stimulating yet more discussion. As an architect what I'm looking for is a vendor-independent, technology-independent, possibly pictorial, language with which to describe the architecture of solutions. This includes not only network topology, security zones, policies, boundary and core network devices (firewalls, routers, switches and load-balancers/content switches) etc as David suggests but also server machines, middleware (weblogic, MQ Series etc), databases, (capacity, perfomance and health) monitoring systems, application software instances and deployment systems. Maybe something like Data Centre Markup Language could be the starting point for this "Architecture Specification Markup Language" (ASML). I then want a similar, possibly related language with which to specify the technology selections that I make to implement the solution. Again it should be vendor-independent and technology independent (it would have to be by definition). Then I want a system that can bring together the architectural description with the technology selection and produce specific configuration information for the devices and software involved. So if I specify a certain network topology (and access control policies etc) and then choose to implement using Cisco routers and switches this system would derive the appropriate IOS configurations for each of the devices involved. Clearly no single vendor is going to produce such a system so it would have to be a modular approach with standardized (software) interfaces into which vendors could plug their components to derive the configurations for their devices (software or hosts/OS) from the vendor-neutral standard ASML. Furthermore, I want this system to maintain records of the architectures I specify and to provide the facility to compare a proposed new architecture against an existing (or old) architecture and work out what the differences are in terms of new devices/machines that have to added (or old ones that have to be removed) and configuration changes required - on network kit, servers, middleware, apps software etc. (and maybe even assign some costs to those changes) - in essence doing much of the 'bureacratic' part of an impact assessment. Finally I want this "architecture system" to interface with automated deployment and configuration tracking systems to deploy the derived configurations in a clean, safe, controlled manner and periodically compare the "in-the-field" configurations against those derived from the architecture reference description (and of course flag up differences or unauthorised changes). Obviously this is Utopian at the moment but products like Opsware and ThinkDynamic Orchestrator are moving in that direction in the server space. Network automation ought to move in the same direction. This is my personal "big picture" vision. Others may have different views .... ? Site=SiteA WANLink=toSiteB LANLink=toSwitchAlpha LANlink=toSwitchBeta Inbound=Disallow Outbound=Disallow Anybody write an awk, perl or XSLT script to translate this into a Cisco ACL ? Or a visual representation ? Regards, Ian. --=====================_133601968==_.ALT Content-Type: text/html; charset="us-ascii"
My real problem with acls is also maintenance oriented. What I would
really like is to take a written policy like "I want to never except
netbios packets from the Internet", and convert that into a proper acl
at any relevant security border point. That has historically been very
hard.
One usual approach to this seems to be to use some sort of
meta-language to represent the policy, and to then generate the
specific acl from that. This usually doesn't work real well, because
the meta-language doesn't represent policy, but instead represents an
abstraction of the underlying acl. In addition, the meta-language is
usually as abtuse as the native acl language...which makes it just as
hard to maintain in many cases.
Perhaps an interesting approach would be to define a set of devices
that represent borders between security zones, and then create a set of
rules (i.e., policy) about the types of connections between the zones.
Again, there's the problem of how to represent the policy in the
correct acl language (which also varies considerably by platform, just
to make it more fun.) In an ideal world, a change in the policy would
be automatically pushed into a proper form for auto-configuration.
Verification of the new config might be an interesting problem....
(My apologies if some of this has already been hashed out here...I'm
still trying to find the time to read the archives of this list. :)

-David

Having lurked about on this list for a short while (and like David not really having the time to keep up let alone try to catch up), I have found the discussion quite interesting and was prompted by David's comments to describe my personal (somewhat utopian) ideal in the hope of stimulating yet more discussion.
As an architect what I'm looking for is a vendor-independent, technology-independent, possibly pictorial, language with which to describe the architecture of solutions. This includes not only network topology, security zones, policies, boundary and core network devices (firewalls, routers, switches and load-balancers/content switches) etc as David suggests but also server machines, middleware (weblogic, MQ Series etc), databases, (capacity, perfomance and health) monitoring systems, application software instances and deployment systems. Maybe something like Data Centre Markup Language could be the starting point for this "Architecture Specification Markup Language" (ASML).

I then want a similar, possibly related language with which to specify the technology selections that I make to implement the solution. Again it should be vendor-independent and technology independent (it would have to be by definition).

Then I want a system that can bring together the architectural description with the technology selection and produce specific configuration information for the devices and software involved. So if I specify a certain network topology (and access control policies etc) and then choose to implement using Cisco routers and switches this system would derive the appropriate IOS configurations for each of the devices involved.
Clearly no single vendor is going to produce such a system so it would have to be a modular approach with standardized (software) interfaces into which vendors could plug their components to derive the configurations for their devices (software or hosts/OS) from the vendor-neutral standard ASML.

Furthermore, I want this system to maintain records of the architectures I specify and to provide the facility to compare a proposed new architecture against an existing (or old) architecture and work out what the differences are in terms of new devices/machines that have to added (or old ones that have to be removed) and configuration changes required - on network kit, servers, middleware, apps software etc. (and maybe even assign some costs to those changes) - in essence doing much of the 'bureacratic' part of an impact assessment.

Finally I want this "architecture system" to interface with automated deployment and configuration tracking systems to deploy the derived configurations in a clean, safe, controlled manner and periodically compare the "in-the-field" configurations against those derived from the architecture reference description (and of course flag up differences or unauthorised changes).

Obviously this is Utopian at the moment but products like Opsware and ThinkDynamic Orchestrator are moving in that direction in the server space. Network automation ought to move in the same direction.
This is my personal "big picture" vision. Others may have different views .... ?

<Security Policy>
  <Boundary Router>
    <Instance Router1>
      Site=SiteA
      <Interface Outbound1>
        WANLink=toSiteB
      </Interface>
      <Interface InsideLAN1>
        LANLink=toSwitchAlpha
      </Interface>
      <Interface InsideLAN2>
        LANlink=toSwitchBeta
      </Interface>
    </Instance>
    <ProtocolRules>
      <Protocol netbios>
        <Transmission>
          Inbound=Disallow
        Outbound=Disallow
       </Transmission>
      </Protocol netbios>
   </ProtocolRules>
  </Boundary Router>
</Security Policy>

Anybody write an awk, perl or XSLT script to translate this into a Cisco ACL ? Or a visual representation ?

Regards,
Ian.


--=====================_133601968==_.ALT-- From network-automation-owner@greatcircle.com Sat May 21 12:37:54 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 8BB2732C1A3 for ; Sat, 21 May 2005 12:37:52 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id E16F61939C; Sat, 21 May 2005 15:37:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17039.36357.794569.744848@perdition.linnaean.org> Date: Sat, 21 May 2005 15:37:41 -0400 To: Ian Glossop Cc: network-automation@greatcircle.com Subject: ACL compiler [was: Network Automation: An Architects View] In-Reply-To: <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> References: <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200505/15 X-Sequence-Number: 113 > As an architect what I'm looking for is a vendor-independent, > technology-independent, possibly pictorial, language with which to describe [...] > > I then want a similar, possibly related language with which to specify the [...] > Then I want a system that can bring together the architectural description [...] > Furthermore, I want this system to maintain records of the architectures I [...] > Finally I want this "architecture system" to interface with automated [...] > Obviously this is Utopian at the moment but products like Opsware and Well, yeah, it is, but how do we ever plan to get to utopia if we don't know what it should look like when we get there? You are asking for the solutions to Difficult computer science problems such that by the time you've got a good handle on any two of these problems and the relationship between them that you've mostly solved the hard computer science problems. Rather than offering my own ignorant views on the full extent of the horror you ask, I will steal some words from much smarter people than myself. Naively, they probably don't appear related to network automation, but I claim they are by the time you're asking for such high powered solutions. You can find the source of these words around http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-18.html#call_footnote_Temp_289 If the data types in our system can be naturally arranged in a tower, this greatly simplifies the problems of dealing with generic operations on different types, as we have seen. Unfortunately, this is usually not the case. Figure 2.26 illustrates a more complex arrangement of mixed types, this one showing relations among different types of geometric figures. We see that, in general, a type may have more than one subtype. Triangles and quadrilaterals, for instance, are both subtypes of polygons. In addition, a type may have more than one supertype. For example, an isosceles right triangle may be regarded either as an isosceles triangle or as a right triangle. This multiple-supertypes issue is particularly thorny, since it means that there is no unique way to ``raise'' a type in the hierarchy. Finding the ``correct'' supertype in which to apply an operation to an object may involve considerable searching through the entire type network on the part of a procedure such as apply-generic. Since there generally are multiple subtypes for a type, there is a similar problem in coercing a value ``down'' the type hierarchy. Dealing with large numbers of interrelated types while still preserving modularity in the design of large systems is very difficult, and is an area of much current research.(52) (52) This statement, which also appears in the first edition of this book, is just as true now as it was when we wrote it twelve years ago. Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call ``ontology'') seems intractably difficult. The main difference between the confusion that existed ten years ago and the confusion that exists now is that now a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages. For example, much of the complexity of object-oriented programming languages -- and the subtle and confusing differences among contemporary object-oriented languages -- centers on the treatment of generic operations on interrelated types. Our own discussion of computational objects in chapter 3 avoids these issues entirely. Readers familiar with object-oriented programming will notice that we have much to say in chapter 3 about local state, but we do not even mention ``classes'' or ``inheritance.'' In fact, we suspect that these problems cannot be adequately addressed in terms of computer-language design alone, without also drawing on work in knowledge representation and automated reasoning. You are perioulously close to a poorly understood abyss. To move a little closer to a subject at hand, if you want an ACL language, search for closure over the domain. Closure is the property operations have where they both operate on a type, and return that type. An example is SQL: select statements operate on tables (perhaps only 1), and return a table. This lends great expressiveness to the language at no cost other than designing the language correctly in the first place (the hard part). An overly high level language with closure over ACLs is specified approximately as follows: An ACL is a boolean valued function over a user specified "domain". This function is applied in a domain specific fashion to achieve an observable effect in the world over which the ACL applies. This specification leaves the problem of domain specification to the user, as it should if you ask me. David's high level statement is an ACL over a domain that is *different* from the domain of ACLs for IOS which is different yet again from the ACL domain of a netscreen. Each of these is a seperable ACL question. The biggest gotcha in here is getting the various specifications to speak the same language or otherwise be relatable to one another. The important part is to produce a model where, given enough remove, you can show that an acl the model produced does or does not exist, but you can't readily show which of your target platforms produced the effect that (dis)proves the presence of the ACL simply by the behavior of the ACL. There is some gotcha in this in that achieving this *may not be possible*. It may be the case that you can only approximate an effect you desire, and you can actually tell the difference between the implementations soley from the behavior of described effect. Such is life. Any notion of vendor independances suffers from such contradictions, because sometimes the vendors go out of there way to be different. If its important to you that vendors not look different, you will make some sacrifice sooner or later. I am not volunteering to write an ACL compiler (yet). I am working in a "simpler" domain whereby ACL compiler is easier to write as a result of working on this other domain. There is one property that all domains share, and that is evaluation. Evaluation is thusly promotable to a domain of domains concept. An ACL compiler of some sorts is a very good test tool to target, given this evaluation concept. It's "relatively simple" as these things go, but demonstrates many key configuration management problems. In the case of ACL compiler difficulties, it would be very helpful to me if the audience could come up with some concepts they really want their ACL compiler to express that will run into problems with vendor semantic mismatches. The more specific/concrete your examples of this are, the better I can think about what's really got to be said to smash them where we only get one swing of the hammer. From network-automation-owner@greatcircle.com Sun May 22 17:03:32 2005 X-Original-To: network-automation@greatcircle.com Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mycroft.greatcircle.com (Postfix) with ESMTP id EF57732C32B for ; Sun, 22 May 2005 17:03:31 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 70so3158293wra for ; Sun, 22 May 2005 17:03:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gvfCZWcjnn1dEj2gf8Y7GE7p4RAbwf79Qmsuyy0DpoCcQe3RoYIkTA/+UIAcSPJz2PUl7VDCGw/8ZAzv3ZVvV0eCHrLiQ0n11P5XNW3gkhyUepqTYyBF3JDZbANdruPoo76Cl7tkMqBqIbxid33htQooJWZhepq22BrqNfNWRHw= Received: by 10.54.23.26 with SMTP id 26mr3087035wrw; Sun, 22 May 2005 17:03:30 -0700 (PDT) Received: by 10.54.24.16 with HTTP; Sun, 22 May 2005 17:03:30 -0700 (PDT) Message-ID: Date: Sun, 22 May 2005 17:03:30 -0700 From: Lori Barfield Reply-To: Lori Barfield To: network-automation@greatcircle.com Subject: Re: ACL compiler [was: Network Automation: An Architects View] Cc: Ian Glossop , Daniel Hagerty In-Reply-To: <17039.36357.794569.744848@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <17039.36357.794569.744848@perdition.linnaean.org> X-Archive-Number: 200505/16 X-Sequence-Number: 114 well, i wouldn't limit the solution to an ACL compiler; i'd shoot=20 for the whole kit, where the security policy is defined with a strict=20 syntax, and that is interpreted to create baseline executable=20 configuration instructions for traffic-bearing devices at various=20 layers.=20=20 plus i'd want the interpreter to create baseline monitoring code=20 (for a unix-hosted scripting language). plus i'd want it to spit=20 out a documentation template for me so i could iterate and catch errors visually, the way people really do architecting.=20=20 because network devices interoperate to apply security policy,=20 just automating (say) cisco configurations won't catch the=20 common oversights that a top-down policy tool could fend off.=20 you'd need all the modules to interoperate intelligently. this is so doable you'd think someone *must* have started a=20 thing like this already. (perhaps at a university somewhere?) i'd pick python. anyone else interested? ...lori From network-automation-owner@greatcircle.com Mon May 23 03:27:49 2005 X-Original-To: network-automation@greatcircle.com Received: from mra04.ex.eclipse.net.uk (mra04.ex.eclipse.net.uk [212.104.129.139]) by mycroft.greatcircle.com (Postfix) with ESMTP id DFB5B32C325 for ; Mon, 23 May 2005 03:27:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id B7883133B08; Mon, 23 May 2005 11:34:07 +0100 (BST) Received: from mra04.ex.eclipse.net.uk ([127.0.0.1]) by localhost (mra04.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04871-01-21; Mon, 23 May 2005 11:34:07 +0100 (BST) Received: from PackardBell.glomal.co.uk (unknown [82.152.149.139]) by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id 14EA313381D; Mon, 23 May 2005 11:32:16 +0100 (BST) Message-Id: <5.1.0.14.0.20050523103126.02acaec0@mail.eclipse.co.uk> X-Sender: ian.glossop@glomal.co.uk@mail.eclipse.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 May 2005 11:31:58 +0100 To: network-automation@greatcircle.com From: Ian Glossop Subject: Re: ACL compiler [was: Network Automation: An Architects View] Cc: Daniel Hagerty , Lori Barfield In-Reply-To: References: <17039.36357.794569.744848@perdition.linnaean.org> <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <17039.36357.794569.744848@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk X-Archive-Number: 200505/17 X-Sequence-Number: 115 At 17:03 22/05/2005 -0700, Lori Barfield wrote: >I'd shoot >for the whole kit, where the security policy is defined with a strict >syntax, and that is interpreted to create baseline executable >configuration instructions for traffic-bearing devices at various >layers. Right. That "strict syntax" is what I dubbed ASML. However, it would need to be extensible to accomodate new devices or new features as the technology developed. Hence, an XML-based approach. I'd envisage the interepreter as a module that gets called in to do the job for the specific technology selected (as specified in the architecture technology selections). This may itself be modular and call in an ACL compiler as required. What I'm really suggesting is a community-based standardisation effort to try to define in detail the "strict syntax". >plus i'd want the interpreter to create baseline monitoring code >(for a unix-hosted scripting language). I'd envisage that the interpreter would save the configs it derived in a standardised filesystem layout (what ITIL might call a Configuration Management DataBase) and call out to the deployment subsystem to supply the config to the device (maybe in response to a TFTP or HTTP(S) request from the router or switch or whatever). I say filesystem because I think text files would be a) easier to work with b) easier to implement. In due course it could actually be a conventional (Relational) Database. I'd envisage "monitoring" to comprise pulling back the "in-use" config using TFTP or HTTP and a simple comparison with the stored config. >plus i'd want it to spit >out a documentation template for me so i could iterate and >catch errors visually, the way people really do architecting. Right again. The business of "architecting" is really about arguing over a picture. Ideally I'd want to derive the ASML from the picture - because I and the other architects I know tend to think in pictures - but I think this might be a little ambitious. Next best thing would be to spit out a (XML) document (possibly containing a picture) to argue over. (And anyway, if I'm leading an architecture team on a big solution, I'm going to insist on this documentation as a minimum.) >because network devices interoperate to apply security policy, >just automating (say) cisco configurations won't catch the >common oversights that a top-down policy tool could fend off. >you'd need all the modules to interoperate intelligently. I think there is probably a trade-off between the amount of intelligence built into the modules and the amount of intelligence expected of the architect (and before I was one I had various roles where I had to (try to) implement other people's designs - so I am very well aware these can vary enormously in quality). To make implementation of such a system easier I would start by assuming the modules were not all that intelligent - but then assume they would get smarter over time. >this is so doable you'd think someone *must* have started a >thing like this already. (perhaps at a university somewhere?) You would have thought so, wouldn't you. >i'd pick python. I don't care. I'd expect a mix of languages/tools - whatever is best to get the job done. Unfortunately, while I'm a very good systems analyst (not S/W analyst or A/P) and architect, I'm not really a very good programmer. So, though not totally out of the question, it is better for my contribution to be restricted to discussing standards / designs / functionality. Regards, Ian. From network-automation-owner@greatcircle.com Mon May 23 05:18:00 2005 X-Original-To: network-automation@greatcircle.com Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mycroft.greatcircle.com (Postfix) with ESMTP id 4896732C15E for ; Mon, 23 May 2005 05:17:58 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 70so3423678wra for ; Mon, 23 May 2005 05:17:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WnkjGq39WGVmL8977FPNb2/PH/EenEFv7AEMAZYymDqlksz80YeDw7rYKkLE0iQQaWIbsw8T6yW9QSBSYlRSrnXRj1ul0VaQP9G8NIJQ3m9b/Ueljw/HzcdCkqTM879iGrr0Mc28v6zM5K4nNWj4zIVNaVUu8nKT/j0Q0/pakyw= Received: by 10.54.10.61 with SMTP id 61mr3445063wrj; Mon, 23 May 2005 05:17:58 -0700 (PDT) Received: by 10.54.24.16 with HTTP; Mon, 23 May 2005 05:17:58 -0700 (PDT) Message-ID: Date: Mon, 23 May 2005 05:17:58 -0700 From: Lori Barfield Reply-To: Lori Barfield To: Ian Glossop Subject: Re: ACL compiler [was: Network Automation: An Architects View] Cc: network-automation@greatcircle.com, Daniel Hagerty In-Reply-To: <5.1.0.14.0.20050523103126.02acaec0@mail.eclipse.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <17039.36357.794569.744848@perdition.linnaean.org> <5.1.0.14.0.20050523103126.02acaec0@mail.eclipse.co.uk> X-Archive-Number: 200505/18 X-Sequence-Number: 116 thanks for the followup, ian. well thought-out. one clarification i'd like to make: On 5/23/05, Ian Glossop wrote: > At 17:03 22/05/2005 -0700, Lori Barfield wrote: > >plus i'd want the interpreter to create baseline monitoring code > >(for a unix-hosted scripting language). >=20 > I'd envisage that the interpreter would save the configs it derived in a > standardised filesystem layout (what ITIL might call a Configuration > Management DataBase) and call out to the deployment subsystem to supply t= he > config to the device (maybe in response to a TFTP or HTTP(S) request from > the router or switch or whatever). I say filesystem because I think text > files would be a) easier to work with b) easier to implement. In due cour= se > it could actually be a conventional (Relational) Database. I'd envisage > "monitoring" to comprise pulling back the "in-use" config using TFTP or > HTTP and a simple comparison with the stored config. checking configurations is so critical, i was taking it for granted and actually wasn't referring to that when i said "monitoring." glad you=20 expanded on that.=20=20 i was thinking of how packet filtering and real-time *traffic* monitoring= =20 tasks go hand in hand. applying a configuration rule manually often=20 means duplicating the work on your monitoring system. (if you have=20 time to actually set up and maintain dedicated traffic monitors.) but once you have a set of rules in a database (text files, RDB, whatever)=20 that defines traffic which isn't supposed to occur, you can write a=20 module that will create real-time monitors so you don't have to try to remember to watch for every possible configuration failure you've=20 encountered. i was picturing something really generic, like code that=20 created unixy script snippets. but of course you could make it write=20 IDS instructions instead, or otherwise interface with other real-time=20 monitoring tools if you've gotten fancy. or maybe this is a dumb idea. here is a for instance: for instance, we all agree that traffic from private networks shouldn't=20 spill out of border routers. some folks maybe even block those outgoing packets even if we're positive they would never get that far=20 to start with. :) but i'll bet few admins go out of their way to set up=20 alarm triggers elsewhere that look for leaks, because this failure=20 doesn't usually break anything operationally. eventually you'll catch=20 the goof and fix it. but if you had a rule that said private network=20 packets weren't supposed to leave particular vlans or switches, a=20 tool in the suite could automatically generate script snippets for a chosen checkpoint that would send out alerts if any such packets=20 were found. the goal here is just to reduce the work and increase=20 the thoroughness with creating a baseline real-time monitoring=20 system. ...lori From network-automation-owner@greatcircle.com Mon May 23 07:43:59 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id AF26D32C2D9 for ; Mon, 23 May 2005 07:43:57 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 038D6193A1; Mon, 23 May 2005 10:43:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17041.60458.892333.512810@perdition.linnaean.org> Date: Mon, 23 May 2005 10:43:54 -0400 To: Ian Glossop Cc: network-automation@greatcircle.com, Lori Barfield Subject: Re: ACL compiler [was: Network Automation: An Architects View] In-Reply-To: <5.1.0.14.0.20050523103126.02acaec0@mail.eclipse.co.uk> References: <17039.36357.794569.744848@perdition.linnaean.org> <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <5.1.0.14.0.20050523103126.02acaec0@mail.eclipse.co.uk> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200505/19 X-Sequence-Number: 117 Before we try to make a big picture work, I'd like to see some small pictures work. There are often devils in the details. Many people have noted that ACL compiler doesn't seem to exist in a useful fashion. Its appears to be faster to produce something quick and dirty that solves your problem today, then it is to produce something that solves the general problem space once and for all. An ACL compiler has several annoying problems lurking within it, like the wide semantic distance in between different implementations. I picked it out of a hat as something supposedly tractable that will involve real effort to create. Done properly, any such compiler can be readily reused in a bigger picture, up to and including having its source text generated by the big picture. One of my copious free time projects will involve taking apart a netscreen firewall configuration for work; I imagine by the time I'm done with that, I'll have a good idea how to write a compiler that would target it. Writing the compiler that would target it, as well as some wildly different platforms (linux iptables, ipf, pf, cisco ios, cisco pix have been played with before) would no doubt involve more work. Specific, concrete examples of "how would you do..." between two different ACL implementations would be very helpful. As I said earlier, I'm not volunteering. Its a useful problem area to exercise on. From network-automation-owner@greatcircle.com Mon May 23 08:17:09 2005 X-Original-To: network-automation@greatcircle.com Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mycroft.greatcircle.com (Postfix) with ESMTP id E357732C1D5 for ; Mon, 23 May 2005 08:17:07 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 70so3536315wra for ; Mon, 23 May 2005 08:17:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rsI+geUT66vXnWFPVM9EQIEQLk1mE0vxbYrNOUmqUeggzHaTWmvgMM2YDctuiYtDedLQz/YD68lxjkWy1pQEws5EJoe54WNVUxzB0oVNp68GuhbHvheX+94nO1usc7cSKDc6qfsIVPOXoCS7t/vunKp/YdzWHk3v5t6N1ghAGdI= Received: by 10.54.76.12 with SMTP id y12mr3639780wra; Mon, 23 May 2005 08:17:06 -0700 (PDT) Received: by 10.54.24.16 with HTTP; Mon, 23 May 2005 08:17:06 -0700 (PDT) Message-ID: Date: Mon, 23 May 2005 08:17:06 -0700 From: Lori Barfield Reply-To: Lori Barfield To: Daniel Hagerty Subject: Re: ACL compiler [was: Network Automation: An Architects View] Cc: Ian Glossop , network-automation@greatcircle.com In-Reply-To: <17041.60458.892333.512810@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17039.36357.794569.744848@perdition.linnaean.org> <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <5.1.0.14.0.20050523103126.02acaec0@mail.eclipse.co.uk> <17041.60458.892333.512810@perdition.linnaean.org> X-Archive-Number: 200505/20 X-Sequence-Number: 118 On 5/23/05, Daniel Hagerty wrote: > Before we try to make a big picture work, I'd like to see some > small pictures work. There are often devils in the details. Many > people have noted that ACL compiler doesn't seem to exist in a useful > fashion. Its appears to be faster to produce something quick and > dirty that solves your problem today, then it is to produce something > that solves the general problem space once and for all. >=20 > An ACL compiler has several annoying problems lurking within it, > like the wide semantic distance in between different implementations. > I picked it out of a hat as something supposedly tractable that will > involve real effort to create. Done properly, any such compiler can > be readily reused in a bigger picture, up to and including having its > source text generated by the big picture. >=20 > One of my copious free time projects will involve taking apart a > netscreen firewall configuration for work; I imagine by the time I'm > done with that, I'll have a good idea how to write a compiler that > would target it. Writing the compiler that would target it, as well > as some wildly different platforms (linux iptables, ipf, pf, cisco > ios, cisco pix have been played with before) would no doubt involve > more work. >=20 >=20 > Specific, concrete examples of "how would you do..." between two > different ACL implementations would be very helpful. As I said > earlier, I'm not volunteering. Its a useful problem area to exercise > on. i understand what you are saying about trying to attack things in addressible bites, but there are some things that still need to be decided ahead of time or interoperability will be precluded by a lack of design. for instance, i disagree about a straightforward ACL compiler being very useful in the larger picture if it's only written to just spit out a set instructions made for a particular vendor platform. you've got to include at least two other higher=20 concepts- workgroups or departments or sites plus levels of=20 accessibility- in order to produce something that's maintainable. just mho. ...lori From network-automation-owner@greatcircle.com Mon May 23 08:29:02 2005 X-Original-To: network-automation@greatcircle.com Received: from bluebox.CS.Princeton.EDU (bluebox.CS.Princeton.EDU [128.112.136.38]) by mycroft.greatcircle.com (Postfix) with ESMTP id 3F1FC32C1D5 for ; Mon, 23 May 2005 08:28:56 -0700 (PDT) Received: from Rexford (rexford.CS.Princeton.EDU [128.112.95.67]) (authenticated bits=0) by bluebox.CS.Princeton.EDU (8.12.11/8.12.11) with ESMTP id j4NFSrFm011908 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 May 2005 11:28:54 -0400 (EDT) Message-Id: <200505231528.j4NFSrFm011908@bluebox.CS.Princeton.EDU> From: "Jennifer Rexford" To: "'Daniel Hagerty'" Cc: Subject: Re: ACL compiler [was: Network Automation: An Architects View] Date: Mon, 23 May 2005 11:30:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <17041.60458.892333.512810@perdition.linnaean.org> Thread-index: AcVfpeeddL9CdJW9QnGJ4U5rIDHt7AABZe3Q X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=-1 adultscore=0 adjust=0 reason=safe engine=3.0.0-05052000 definitions=3.0.0-05052102 X-Archive-Number: 200505/21 X-Sequence-Number: 119 Daniel, One abstraction that might be useful is the idea of a "reachability matrix" -- what end hosts and applications/services should be able to talk to each other. This gets at a network-wide view of reachability control, rather than the details of which ACLs are installed on each interface and using what commands. Then, the decision of which ACLs to install (and where) could be compiled from that high-level specification. Otherwise, it is easy to have an ACL configuration that works just fine until a failure occurs, directing packets on a different path whether they encounter a different set of ACLs. We've worked out one simple example in Section 2.1 of http://www.cs.princeton.edu/~jrex/papers/4D-report.pdf that might be of interest. More broadly, I think it would be great to have an integrated view of the effects of ACLs, routing, and NATs on who can communicate with whom. -- Jen -----Original Message----- From: network-automation-owner@greatcircle.com [mailto:network-automation-owner@greatcircle.com] On Behalf Of Daniel Hagerty Sent: Monday, May 23, 2005 9:44 AM To: Ian Glossop Cc: network-automation@greatcircle.com; Lori Barfield Subject: Re: ACL compiler [was: Network Automation: An Architects View] Before we try to make a big picture work, I'd like to see some small pictures work. There are often devils in the details. Many people have noted that ACL compiler doesn't seem to exist in a useful fashion. Its appears to be faster to produce something quick and dirty that solves your problem today, then it is to produce something that solves the general problem space once and for all. An ACL compiler has several annoying problems lurking within it, like the wide semantic distance in between different implementations. I picked it out of a hat as something supposedly tractable that will involve real effort to create. Done properly, any such compiler can be readily reused in a bigger picture, up to and including having its source text generated by the big picture. One of my copious free time projects will involve taking apart a netscreen firewall configuration for work; I imagine by the time I'm done with that, I'll have a good idea how to write a compiler that would target it. Writing the compiler that would target it, as well as some wildly different platforms (linux iptables, ipf, pf, cisco ios, cisco pix have been played with before) would no doubt involve more work. Specific, concrete examples of "how would you do..." between two different ACL implementations would be very helpful. As I said earlier, I'm not volunteering. Its a useful problem area to exercise on. From network-automation-owner@greatcircle.com Mon May 23 09:18:40 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id B0A6132C18C for ; Mon, 23 May 2005 09:15:54 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 1B18B193A0; Mon, 23 May 2005 12:15:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17042.435.13943.754807@perdition.linnaean.org> Date: Mon, 23 May 2005 12:15:47 -0400 To: Lori Barfield Cc: Ian Glossop , network-automation@greatcircle.com Subject: Re: ACL compiler [was: Network Automation: An Architects View] In-Reply-To: References: <17039.36357.794569.744848@perdition.linnaean.org> <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <5.1.0.14.0.20050523103126.02acaec0@mail.eclipse.co.uk> <17041.60458.892333.512810@perdition.linnaean.org> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200505/22 X-Sequence-Number: 120 > i understand what you are saying about trying to attack things > in addressible bites, but there are some things that still need > to be decided ahead of time or interoperability will be precluded > by a lack of design. for instance, i disagree about a straightforward > ACL compiler being very useful in the larger picture if it's only > written to just spit out a set instructions made for a particular > vendor platform. you've got to include at least two other higher I thought I made it rather clear that any such approach is only useful if you address it where the platonic ideal of ACL is seperated from any given vendors implementation of it. > concepts- workgroups or departments or sites plus levels of > accessibility- in order to produce something that's maintainable. See the quote I opened this up with. As you increase the scope of what you attack, you leave yourself more room to fall into the turing trap. Workgroups, departments, sites are all words that are very open to interpretation. We can't even come to concrete agreement on a simple predicate for all we do, like "configure". From network-automation-owner@greatcircle.com Mon May 23 09:33:47 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 5007432C219 for ; Mon, 23 May 2005 09:33:46 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 99B7D193A0; Mon, 23 May 2005 12:33:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17042.1513.533013.135583@perdition.linnaean.org> Date: Mon, 23 May 2005 12:33:45 -0400 To: "Jennifer Rexford" Cc: Subject: Re: ACL compiler [was: Network Automation: An Architects View] In-Reply-To: <200505231528.j4NFSrFm011908@bluebox.CS.Princeton.EDU> References: <17041.60458.892333.512810@perdition.linnaean.org> <200505231528.j4NFSrFm011908@bluebox.CS.Princeton.EDU> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200505/23 X-Sequence-Number: 121 > One abstraction that might be useful is the idea of a "reachability matrix" > -- what end hosts and applications/services should be able to talk to each > other. This gets at a network-wide view of reachability control, rather My own naive view sounds something like this; express the graph that is the network, and express what is and is not doable within the graph because of the security policy. Derive the ACLs from the specification of the network. As you alude to, other objects within the network drive who can communicate with whom and are just as important to specify. > of ACLs. We've worked out one simple example in Section 2.1 of > > http://www.cs.princeton.edu/~jrex/papers/4D-report.pdf > > that might be of interest. More broadly, I think it would be great to have > an integrated view of the effects of ACLs, routing, and NATs on who can > communicate with whom. Sounds delightful, exactly the kind of concrete I want to hear about. Thanks! Longer term, one of the things I'm interested in/concerned about with any kind of network configuration automation is that it can express the brain surgery on self problem: without really good (preferably proovably good) out of band management, a network configuration manager can trivially destroy the network's ability to communicate with itself. Worse, it can be directed to do such destruction in an oblique way by its user: how is a network configuration tool any good at all if I can *insist* that I know something it doesn't, and please produce a configuration that appears completely irrational to the poor little computer program, and no, I don't have time to prove its rationality to the tool? This sort of problem comes down to what prompted Steve Traugott to write the Turing equivelance paper. While I don't agree with 100% of the upshot there, the point remains that deep computer science lurks within this seemingly simple "perfectly doable". From network-automation-owner@greatcircle.com Mon May 23 10:21:20 2005 X-Original-To: network-automation@greatcircle.com Received: from central.redice.net (central.redice.net [62.69.77.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id F231B32C1D5 for ; Mon, 23 May 2005 10:21:18 -0700 (PDT) Received: from central.redice.net (central.redice.net [127.0.0.1]) by central.redice.net (8.12.8/8.12.5) with ESMTP id j4NHRapK021585; Mon, 23 May 2005 18:27:36 +0100 Received: (from matt@localhost) by central.redice.net (8.12.8/8.12.8/Submit) id j4NHRZ77021583; Mon, 23 May 2005 18:27:35 +0100 Date: Mon, 23 May 2005 18:27:35 +0100 From: Matt S Trout To: Lori Barfield Cc: network-automation@greatcircle.com, Ian Glossop , Daniel Hagerty Subject: Re: ACL compiler [was: Network Automation: An Architects View] Message-ID: <20050523172735.GC21523@central.redice.net> References: <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <17039.36357.794569.744848@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Archive-Number: 200505/24 X-Sequence-Number: 122 On Sun, May 22, 2005 at 05:03:30PM -0700, Lori Barfield wrote: > well, i wouldn't limit the solution to an ACL compiler; i'd shoot > for the whole kit, where the security policy is defined with a strict > syntax, and that is interpreted to create baseline executable > configuration instructions for traffic-bearing devices at various > layers. > > plus i'd want the interpreter to create baseline monitoring code > (for a unix-hosted scripting language). plus i'd want it to spit > out a documentation template for me so i could iterate and > catch errors visually, the way people really do architecting. > > because network devices interoperate to apply security policy, > just automating (say) cisco configurations won't catch the > common oversights that a top-down policy tool could fend off. > you'd need all the modules to interoperate intelligently. > > this is so doable you'd think someone *must* have started a > thing like this already. (perhaps at a university somewhere?) > > i'd pick python. I didn't - but I'm still working towards a system that can host such a beast. > anyone else interested? have a look at bast-EXP in http://trout.me.uk/perl/ - it's my first cut at an XML + XSLT-based system that should be able to do arbitrary config generation. The basic unit is a functional transform on URL-space, with chunks of URL-space mapped to whatever you want (files, databases, devices ...). There's a bast-discuss list @sourceforge.net already set up, and I'll be getting a public version control repo and a .sf.net website up within the next week; I'm a little constrained for time due to also having to do stuff for clients, and I've been knocked out by a cold for the last week - so please be patient. -- Matt S Trout Website: http://www.shadowcatsystems.co.uk Technical Director E-mail: mst (at) shadowcatsystems.co.uk Shadowcat Systems Ltd. From network-automation-owner@greatcircle.com Mon May 23 17:25:17 2005 X-Original-To: network-automation@greatcircle.com Received: from mail1.optus.com.au (mail1.optus.com.au [203.13.126.129]) by mycroft.greatcircle.com (Postfix) with ESMTP id 0B3B432C2F7 for ; Mon, 23 May 2005 17:25:15 -0700 (PDT) Received: from chow2ke002.optus.com.au ([161.43.32.103]) by mail1.optus.com.au with InterScan Messaging Security Suite; Tue, 24 May 2005 10:25:04 +1000 Received: from shqw2ke001.optus.com.au ([10.17.224.13]) by chow2ke002.optus.com.au with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 May 2005 10:25:03 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: ACL compiler [was: Network Automation: An Architects View] Date: Tue, 24 May 2005 10:25:05 +1000 Message-ID: <799B0CDA650143429C5EA103965B59F82C2842@shqw2ke001.optus.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACL compiler [was: Network Automation: An Architects View] thread-index: AcVfgzT0Muyc1m9CSP2VodOMAnou3wAcpS4Q From: "Francis Liu" To: X-OriginalArrivalTime: 24 May 2005 00:25:03.0982 (UTC) FILETIME=[07A630E0:01C55FF7] X-Archive-Number: 200505/25 X-Sequence-Number: 123 > At 17:03 22/05/2005 -0700, Lori Barfield wrote: >=20 > What I'm really suggesting is a community-based=20 > standardisation effort to try to define in detail the "strict syntax". I think this is a killer. I think the problem is too large, too apparently intractable for a community project. This sounds like something that the IETF (or a large enough vendor) would have a whole team working on. There may be difficulties in negotiating with vendors to provide a more-or-less static interface to the their systems. There should be some level of "official" support, otherwise the various vendors may intentionally break compatibility with this config tool. (There are many reasons why they might do this.) > I'd envisage that the interpreter would save the configs it=20 > derived in a standardised filesystem layout (what ITIL might call a Configuration=20 > Management DataBase) and call out to the deployment subsystem to supply the ... As you say, you're not a programmer, so don't worry about the implementation, it'll be taken care of by someone doing the coding. The issues Daniel Hagerty has identified need some resolution first. I think it's excellent that we've produced a wishlist. Now we need some money and time thrown at intelligent types to produce a workable idea that the business/community types can code and develop. I wonder if anyone besides Daniel is actively analysing and thinking about this issue from a hard comsci perspective (turing, completeness, etc). Regards, Francis From network-automation-owner@greatcircle.com Tue May 24 04:52:48 2005 X-Original-To: network-automation@greatcircle.com Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mycroft.greatcircle.com (Postfix) with ESMTP id 4847F32C1F9 for ; Tue, 24 May 2005 04:52:45 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 70so4203139wra for ; Tue, 24 May 2005 04:52:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Jxq8lO3Fbk/uNZYq+fw/1oDv19wES47WaOCMkhlsasKI+9MSavNnSEeRn7lpRwzEdOhpG/4imAqOHxR13xZ75ZKc3LcAS1Emf1rfYE5mJWLs1Mcn8xlawxHNRebh5QSCRsmtRtb1hb3oqSpomWK4L/XdkZSlYxVP2EtO6LkI6hk= Received: by 10.54.36.60 with SMTP id j60mr317860wrj; Tue, 24 May 2005 04:52:45 -0700 (PDT) Received: by 10.54.24.16 with HTTP; Tue, 24 May 2005 04:52:45 -0700 (PDT) Message-ID: Date: Tue, 24 May 2005 04:52:45 -0700 From: Lori Barfield Reply-To: Lori Barfield To: Francis Liu Subject: Re: ACL compiler [was: Network Automation: An Architects View] Cc: network-automation@greatcircle.com In-Reply-To: <799B0CDA650143429C5EA103965B59F82C2842@shqw2ke001.optus.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <799B0CDA650143429C5EA103965B59F82C2842@shqw2ke001.optus.com.au> X-Archive-Number: 200505/26 X-Sequence-Number: 124 actually, those quotes are inaccurately attributed to me, francis. those are Ian Glossop's good suggestions. :) one thing i will say, though. having been both a programmer=20 and system administrator for many years, i understand how=20 an implementation can limit the scope of the solution. it's not just an automatic thing "taken care of by someone doing=20 the coding." so let's continue to develop a wish list, but i'd=20 enjoy seeing implementation suggestions (and experiences from existing projects) as well. we don't necessarily have to wait for money to get an idea out of the theoretical. let's see what it takes to solve first. ...lori On 5/23/05, Francis Liu wrote: > > At 17:03 22/05/2005 -0700, Lori Barfield wrote: > > > > What I'm really suggesting is a community-based > > standardisation effort to try to define in detail the "strict syntax". >=20 > I think this is a killer. I think the problem is too large, too > apparently intractable for a community project. This sounds like > something that the IETF (or a large enough vendor) would have a whole > team working on. There may be difficulties in negotiating with vendors > to provide a more-or-less static interface to the their systems. >=20 > There should be some level of "official" support, otherwise the various > vendors may intentionally break compatibility with this config tool. > (There are many reasons why they might do this.) >=20 > > I'd envisage that the interpreter would save the configs it > > derived in a standardised filesystem layout (what ITIL might call a > Configuration > > Management DataBase) and call out to the deployment subsystem to > supply the ... >=20 > As you say, you're not a programmer, so don't worry about the > implementation, it'll be taken care of by someone doing the coding. The > issues Daniel Hagerty has identified need some resolution first. >=20 > I think it's excellent that we've produced a wishlist. Now we need some > money and time thrown at intelligent types to produce a workable idea > that the business/community types can code and develop. >=20 > I wonder if anyone besides Daniel is actively analysing and thinking > about this issue from a hard comsci perspective (turing, completeness, > etc). >=20 > Regards, > Francis > From network-automation-owner@greatcircle.com Tue May 24 08:58:47 2005 X-Original-To: network-automation@greatcircle.com Received: from mail.reptiles.org (mail.reptiles.org [198.96.119.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id 8B6CC32C1B4 for ; Tue, 24 May 2005 08:58:46 -0700 (PDT) Received: from mail.reptiles.org([198.96.119.1] port=4401) (1909 bytes) by mail.reptiles.org([198.96.119.1] port=25) via TCP with esmtp (sender: ) id for ; (dest:remote)(R=bind_hosts)(T=inet_zone_bind_smtp) Tue, 24 May 2005 11:58:37 -0400 (EDT) (Smail-3.2.0.118 2004-May-31 #3 built 2004-Oct-14) Date: Tue, 24 May 2005 11:58:30 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@skink.reptiles.org Reply-To: Cat Okita To: Lori Barfield Cc: network-automation@greatcircle.com, Ian Glossop , Daniel Hagerty Subject: Re: ACL compiler [was: Network Automation: An Architects View] In-Reply-To: Message-ID: <20050524115708.E40415@skink.reptiles.org> References: <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <17039.36357.794569.744848@perdition.linnaean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Archive-Number: 200505/27 X-Sequence-Number: 125 On Sun, 22 May 2005, Lori Barfield wrote: > well, i wouldn't limit the solution to an ACL compiler; i'd shoot > for the whole kit, where the security policy is defined with a strict > syntax, and that is interpreted to create baseline executable > configuration instructions for traffic-bearing devices at various > layers. Heh. I floated that idea by on firewall-wizards a while back, and it's really not at all a trivial problem or an easy solution. Each device and vendor uses slightly different syntax, and producing an agreeable meta-language is a right pain in the keister. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From network-automation-owner@greatcircle.com Tue May 24 09:39:39 2005 X-Original-To: network-automation@greatcircle.com Received: from gregor.com (pine.he.net [216.218.254.226]) by mycroft.greatcircle.com (Postfix) with SMTP id 1BFE232C359 for ; Tue, 24 May 2005 09:25:56 -0700 (PDT) Received: from IPv6:::1 ([127.0.0.1]) by gregor.com for ; Tue, 24 May 2005 09:40:53 -0700 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <20050524115708.E40415@skink.reptiles.org> References: <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <17039.36357.794569.744848@perdition.linnaean.org> <20050524115708.E40415@skink.reptiles.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66b6f3369bde6fa64632f383d2bc4500@gregor.com> Content-Transfer-Encoding: 7bit From: DJ Gregor Subject: Re: ACL compiler [was: Network Automation: An Architects View] Date: Tue, 24 May 2005 12:25:54 -0400 To: network-automation@greatcircle.com X-Mailer: Apple Mail (2.622) X-Archive-Number: 200505/28 X-Sequence-Number: 126 In terms of ACL compilers, has anyone looked at Firewall Builder? It looks to have a general XML format that defines the policy (although at a low-level, in terms of ports and devices), along with translators from the XML format into implementation-specific configuration statements. http://www.fwbuilder.org/ I've also seen the same thing done in a commercial product where not only the firewall configuration, but the entire device configuration was specified in an XML language that was translated to operating system-specific configurations (for multiple OSes, even). The XML configurations were per-device, not per-network, however. - djg On May 24, 2005, at 11:58 AM, Cat Okita wrote: > On Sun, 22 May 2005, Lori Barfield wrote: >> well, i wouldn't limit the solution to an ACL compiler; i'd shoot >> for the whole kit, where the security policy is defined with a strict >> syntax, and that is interpreted to create baseline executable >> configuration instructions for traffic-bearing devices at various >> layers. > > Heh. I floated that idea by on firewall-wizards a while back, and it's > really not at all a trivial problem or an easy solution. > > Each device and vendor uses slightly different syntax, and producing > an agreeable meta-language is a right pain in the keister. > > cheers! > ======================================================================= > === > "A cat spends her life conflicted between a deep, passionate and > profound > desire for fish and an equally deep, passionate and profound desire to > avoid getting wet. This is the defining metaphor of my life right > now." > From network-automation-owner@greatcircle.com Tue May 24 11:07:27 2005 X-Original-To: network-automation@greatcircle.com Received: from streamxpress.net (s113.n45.vds2000.com [66.84.45.113]) by mycroft.greatcircle.com (Postfix) with ESMTP id 7CAF832C1A0 for ; Tue, 24 May 2005 11:07:25 -0700 (PDT) Received: from [192.168.1.100] (adsl-69-234-181-41.dsl.irvnca.pacbell.net [69.234.181.41]) (authenticated) by streamxpress.net (8.11.6/8.11.6) with ESMTP id j4OI7Jc02656; Tue, 24 May 2005 14:07:19 -0400 Subject: Re: ACL compiler [was: Network Automation: An Architects View] From: Kon Wilms To: DJ Gregor Cc: network-automation@greatcircle.com In-Reply-To: <66b6f3369bde6fa64632f383d2bc4500@gregor.com> References: <5.1.0.14.0.20050521155048.025ab230@mail.eclipse.co.uk> <17039.36357.794569.744848@perdition.linnaean.org> <20050524115708.E40415@skink.reptiles.org> <66b6f3369bde6fa64632f383d2bc4500@gregor.com> Content-Type: text/plain Date: Tue, 24 May 2005 11:07:17 -0700 Message-Id: <1116958037.3265.144.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Archive-Number: 200505/29 X-Sequence-Number: 127 On Tue, 2005-05-24 at 12:25 -0400, DJ Gregor wrote: > I've also seen the same thing done in a commercial product where not > only the firewall configuration, but the entire device configuration > was specified in an XML language that was translated to operating > system-specific configurations (for multiple OSes, even). The XML > configurations were per-device, not per-network, however. We use this kind of approach on our embedded receivers. The entire configuration of the receiver (they run embedded linux) from the network addresses down to the software and daemons is ruled by a configuration daemon that uses a pseudo-xml structured file to retrieve settings. The delivery of these configurations are done to targeted devices, which may be a single device or a group of devices (a group is used interchangeably). Configuration data can also update the entire box (new firmware and configuration) or only a subset of sections (all firewall configuration files, or just the ip address). Using the group IDs with masking and conflict management at the management system you can do per device and per network configurations. Cheers Kon