Great Circle Associates Firewalls
(September 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: ATM Security
From: Rabid Wombat <wombat @ mcfeely . bsfs . org>
Date: Thu, 26 Sep 1996 22:46:07 -0400 (EDT)
To: Sarah Wheeler <wheelsl @ mnbp2 . network . com>
Cc: "'firewalls mailing list'" <firewalls @ GreatCircle . COM>
In-reply-to: <324AF49F @ mnbp . network . com>


On Thu, 26 Sep 1996, Sarah Wheeler wrote:

> 
> Greetings!
> There has been quite a bit of discussion lately on the subject of ATM 
> security and also what vendors are doing, product wise.  I am a product 
> manager at NSC who is working on our ATM security developements and I would 
> like to give a bit of info on what we are developing (flames expected). 

Thanks for the info. I, for one, welcome on-topic vendor participation on 
the list. 


>  What we are doing is implementing ATM security policies via access control 
> and content checking (with integrated encryption to follow). This approach 
> allows you to filter based on IP (in it's cellified form) and ATM, while 
> maintaining line rates (OC3). Filtering can be based on source and 
> destination address (exact addresses or ranges) as well as logical ports. 
>  The unit itself is transparent to the network.
> 

Just curious - What line rates? OC3 to OC3 on a single link (one in / 
one out anyway), or are multiple OC3 links supported?

> Filtering and content checking is done on cellified traffic which allows us 
> to maintain the high speeds, however we have a logging tool that allows you 
> to see the specific TCP/IP  information about the rejected 
> connection/transaction.  This tool shows you what types of transactions are 
> being denied and gives the feedback to ensure your policy is correctly 
> applied.
> 

How do you handle fragmented IP packets, when some of the cells that 
comprise them have been dropped in transit?

> Our overall goal is to provide the firewall capabilities currently found in 
> firewall products on the market today -- for ATM.  Another goal is to 
> provide a level of granularity that allows you to have a security policy for 
> each VC -- this also enables selective encryption on a per VC basis as well. 
>  For example -- one could write their security policy to say... email from 
> me to you is allowed and encrypted,  and ftp is allowed from me to you, but 
> not from you to me, we both can Telnet either way.
> 

Again, curious how you handle the individual cells re the above. Also - 
how does this fit relative to VLAN tagging standards? Will this support 
spanning VLANs across WAN links?

- r.w.



References:
  • ATM Security
    From: Sarah Wheeler <wheelsl @ mnbp2 . network . com>
Indexed By Date Previous: 'secure' intranet mailreading?
From: lists @ lina . inka . de (Bernd Eckenfels)
Next: RE: Checking email address
From: Rabid Wombat <wombat @ mcfeely . bsfs . org>
Indexed By Thread Previous: ATM Security
From: Sarah Wheeler <wheelsl @ mnbp2 . network . com>
Next: Web viewers
From: potlicker @ morebbs . com

Google
 
Search Internet Search www.greatcircle.com