Subject: Security notes

From: [email-masked]
Date: Mon, 10 Nov 97 14:40:15 -0500

Greetings. In working to revise the security device performance draft now before
the bmwg, a couple of questions have come up. We would welcome guidance from the
list on these questions:

1. As several attendees recommended in Munich, we are working to narrow the 
scope of the document to cover firewalls alone rather than security devices as a
whole. Are there any objections to doing so? 

2. At the Munich meeting, HP's Jeff Dunn suggested that we add terminology to 
cover firewalls on ATM networks. The group kicked around the term PDU quite a 
bit, with some attendees cautioning that we may get into characterizing 
functionality rather than performance if the definition is overly generic. 

Our take on this is to add a definition only for PDU, with some discussion of 
specific ATM requirements with regard to firewalls.

Question here is whether the lone definition for PDU is adequate. For purposes 
of this document, we will make clear that PDUs are used to measure forwarding 
rate alone.

Thanks in advance for your thoughts.

David Newman
Data Communications

Helen Holzbaur
NSTL

Jim Hurd
NSTL

Steve Platt
NSTL

---

From: "Freedman, Jerome" <[email-masked]>
Date: Tue, 11 Nov 1997 11:20:09 -0500

I agree that the scope of the security device performance draft is
overly broad. To narrow the scope I would suggest splitting the document
into two documents. One document would cover firewalls, the other
document would cover VPN/encrypting devices.The functionality is
orthogonal and it would be unwise to ignore issues of VPN performance
since this a growing market ( where do NAT devices fit? ). 

Jerry Freedman,Jr
                                                                     GTE
Gov't Systems

781-455-2451

---

From: [email-masked]
Date: Tue, 11 Nov 97 14:36:17 -0500

I agree that the scope of the security device performance draft is overly 
broad. To narrow the scope I would suggest splitting the document into 
two documents. One document would cover firewalls, the other document 
would cover VPN/encrypting devices.The functionality is orthogonal and it 
would be unwise to ignore issues of VPN performance since this a growing 
market ( where do NAT devices fit? ). 

     Yes, splitting the document into two seems a good idea. But there is an 
     issue here: While firewall and VPN *functionality* is definitely 
     orthogonal, product *feature sets* are not. Virtually every firewall vendor 
     claims some sort of VPN functionality. 

     This raises the question of how these devices should be benchmarked. We 
     normally isolate one variable at a time -- firewall performance *or* VPN 
     performance but not both simultaneously. But both functions simultaneously 
     is exactly how many of these systems are deployed.

     I'd suggest separate documents as you suggest, but only as a starting 
     point. Once we can adequately describe each function separately, it may 
     be useful to benchmark devices acting as both firewalls and VPNs.

     dn

---

From: [email-masked] (Kevin Dubray)
Date: Mon, 17 Nov 1997 15:59:17 -0500

> From [email-masked] Mon Nov 10 14:48:55 1997
> 
> 
> scope of the document to cover firewalls alone rather than security devices 
> as a whole. Are there any objections to doing so? 

I would agree that the "divide and conquer" approach advocated is probably
best here.  As alluded to by others,  classifying a device from 
perceived "feature" may prove to be non-trivial. (Or, at least, very
interesting! ;-)

> Question here is whether the lone definition for PDU is adequate. 
> For purposes of this document, we will make clear that PDUs are 
> used to measure forwarding rate alone.
> 

Though I agree with the need for a tag for the unit of work being tested, 
I am apprehensive about the use of the term "PDU" for a couple of
reasons:

    A. You appear to be re-casting the term from its formal definition
    in ISO 7498-1 (aka ITU Rec. X.200) into the context of this
    document. Other than showing a knowledge of OSI, this generally 
    is not a good thing. ;-)

    B. The term PDU seems to embodies a unit of information between
    peers of the same protocol.  And that would work if we're talking
    about a device under test (DUT) in a symmetric test environment -
    ATM cells into a DUT; ATM cells out of the DUT.  Now consider an
    asymmetric test scenario whereby IP packets go into the DUT but
    ATM cells go out. Which data/transactional unit gets scrutinized?  
    Does the term PDU still hold? 

-Kevin

---

From: [email-masked]
Date: Mon, 17 Nov 97 17:27:29 -0500

B. The term PDU seems to embodies a unit of information between 
    peers of the same protocol.  And that would work if we're talking 
    about a device under test (DUT) in a symmetric test environment - 
    ATM cells into a DUT; ATM cells out of the DUT.  Now consider an 
    asymmetric test scenario whereby IP packets go into the DUT but ATM 
    cells go out. Which data/transactional unit gets scrutinized?  Does 
    the term PDU still hold? 

We hadn't even considered the asymmetric case! We were thinking only of 
ATM-to-ATM connections. While it's unlikely a straight firewall would handle 
ATM-to-something else conversion, this is a valid concern--especially as more 
switches and routers embed firewall functionality. 

As for the term PDU, I wouldn't exclude a term just because it was part of OSI. 
;-) 

However, I would propose that we hold off on including the term PDU in this 
draft, and in Washington discuss what label to affix to the unit of 
information/unit of information/packet/frame/datagram/message/hunk o' data. 
Judging from the number of requests Data Comm magazine fields for testing of ATM
firewalls, we're going to have to address the question of ATM and firewalls 
sooner or later.

David Newman
Data Communications magazine