draft-macaulay-6man-packet-stain-00 High Level Questions

"Martin, Steve" <s.martin1@lancaster.ac.uk> Thu, 16 February 2012 21:23 UTC

Return-Path: <s.martin1@lancaster.ac.uk>
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 0FDFF21F8731 for <ipv6@ietfa.amsl.com>; Thu, 16 Feb 2012 13:23:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 hl0cpasp9zty for <ipv6@ietfa.amsl.com>; Thu, 16 Feb 2012 13:23:04 -0800 (PST)
Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5427521F8723 for <ipv6@ietf.org>; Thu, 16 Feb 2012 13:23:04 -0800 (PST)
Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from <s.martin1@lancaster.ac.uk>) id 1Ry8n9-00016N-Ay for ipv6@ietf.org; Thu, 16 Feb 2012 21:23:03 +0000
Received: from EX-1-MB0.lancs.local ([fe80::f083:6530:dfd5:ebc7]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%13]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 21:23:03 +0000
From: "Martin, Steve" <s.martin1@lancaster.ac.uk>
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: draft-macaulay-6man-packet-stain-00 High Level Questions
Thread-Topic: draft-macaulay-6man-packet-stain-00 High Level Questions
Thread-Index: Aczs8AhinRQbX7jrRoaOqLMHJv2jbw==
Date: Thu, 16 Feb 2012 21:23:01 +0000
Message-ID: <C03F3430284E23419D3BD41E5827FE11891559@EX-1-MB0.lancs.local>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [46.33.133.4]
Content-Type: multipart/alternative; boundary="_000_C03F3430284E23419D3BD41E5827FE11891559EX1MB0lancslocal_"
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:58:05 -0800
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: Thu, 16 Feb 2012 22:47:55 -0000

Hi Tyson,
I've just read your ITEF paper on Packet Staining, a very interesting idea and relevant to an area of research that I'm looking at.

Something that I've been considering is how might IPv6 impact individuals, i.e. home users who typically have limited internet security.  Under IPv4 NAT has provided an "accidental" firewall that has been very beneficial to such subscribers. As the migration to IPv6 takes hold, it strikes me that specific firewalls will become mandatory (and critical that they are kept up to date), but those subscribers won't perceive any benefit from such devices (at least not until it is too late) and will simply connect devices directly to the internet with insufficient protection.

So, and this is where you paper is relevant, I have been pondering how IPv6 can be deployed to these subscribers with the added benefit of the "built-in" security that they have been used to with the likes of NAT.

Am I right in understanding that you packet staining could provide service provision that might include any number of the following:

  *   Spam Assessment
  *   Parental Controls
  *   Malware Detection
  *   Forged Certificates
  *   etc

Some of the above would require deep packet inspection, at least as far as protocol, and in some cases of the actual data.  Is this within scope of what you envisage ?

It strikes me that your Packet Staining concept could enable the provision of services that meet the needs of these subscribers in a manner that will enable them to "configure and forget", much like they already experience with Anti-Virus products which regularly download updates), except that they would get the benefit of a more intelligent process that has a re timely updates and the potential for filtering at the perimeter or the endpoint.

Finally, it is not clear to me whether there is any impact if IPsec is involved, which would prevent such a level of packet inspection.

Many thanks for you contribution and thoughts.

Regards
Steve Martin