Re: Question on Security Considerations for draft-macaulay-6man-packet-stain

Tyson Macaulay <tmacaulay@2keys.ca> Mon, 05 March 2012 12:34 UTC

Return-Path: <tmacaulay@2keys.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E54F21F86DD for <ipv6@ietfa.amsl.com>; Mon, 5 Mar 2012 04:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-D5aJD-yddO for <ipv6@ietfa.amsl.com>; Mon, 5 Mar 2012 04:34:18 -0800 (PST)
Received: from mail.2keys.ca (mail.2keys.ca [72.1.200.74]) by ietfa.amsl.com (Postfix) with ESMTP id C233C21F86B9 for <ipv6@ietf.org>; Mon, 5 Mar 2012 04:34:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.2keys.ca (Postfix) with ESMTP id 7098228110B for <ipv6@ietf.org>; Mon, 5 Mar 2012 07:30:59 -0500 (EST)
X-Virus-Scanned: amavisd-new at 2keys.ca
Received: from mail.2keys.ca ([127.0.0.1]) by localhost (mail.2keys.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ja2e8dEUodT for <ipv6@ietf.org>; Mon, 5 Mar 2012 07:30:55 -0500 (EST)
Received: from mail.2keys.ca (mail.2keys.ca [192.168.1.103]) by mail.2keys.ca (Postfix) with ESMTP id 045D3281109 for <ipv6@ietf.org>; Mon, 5 Mar 2012 07:30:55 -0500 (EST)
Date: Mon, 05 Mar 2012 07:30:54 -0500
From: Tyson Macaulay <tmacaulay@2keys.ca>
To: ipv6@ietf.org
Subject: Re: Question on Security Considerations for draft-macaulay-6man-packet-stain
Message-ID: <7ecb96b9-0d53-4e21-a0e3-d2c2f7cc652c@Tysons-MacBook-Air.local>
In-Reply-To: <mailman.31.1330632007.11177.ipv6@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Originating-IP: [99.241.179.111]
X-Mailer: Zimbra 7.1.3_GA_3374 (Zimbra Desktop/7.1.2_10978_Mac)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2012 12:34:19 -0000

> 
> Hello Tyson.  I have a few questions on your I-D about "IPv6 packet
> staining".  Let me start with one that concerns security
> considerations.
> 
> In Section 7, the I-D mentions reputational algorithms for cyber
> intelligence and then it cautions implementers about unspecified
> hazards
> associated with the source of intelligence and the protection of the
> algorithms.
> 
> Where are the algorithms (mentioned in Section 7) to be applied? In
> the
> PMDs? At the end points? In a different locations or element
> altogether?"

HI Ed,

The reputation algorithms used to derive reputation score for staining within Destination Options (DOs) would reside in an security application or service distinct from the packet manipulation device (PMD) used to apply the DOs.   For instance, many security vendors currently have on-line repositories of intelligence available for query by their deployed products.  Their algorithms reside close to, or possibly within, these service-delivery-points on the 'net.  NOT within the vendor products deployed in the field.

Similarly, the PMDs are probably not going to actually contain the algorithms used to obtain reputation scores from the correlation and aggregation of intelligence source.  PMD will, however, need to consume the finished intelligence in as close to a real-time manner as possible, so reputation stains are as accurate as possible.

Have said this - it is possible that a PMD vendor may elect to implement the algorithms within a PMD itself. For instance, for clients that need PMDs on the borders of different zones (for internal deployments), and want unique intelligence and reputations scores in each zone.

> 
> Thanks in advance,
> 
> Ed  J.