RE: ipv6 Digest, Vol 94, Issue 17

["[e-mail]" <[e-mail]>]

> 
> Hi Tyson,

HI Steve,

First  - thanks for your comments and questions  They are on topic and on target.

> 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

Staining will insert a reputation score into each packet.  The reputation taxonomy is variable (at least at this time) and could include sub-classes just for spam.  In such a case, those stains may only be used by email systems while other assets such as web servers choose to ignore them (because they are email-specific stains).  This is at the discretion of the implementer.

>   *   Parental Controls

This is a core function of staining.  Certain type of content will fall into a reputation category.  It is certainly possible that an ISP may elect to stain traffic entering the distribution network for residential customers and then allow the customers to in effect filter the traffic on the edge device (DSL/DOCSIS router) or end-point device.  Much the same thing can be done with DNS services now - but it applies to every device in the house.  Staining could be applied device by device - though the network stack would need to read the stains or third-party software would need to read the stains.

>   *   Malware Detection

This is a core function.  The idea is that a carrier/ISP will stain traffic from known malware sites/locations as it enters the network and then allow subscribers to filter quickly on their end.  The ISP in this case may elect to filter traffic from malware sites at the access layer of the ISP, or let the subscriber endpoints do it as part of a subscription services.

>   *   Forged Certificates

A forged cert, once discovered, would affect the reputation of the site using the certificate and probably the CA itself.  Their reputations would be stained accordingly and traffic filtered on this basis.  Staining devices will generally not make decisions about whether  certificate is forged or not - they use intelligence supplied by various different means that is outside the scope of the DRAFT right now.

>   *   etc

Another use-case we tried to describe (briefly) is that staining can also created walled-gardens. Traffic from "approved" sites has a specific stain and only packets with that stain may enter (network, endpoint, whatever).  Schools might like this - where only traffic from approved educational sites get into the network.  True - firewalls can do this now but it's a problem and a hassle to maintain such devices, and DNS-type filtering can be defeated by simply re-configuring your host DNS IP.  Staining can be used to do firewalling and content filtering in the carrier or ISP cloud, at least in part.  These days we need all the layers of security we can get.


> 
> 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 ?

DPI is partially in scope when the reputation of large portals is at stake.  For instance, Facebook.  One of the staining options is to indicate if the reputation stain includes a URL.  When the stain includes a URL, the staining-reading element (FW, etc) may need to do DPI to see if the URL is present.  


> 
> 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.

Yes - in addition to more timely threat intelligence, the solution itself is possibly more scalable, since massive list of threat signatures and/or extracts from a virtually unlimited IP-space would not need to be managed.

Thanks for your comments and collaboration as we refine the draft.
> 
> 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