idnits 2.17.1 draft-ietf-bmwg-secperf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 839 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '...et. Forwarded packets MUST be included...' RFC 2119 keyword, line 101: '...ll other packets MUST NOT be included ...' RFC 2119 keyword, line 122: '...r) with restricted access MUST require...' RFC 2119 keyword, line 130: '...Authentication MAY work either by clie...' RFC 2119 keyword, line 133: '...she claims to be). Servers SHOULD also...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 109 looks like a reference -- Missing reference section? '3' on line 165 looks like a reference -- Missing reference section? '4' on line 221 looks like a reference -- Missing reference section? '5' on line 276 looks like a reference -- Missing reference section? '6' on line 331 looks like a reference -- Missing reference section? '7' on line 387 looks like a reference -- Missing reference section? '8' on line 442 looks like a reference -- Missing reference section? '9' on line 498 looks like a reference -- Missing reference section? '10' on line 554 looks like a reference -- Missing reference section? '11' on line 608 looks like a reference -- Missing reference section? '12' on line 664 looks like a reference -- Missing reference section? '13' on line 690 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Newman 3 INTERNET-DRAFT Data Communications 4 Expires in May 1998 H. Holzbaur, J. Hurd, and S. Platt 5 National Software Testing Laboratories 7 Benchmarking Terminology for Firewall Performance 8 10 Status of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 1. Introduction .......................................................2 29 2. Existing definitions ...............................................2 30 3. Term definitions ...................................................2 31 3.1 Allowed traffic ..............................................2 32 3.2 Authentication ...............................................3 33 3.3 Data source ..................................................3 34 3.4 Data connection ..............................................4 35 3.5 Demilitarized zone (DMZ) .....................................4 36 3.6 Dual-homed ...................................................5 37 3.7 Dynamic proxy ................................................5 38 3.8 External network .............................................6 39 3.9 Homed ........................................................6 40 3.10 Packet filtering ............................................6 41 3.11 Perimeter network ...........................................7 42 3.12 Policy ......................................................7 43 3.13 Protected network ...........................................8 44 3.14 Proxy .......................................................8 45 3.15 Rejected traffic ............................................9 46 3.16 Rule set ....................................................9 47 3.17 Session .....................................................9 48 3.18 Stateful inspection ........................................10 49 3.19 Tri-homed ..................................................11 50 3.20 User .......................................................11 51 4. Security considerations ..........................................11 52 5. References ........................................................12 53 6. Acknowledgments ...................................................12 54 7. Contact Information ...............................................12 55 1. Introduction 56 This document defines terms used in measuring the performance of 57 firewalls. It extends the terminology already used for benchmarking 58 routers and switches and adds terminology specific to firewalls. The 59 primary metrics defined in this document are maximum forwarding rate 60 and maximum number of connections. 62 Why are firewall performance measurements needed? First, despite the 63 rapid rise in deployment of firewalls, there is no standard method 64 for benchmarking their performance. Second, implementations vary 65 widely, making it difficult to do direct performance comparisons. 66 Finally, more and more organizations are deploying firewalls on 67 internal networks operating at relatively high speeds, while most 68 firewall implementations remain optimized for use over low-speed 69 wide-area connections. As a result, users are often unsure whether 70 the products they buy will stand up to relatively heavy loads. 72 We may also create additional terminology and methodology documents 73 to define other types of network security products such as virtual 74 private network (VPN) and encryption devices. This document, however, 75 focuses solely on firewall terminology. 77 2. Existing definitions 78 This document uses the conceptual framework established in RFCs 1242 79 and 1944 (for routers) and draft-ietf-bmwg-lanswitch-07.txt (for 80 switches). The router and switch documents contain discussions of 81 several terms relevant to benchmarking the performance of firewalls. 82 Readers should consult the router and switch documents before making 83 use of this document. 85 This document uses the definition format described in RFC 1242, 86 Section 2. The sections in each definition are: definition, 87 discussion, measurement units (optional), issues (optional), and 88 cross-references. 90 3. Term definitions 92 3.1 Allowed traffic 94 Definition: 95 Packets forwarded as a result of the rule set of the DUT/SUT. 97 Discussion: 98 Firewalls typically are configured to forward only those packets 99 explicitly permitted in the rule set. Forwarded packets MUST be included 100 in calculating the forwarding rate or maximum forwarding rate of the 101 DUT/SUT. All other packets MUST NOT be included in forwarding rate 102 calculations. 104 Measurement units: 105 Not applicable 107 Issues: 109 Newman et al. Page [2] 110 See also: 111 policy (3.12) 112 rule set (3.15) 114 3.2 Authentication 116 Definition: 117 The process of verifying that a client user or machine requesting a 118 network resource is who he, she, or it claims to be, and vice versa. 120 Discussion: 121 Trust is a critical concept in network security. Any network resource 122 (such as a file server or printer) with restricted access MUST require 123 authentication before granting access. 125 Authentication takes many forms, including but not limited to IP 126 addresses; TCP or UDP port numbers; passwords; external token 127 authentication cards; and biometric identification such as signature, 128 speech, or retina recognition systems. 130 Authentication MAY work either by client machine (for example, by 131 proving that a given IP source address really is that address, and not a 132 rogue machine spoofing that address) or by user (by proving that the 133 user really is who he or she claims to be). Servers SHOULD also 134 authenticate themselves to clients. 136 Measurement units: 137 Not applicable 139 Issues: 140 Testers should be aware that in an increasingly mobile society, 141 authentication based on machine-specific criteria such as an IP address 142 or port number is not equivalent to verifying that a given individual is 143 making an access request. At this writing systems that verify the 144 identity of persons are typically external to the firewall, and may 145 introduce additional latency to the overall SUT. 147 See also: 148 user (3.20) 150 3.3 Data source 152 Definition: 153 A station capable of generating traffic to the DUT/SUT. 155 Discussion: 156 One data source MAY emulate multiple users or stations. In addition, one 157 data source MAY offer traffic to multiple network interfaces on the 158 DUT/SUT. 160 Measurement units: 161 Not applicable 163 Issues: 165 Newman et al. Page [3] 166 The term "data source" is deliberately independent of any number of 167 users. It is useful to think of data sources simply as traffic 168 generators, and not as a given number of users. 170 See also: 171 data connection (3.4) 173 3.4 Data connection 175 Definition: 176 A logical link established between two hosts, or between a host and the 177 DUT/SUT. 179 Discussion: 180 The number of concurrent data connections a firewall can field may be 181 just as important a metric for some users as the rate at which it can 182 forward traffic. Data connections MAY be TCP sessions, but they don't 183 have to be. Users of other connection-oriented protocols such as ATM may 184 wish to measure these, either instead of or in addition to TCP 185 connections. 187 Measurement units: 188 Number of connections 190 Issues: 191 A firewall's architecture dictates where the connection is terminated. 192 In the case of proxy-based systems, a connection by definition 193 terminates at the DUT/SUT. But firewalls using packet filtering or 194 stateful inspection designs act only as passthrough devices, in that 195 they reside between two connection endpoints. Regardless of firewall 196 architecture, the number of data connections is still relevant, since 197 all firewalls perform some form of connection maintenance; at the very 198 least, all check connection requests against their rule sets. 200 See also: 201 data source (3.3) 203 3.5 Demilitarized zone (DMZ) 205 Definition: 206 A network segment or segments located between protected and external 207 networks. DMZ networks are sometimes called perimeter networks. 209 Discussion: 210 As an extra security measure, networks are often designed such that 211 protected and external segments are never directly connected. Instead, 212 firewalls (and possibly public resources such as WWW or FTP servers) 213 often reside on the so-called DMZ network. To connect protected, DMZ, 214 and external networks with one device, the device MUST have at least 215 three network interfaces. 217 Multiple firewalls MAY bound the DMZ. In this case, the firewalls 218 connecting the protected network with the DMZ and the DMZ with the 219 external network MUST each have at least two network interfaces. 221 Newman et al. Page [4] 222 Measurement units: 223 Not applicable 225 Issues: 226 Dual-homed 227 Homed 229 See also: 230 external network (3.8) 231 perimeter network (3.11) 232 protected network (3.13) 234 3.6 Dual-homed 236 Definition: 237 A firewall with at least two network interfaces. 239 Discussion: 240 Dual-homed firewalls connect two segments with different network 241 addresses. 243 Measurement units: 244 Not applicable 246 Issues: 247 Typically the differentiator between one segment and another is its IP 248 address. However, firewalls may connect different networks of other 249 types, such as ATM or Netware segments. 251 See also: 252 Homed (3.9) 253 Tri-homed (3.19) 255 3.7 Dynamic proxy 257 Definition: 258 A proxy service that is set up and torn down in response to a client 259 request, rather than existing on a static basis. 261 Discussion: 262 Proxy services (see section 3.14) typically "listen" on a given TCP port 263 number for client requests. With static proxies, a firewall always 264 forwards packets containing a given TCP port number if that port number 265 is permitted by the rule set. Dynamic proxies, in contrast, forward TCP 266 packets only once an authenticated connection has been established. When 267 the connection closes, a firewall using dynamic proxies rejects 268 individual packets, even if they contain port numbers allowed by a rule 269 set. 271 Measurement units: 272 Not applicable 274 Issues: 276 Newman et al. Page [5] 277 rule sets 279 See also: 280 allowed traffic (3.1) 281 proxy (3.14) 282 rejected traffic (3.15) 283 rule set (3.16) 285 3.8 External network 287 Definition: 288 The segment or segments not protected by the network security DUT/SUT. 290 Discussion: 291 Firewalls are deployed between protected and unprotected segments. The 292 external network is not protected by the DUT/SUT. 294 Measurement units: 295 Not applicable 297 Issues: 299 See also: 300 demilitarized zone (DMZ) (3.5) 301 protected network (3.13) 303 3.9 Homed 305 Definition: 306 The number of logical interfaces a DUT/SUT contains. 308 Discussion: 309 Firewalls MUST contain at least two interfaces, using a dual-homed 310 configuration. In network topologies where a DMZ is used, the firewall 311 contains at least three interfaces and is said to be tri-homed. 312 Additional interfaces would make a firewall quad-homed, quint-homed, and 313 so on. 315 Issues: 316 It is theoretically possible for a firewall to contain one physical 317 interface and multiple logical interfaces. This configuration is 318 strongly discouraged for testing purposes because of the possibility of 319 leakage between protected and unprotected segments. 321 See also: 322 Dual-homed (3.6) 323 Tri-homed (3.19) 325 3.10 Packet filtering 327 Definition: 328 The process of controlling access by examining packets based on packet 329 header content. 331 Newman et al. Page [6] 332 Discussion: 333 Packet-filtering devices forward or deny packets based on information in 334 each packet's header, such as IP address or TCP port number. A packet- 335 filtering firewall uses a rule set (see section 3.16) to determine which 336 traffic should be forwarded and which should be blocked. 338 Measurement units: 339 Not applicable 341 Issues: 343 See also: 344 dynamic proxy (3.7) 345 proxy (3.14) 346 rule set (3.16) 347 stateful inspection (3.18) 349 3.11 Perimeter network 351 Definition: 352 A network segment or segments located between protected and external 353 networks. Perimeter networks are often called DMZ networks. 355 Discussion: 356 See the definition of DMZ for a discussion. 358 Measurement units: 359 Not applicable 361 Issues: 362 Dual-homed 363 Tri-homed 365 See also: 366 Demilitarized zone (DMZ) (3.5) 367 external network (3.8) 368 protected network (3.13) 370 3.12 Policy 372 Definition: 373 A document defining acceptable use of protected, DMZ, and external 374 networks. 376 Discussion: 377 Security policies generally do not spell out specific configurations for 378 firewalls; rather, they set general guidelines for what it and is not 379 acceptable network behavior. 381 The actual mechanism for controlling access is usually the rule set (see 382 section 3.16) implemented in the DUT/SUT. 384 Measurement units: 385 Not applicable 387 Newman et al. Page [7] 388 Issues: 390 See also: 391 Rule set (3.16) 393 3.13 Protected network 395 Definition: 396 A network segment or segments to which access is controlled by the 397 DUT/SUT. 399 Discussion: 400 Firewalls are intended to prevent unauthorized access either to or from 401 the protected network. Depending on the configuration specified by the 402 policy and rule set, the DUT/SUT may allow stations on the protected 403 segment to act as clients for servers on either the DMZ or the external 404 network, or both. 406 Protected networks are often called "internal networks." That term is 407 not used here because firewalls increasingly are deployed within an 408 organization, where all segments are by definition internal. 410 Measurement units: 411 Not applicable 413 Issues: 415 See also: 416 Demilitarized zone (DMZ) (3.5) 417 external network (3.8) 418 policy (3.12) 419 rule set (3.16) 421 3.14 Proxy 423 Definition: 424 A request for a connection made on behalf of a host. 426 Discussion: 427 Proxy-based firewalls never allow direct connections between hosts. 428 Instead, two connections are established: one between the client host 429 and the DUT/SUT, and another between the DUT/SUT and server host. 431 As with packet-filtering firewalls, proxy-based devices use a rule set 432 to determine which traffic should be forwarded and which should be 433 rejected. 435 Measurement units: 436 Not applicable 438 Issues: 440 See also: 442 Newman et al. Page [8] 443 dynamic proxy (3.7) 444 packet filtering (3.10) 445 stateful inspection (3.18) 447 3.15 Rejected traffic 449 Definition: 450 Packets dropped as a result of the rule set of the DUT/SUT. 452 Discussion: 453 Firewalls MUST reject any traffic not explicitly permitted in the rule 454 set. Dropped packets MUST NOT be included in calculating the forwarding 455 rate or maximum forwarding rate of the DUT/SUT. 457 Measurement units: 458 Not applicable 460 Issues: 462 See also: 463 policy (3.12) 464 rule set (3.16) 466 3.16 Rule set 468 Definition: 469 The collection of access control rules that determines which packets the 470 DUT/SUT will forward and which it will reject. 472 Discussion: 473 Rule sets control access to and from the network interfaces of the 474 DUT/SUT. By definition, rule sets MUST NOT apply equally to all network 475 interfaces; otherwise there would be no need for the firewall. 476 Therefore, a specific rule set MUST be applied to each network interface 477 in the DUT/SUT. 479 The order of rules within the rule set is critical. Firewalls generally 480 scan rule sets in a "top down" fashion, which is to say that the device 481 compares each packet received with each rule in the rule set until it 482 finds a rule that applies to the packet. Once the device finds an 483 applicable rule, it applies the actions defined in that rule (such as 484 forwarding or rejecting the packet) and ignores all subsequent rules. 485 For testing purposes, the rule set MUST conclude with a rule denying all 486 access. 488 Measurement units: 489 Not applicable 491 Issues: 493 See also: 494 Demilitarized zone (DMZ) (3.5) 495 external network (3.8) 496 policy (3.12) 498 Newman et al. Page [9] 499 protected network (3.13) 500 rejected traffic (3.15) 502 3.17 Session 504 Definition: 505 A logical connection established between two stations using a known 506 protocol. 508 Discussion: 509 Because of the application-layer focus of many firewalls, sessions are a 510 more useful metric than the packet-based measurements used in 511 benchmarking routers and switches. Although firewall rule sets generally 512 work on a per-packet basis, it is ultimately sessions that a firewall 513 must handle. For example, the number of file transfer protocol (ftp) 514 sessions a DUT/SUT can handle concurrently is a more meaningful 515 measurement in benchmarking performance than the number of ftp "open" 516 packets it can reject. Further, a stateful inspection firewall will not 517 forward individual packets if those packets' headers conflict with state 518 information maintained by the firewall. 520 For purposes of this document, a session MUST be established using a 521 known protocol such as TCP. A traffic pattern is not considered a 522 session until it successfully completes the establishment procedures 523 defined by that protocol. 525 Also for purposes of this document, a session constitutes the logical 526 connection between two end-stations and not the intermediate connections 527 that proxy-based firewalls may use. 529 Issues: 531 See also: 532 policy (3.12) 533 proxy (3.14) 534 rule set (3.16) 535 stateful inspection (3.18) 537 3.18 Stateful inspection 539 Definition: 540 The process of forwarding or rejecting traffic based on the contents of 541 a state table maintained by a firewall. 543 Discussion: 544 Packet filtering and proxy firewalls are essentially static, in that 545 they always forward or reject packets based on the contents of the rule 546 set. 548 In contrast, devices using stateful inspection will only forward packets 549 if they correspond with state information maintained by the device about 550 each session. For example, a stateful inspection device will reject a 551 packet on port 20 (ftp-data) if no session has been established over the 552 ftp control port (usually port 21). 554 Newman et al. Page [10] 555 Measurement units: 556 Not applicable 558 Issues: 560 See also: 561 dynamic proxy (3.7) 562 packet filter (3.10) 563 proxy (3.14) 565 3.19 Tri-homed 567 Definition: 568 A firewall with three network interfaces. 570 Discussion: 571 Tri-homed firewalls connect three network segments with different 572 network addresses. Typically, these would be protected, DMZ, and 573 external segments. 575 Measurement units: 576 Not applicable 578 Issues: 579 Usually the differentiator between one segment and another is its IP 580 address. However, firewalls may connect different networks of other 581 types, such as ATM or Netware segments. 583 See also: 584 Dual-homed (3.6) 585 Homed (3.9) 587 3.20 User 589 Definition: 590 The person or machine requesting access to resources protected by the 591 DUT/SUT. 593 Discussion: 594 "User" is a problematic term in the context of firewall performance 595 testing, for several reasons. First, a user may in fact be a machine or 596 machines requesting services through the DUT/SUT. Second, different 597 "user" requests may require radically different amounts of DUT/SUT 598 resources. Third, traffic profiles vary widely from one organization to 599 another, making it difficult to characterize the load offered by a 600 typical users. 602 For these reasons, we prefer not to measure DUT/SUT performance in terms 603 of users supported. Instead, we describe performance in terms of maximum 604 forwarding rate and maximum number of sessions sustained. Further, we 605 use the term "data source" rather than user to describe the traffic 606 generator(s). 608 Newman et al. Page [11] 609 Measurement units: 610 Not applicable 612 Issues: 614 See also: 615 data source (3.3) 617 4. Security considerations 618 Security considerations are explicitly excluded from this memo. The 619 authors plan to address security and management concerns in a separate 620 proposal brought to the IETF's security directorate. 622 5. References 624 Bradner, S., editor. "Benchmarking Terminology for Network 625 Interconnection Devices." RFC 1242. 627 Bradner, S., and McQuaid, J. "Benchmarking Methodology for Network 628 Interconnect Devices." RFC 1944. 630 Mandeville, B. "Benchmarking Terminology for LAN Switching Devices." 631 ftp://ietf.org/internet-drafts/draft-ietf-bmwg-lanswitch-07.txt 633 Newman, D., and Melson, B. "Can Firewalls Take the Heat?" Data 634 Communications, November 21, 1995. 635 http://www.data.com/Lab_Tests/Firewalls.html 637 Newman, D., Holzbaur, H., and Bishop, K. "Firewalls: Don't Get Burned," 638 Data Communications, March 21, 1997. 639 http://www.data.com/lab_tests/firewalls97.html 641 Ranum, M. "Firewall Performance Measurement Techniques: A Scientific 642 Approach." http://www.clark.net/pub/mjr/pubs/fwperf/intro.htm 644 Shannon, G. "Profile of Corporate Internet Application Traffic." 645 http://www.milkyway.com/libr/prof.html 647 6. Acknowledgments 648 The authors wish to thank the IETF Benchmarking Working Group for 649 agreeing to review this document. Ted Doty (Internet Security Systems), 650 Shlomo Kramer (Check Point Software Technologies), Bob Mandeville 651 (European Network Laboratories), Brent Melson (National Software Testing 652 Laboratories), Marcus Ranum (Network Flight Recorder Inc.), Greg Shannon 653 (Ascend Communications), Rick Siebenaler (Cyberguard), and Greg Smith 654 (Check Point Software Technologies) offered valuable contributions and 655 critiques during this project. 657 7. Contact Information 658 David Newman 659 Data Communications magazine 660 1221 Avenue of the Americas, 41st Floor 661 New York, NY 10020 662 USA 664 Newman et al. Page [12] 665 212-512-6182 voice 666 212-512-6833 fax 667 dnewman@data.com 669 Helen Holzbaur 670 National Software Testing Laboratories Inc. 671 625 Ridge Pike 672 Conshohocken, PA 19428 673 USA 674 helen@nstl.com 676 Jim Hurd 677 National Software Testing Laboratories Inc. 678 625 Ridge Pike 679 Conshohocken, PA 19428 680 USA 681 jimh@nstl.com 683 Steven Platt 684 National Software Testing Laboratories Inc. 685 625 Ridge Pike 686 Conshohocken, PA 19428 687 USA 688 steve@nstl.com 690 Newman et al. Page [13]