Return-Path: X-Original-To: homesec-dt@core3.amsl.com Delivered-To: homesec-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607EE3A6BE6 for ; Tue, 23 Mar 2010 06:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.032 X-Spam-Level: **** X-Spam-Status: No, score=4.032 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDxiMnf8RiTB for ; Tue, 23 Mar 2010 06:49:22 -0700 (PDT) Received: from hiltonsmtp.worldspice.net (hiltonsmtp.worldspice.net [216.37.94.58]) by core3.amsl.com (Postfix) with ESMTP id 133B13A6B14 for ; Tue, 23 Mar 2010 06:49:13 -0700 (PDT) Received: (qmail 5761 invoked by uid 0); 23 Mar 2010 13:49:29 -0000 Received: by simscan 1.4.0 ppid: 5564, pid: 5719, t: 1.1190s scanners: clamav: 0.94.1/m:50/d:9101 spam: 3.2.5 Received: from unknown (HELO HDC00027112) (lee@asgard.org@207.88.181.2) by hiltoncluster01.worldspice.net with ESMTPA; 23 Mar 2010 13:49:28 -0000 From: "Lee Howard" To: "'Mark Townsley'" , References: In-Reply-To: Date: Tue, 23 Mar 2010 06:49:18 -0700 Message-ID: <000b01caca8f$a5891900$f09b4b00$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01CACA54.F92A4100" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrFFF/7LVWcn1wnSEGkcnyyI8Zj6QFCxOAQ Content-Language: en-us X-Mailman-Approved-At: Tue, 23 Mar 2010 09:55:34 -0700 Subject: Re: [Homesec-dt] IPv6 Advanced Security... X-BeenThere: homesec-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: 'Advanced' Home Gateway Security Design Team List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 13:49:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01CACA54.F92A4100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Complete silence. . . Let me say where I am: I am very interested in the concepts outlines in advanced-security, but I'm not convinced that an IPS is a good replacement for a firewall. Host OSes aren't secure enough yet. I think simple-security ("deny any" as default) is the right approach right now. After there is some live experience with advanced-security (i.e., using an IPS instead of a stateful firewall), and until CPE is beefy enough to support an IPS and reputation client, we can promote advanced-security. So, some specific places where design work is needed (not just nits with rules): What are the requirements of the reputation engine? Assuming reputation defaults to "white," then when something is blackened, how much space is blacklisted? Since any host can use any address within a /64, at least, blacklist whack-a-mole of the individual address seems unscaleable. Has work been done in this area already? What are the requirements of the IPS provider? A certain scale is required, in order to perform event correlation as described, and to detect new exploits. A certain expertise and funding is required to write signatures and mitigations. What happens if they become unreachable? Business collapse, or dDoS as part of a worm attack, for instance. Rule CryptoIntercept sounds like it should become a man-in-the-middle; needs further discussion. I'm willing to take on some of this work, but I will not be at the homegate interim meeting in Paris, because it squarely overlaps with ARIN. Lee From: homesec-dt-bounces@ietf.org [mailto:homesec-dt-bounces@ietf.org] On Behalf Of Mark Townsley Sent: Tuesday, March 16, 2010 7:24 AM To: homesec-dt@ietf.org Subject: [Homesec-dt] IPv6 Advanced Security... "Homesec DT" members, First, an apology. I created this list months ago with the intention of kicking off discussion. This list contains the people who raised their hand at the Hiroshima meeting and/or sent me email volunteering time to participate in the advancement of the idea Eric V. and I presented at the v6ops meeting there. I subsequently dropped the ball. I have a long list of reasons/excuses, personal and professional, as to why this is the case (not the least of which is my new 2-week old daughter!), but this doesn't discount the fact that I've left people hanging. So, where are we? First, Eric updated draft-vyncke-advanced-ipv6-security to -01, with minor additions/modifications based on direct feedback and review. No major overhaul though. The idea is still basically the same as presented in Hiroshima, and the draft is certainly subject to more work before it is ready for prime time. I will not be in Anaheim next week (I am still on paternity leave, and the actual due date for the baby was yesterday). I'm not sure if Eric will be presenting in v6ops. I remember list & jabber discussion about taking some of the ideas in the advanced-security document and bringing them into simple-security. In particular, "Rule #7, ParanoidOpeness"- I'd like to see that at least be discussed seriously before simple-security advances. Time is probably of the essence here. If you think this is a good idea, feel free to grab on to it and try to make it happen. I still get the impression that there is a lot of interest around this idea, and when I speak to people about it, initial skepticism almost inevitably makes its way into some form of interest. As for steps forward... we can do a number of things here. Perhaps a first step is for some of you that will be in the same city next week to chat about this. If there are any good ideas, I'll be happy to setup a webex after you all return home for us to brainstorm about next steps. What I would like to get an idea of is: - The basic architecture of IPv6 advanced security (I think a good start are the slides I used in Hiroshima) - The areas that could use operational description (e.g., within the scope of v6ops) - The areas that could use functional definition (a start is in draft-vyncke) - The interfaces that could use protocol standardization (we've talked and hand-waived a bit about this) If we can nail this down, we'll know better what could/should be done in the IETF. Also, it could be input to the "homegate" interim meeting in April, if we get our act together before then. Finally, this email list is composed of just the "design team" volunteers that agreed to help in Hiroshima. We can operate like this for a bit, but soon (if not immediately) we'll need to move this to an open discussion. I'd like to get an idea of where, and with what goal, first though, as we don't want to create a list and invite people to it without knowing what the discussion there is designed to achieve. Again, sorry for not marching forth with a battle plan right after Hiroshima. Hopefully we didn't lose too much time here. See you on email while you are in California! - Mark ------=_NextPart_000_000C_01CACA54.F92A4100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Complete silence. . = .

 

