RE: terminology of channel numbers

["Ricky Charlet" <rcharlet@SonicWALL.com>]

Howdy,
	
	Channel nubmers would be very helpfull from a network operator's
perspective for managing a VPN or Remote Access type deployment of
IPsec. In both of these cases, network operators have pre-concieved
notions of 'tunnels' or 'channels' and would greatly appreciate the
ability to track MIB2/RMON type statistics on a per channel basis. These
stats gathering capabilities enable the ability to do fault detection,
perfomance tuning, and capacity planning at the 'channel' layer. 

	I believe that an iteroperable notion of how to enable
fault/capacity/performance management of VPN/RemoteAccess IPsec
deployments at the 'channel' layer would noticably improve market
acceptance of IPsec. This is just my personal gut-feeling, not a
marketing researched backed white paper conslusion or anything like
that.


--

 Ricky Charlet     : rcharlet@sonciwall.com   : usa (408) 962-8711 


> -----Original Message-----
> From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
> Sent: Friday, April 12, 2002 10:29 AM
> To: ipsec@lists.tislabs.com
> Subject: terminology of channel numbers
> 
> 
> 
>   One thing that the FreeSWAN team has discussed introducing 
> to Son-of-IKE is
> the notion of a channel and channel ID.
> 
>   This is akin to SPI#, but is higher level.
>   
>   This is essentially a 32 or 64 bit blob produced by 
> concatenating a shorter 
> ID present in the proposal by each end.
> 
>   This is a longer lived identifier than SPI#. One uses this 
> ID to identify
> the set of SAs that currently or have implemented a policy. 
>   That is, the entire blob identifies both directions of traffic flow.
> 
>   Rekey's would say  "I wish to rekey channel #XXXXXX" 
>   Delete's would say "I wish to delete channel #XXXXXX" 
> because I'm turning
> myself off. 
>   {vs "I want to delete SPI#" (because we just rekeyed it)}
> 
>   This makes is very clear what is going on at each end.
> 
> ]       ON HUMILITY: to err is human. To moo, bovine.         
>   |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON  
>   |net architect[
> ] mcr@sandelman.ottawa.on.ca 
> http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another NetBSD/notebook using, kernel hacking, 
> security guy");  [
> 
> 
> 
>   
>