Let  me say where = I am:  I am very interested in the concepts outlines in advanced-security, but = I'm not convinced that an IPS is a good replacement for a firewall.  Host = OSes aren't secure enough yet.  I think simple-security ("deny = any" as default) is the right approach right now.  After there is some = live experience with advanced-security (i.e., using an IPS instead of a = stateful firewall), and until CPE is beefy enough to support an IPS and = reputation client, we can promote advanced-security.

 

So, some specific = places where design work is needed (not just nits with rules):

What are the = requirements of the reputation engine?   Assuming reputation defaults to "white," then  when something is blackened, how much = space is blacklisted?  Since any host can use any address within a /64, at = least, blacklist whack-a-mole of the individual address seems unscaleable.  Has work = been done in this area already?

What are the = requirements of the IPS provider?  A certain scale is required, in order to perform event correlation as described, and to detect new exploits.  A certain = expertise and funding is required to write signatures and = mitigations.

What happens if they = become unreachable?  Business collapse, or dDoS as part of a worm attack, = for instance.

Rule CryptoIntercept = sounds like it should become a man-in-the-middle; needs further = discussion.

 

I'm willing to take on = some of this work, but I will not be at the homegate interim meeting in Paris, = because it squarely overlaps with ARIN.

 

Lee

 

 

From:= homesec-dt-bounces@ietf.org [mailto:homesec-dt-bounces@ietf.org] On = Behalf Of Mark Townsley
Sent: Tuesday, March 16, 2010 7:24 AM
To: homesec-dt@ietf.org
Subject: [Homesec-dt] IPv6 Advanced = Security...

 


"Homesec DT" members,

First, an apology. I created this list months ago with the intention of = kicking off discussion. This list contains the people who raised their hand at = the Hiroshima meeting and/or sent me email volunteering time to participate = in the advancement of the idea Eric V. and I presented at the v6ops meeting = there.

I subsequently dropped the ball. I have a long list of reasons/excuses, personal and professional, as to why this is the case (not the least of = which is my new 2-week old daughter!), but this doesn't discount the fact that = I've left people hanging.

So, where are we?

First, Eric updated draft-vyncke-advanced-ipv6-security to -01, with = minor additions/modifications based on direct feedback and review. No major = overhaul though. The idea is still basically the same as presented in Hiroshima, = and the draft is certainly subject to more work before it is ready for prime = time. I will not be in Anaheim next week (I am still on paternity leave, and the = actual due date for the baby was yesterday). I'm not sure if Eric will be = presenting in v6ops.

I remember list & jabber discussion about taking some of the ideas = in the advanced-security document and bringing them into simple-security. In particular, "Rule #7, ParanoidOpeness"- I'd like to see that = at least be discussed seriously before simple-security advances. Time is probably = of the essence here. If you think this is a good idea, feel free to grab on to = it and try to make it happen.

I still get the impression that there is a lot of interest around this = idea, and when I speak to people about it, initial skepticism almost = inevitably makes its way into some form of interest.

As for steps forward... we can do a number of things here. Perhaps a = first step is for some of you that will be in the same city next week to chat about = this. If there are any good ideas, I'll be happy to setup a webex after you = all return home for us to brainstorm about next steps. What I would like to = get an idea of is:

- The basic architecture of IPv6 advanced security (I think a good start = are the slides I used in Hiroshima)
- The areas that could use operational description (e.g., within the = scope of v6ops)
- The areas that could use functional definition (a start is in = draft-vyncke)
- The interfaces that could use protocol standardization (we've talked = and hand-waived a bit about this)

If we can nail this down, we'll know better what could/should be done in = the IETF. Also, it could be input to the "homegate" interim = meeting in April, if we get our act together before then.

Finally, this email list is composed of just the "design team" volunteers that agreed to help in Hiroshima. We can operate like this = for a bit, but soon (if not immediately) we'll need to move this to an open discussion. I'd like to get an idea of where, and with what goal, first = though, as we don't want to create a list and invite people to it without = knowing what the discussion there is designed to achieve.

Again, sorry for not marching forth with a battle plan right after = Hiroshima. Hopefully we didn't lose too much time here. See you on email while you = are in California!

- Mark






------=_NextPart_000_000C_01CACA54.F92A4100--