EIDE Design Considerations Brian Wright Portland General Electric

1. EIDE Design ConsiderationsBrian WrightPortland General Electric EIDE Design Considerations

2. Introduction • Focus on physical design, not on application development. • Planned Topics 1. Hardware Configuration 2. Location and Function Of Application Modules 3. Data Connectivity 4. Cryptography Basics EIDE Design Considerations

3. LAN – Local Area Network Collection of computers within one domain, secured from outside connections. WAN – Wide Area Network Collection of computer domains, with security between domains. DMZ - Demilitarized Zone A small subnetwork that sits between a trusted internal network, such as a corporate private LAN, and an untrusted external network, such as the public Internet. Firewall A system designed to prevent unauthorized access to or from a private network. Firewalls can be implemented in both hardware and software, HTTP - HyperText Transfer Protocol, the underlying protocol used by the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions server applications and their client applications should take in response to various commands. Glossary & Acronyms EIDE Design Considerations

4. Glossary & Acronyms • UTF - Universal Transformation Format • a method of converting Unicode characters, which are 16 bits each, into 7- or 8-bit characters. UTF-7 converts Unicode into ASCII for transmission over 7-bit mail systems, and UTF-8 converts Unicode to 8-bit bytes. • DBMS – Database Management System • A collection of programs that enables you to store, modify, and extract information from a database • COM – Component Object Model • A software architecture developed by Microsoft to build component-based applications. COM objects are discrete components, each with a unique identity, which expose interfaces that allow applications and other components to access their features. EIDE Design Considerations

5. Hardware Configuration • Simple System • Secure System • Secure Redundant System EIDE Design Considerations

6. Simple System • Single LAN Server • Web Listener receives incoming requests and gives it to the receiver • Data store caches meter and schedule data to be sent or received • EIDE Receiver parses the received XML document and writes to the Data Store • EIDE Sender reads from the Data Store, builds the XML document , and sends to the external entity • The EIDE applications are where the logic is placed, related to managing request to send or receive data EIDE Design Considerations

7. ADVANTAGES Simple to configure Lower Hardware Costs No special requirements on external entities DISADVANTAGES Direct access from internet allowed to LAN server No redundancy, down time can be expected for upgrades and failures Simple System EIDE Design Considerations

8. Secure System • DMZ Server – Limited firewall protection, IP address is masked • LAN Server – High firewall protection. Generally configured to allow no direct internet connections inside • EIDE Proxy provides received application xml validation, document canonicalization and signing. • EIDE Receiver inspects signature to validate message originator EIDE Design Considerations

9. ADVANTAGES No direct access to LAN servers from internet. No special requirements on external entities DISADVANTAGES Additional Administration No redundancy, down time can be expected for upgrades and failures Secure System EIDE Design Considerations

10. Secure Redundant System • Content switches provides load balancing and failover to the dual servers • Virtual IP address provides single address to content switches • Cross connectivity allows maintenance of servers while other node in service • Data store is now required to be shared within its own database cluster. EIDE Design Considerations

11. Data Store Cluster • Two or more servers can be clustered together in an active-passive system. • The DBMS is defined into an application group for failover. • Storage Controller contains the disk array and are manufactured with fault tolerant features. • For fault tolerance in the disk arrays, recently they raid level 0+1 or 10 EIDE Design Considerations

12. ADVANTAGES Majority of maintenance can occur while system is in operation Fault Tolerance DISADVANTAGES Complexity in Administration Additional Hardware Costs Secure Redundant System EIDE Design Considerations

13. Data Connectivity • HTTP protocol works best when crossing a firewall. To assist with security, may want to use a non-standard port for crossing the DMZ to LAN firewall. http://4.5.30.209:22100/WeatherSummary.html • Primary development of content switches were to manage load balancing of server farms for the web, http • Do not have any database connectivity cross the firewall. EIDE Design Considerations

14. Data Connectivity Messaging : If using Microsoft platform use Microsoft Message Queue (MSMQ) for cross server communications, or Java Message Service for other platforms • Raises events within application. • Messages remain in queue until read or message life expires. Allowing processing to be single threaded, avoiding collisions from multiple requests • Messages have priority, read from queue in highest priority first. Messages with same priority are read first in first out. • Messaging can be made fault tolerant. Allowing messages to be delivered even if there was a temporary outage. • MSMQ Triggers automatically associate incoming messages in a queue with functionality in a COM component or standalone .exe EIDE Design Considerations

15. Data Connectivity Messaging Usage: • If EIDE Receiver is a service, it would have a no blocking listener on a queue that EIDE proxy would write to, and send a message to the applications that they have data now available. • If EIDE Sender is a service, the application that request a transfer externally would write the data to the data store and send a message to EIDE Sender to perform a transfer. • If willing to forgo the persistent cache provided by the data store, the messages could contain the data. • Many object oriented languages have the ability to serialize an object. This serialize object would be the payload of a message. EIDE Design Considerations

16. Cryptography Basics • Encryption/Decryption • Symmetric vs Asymmetric • XML Canonicalization • Signing EIDE Design Considerations

17. Cryptography Basics Encryption/Decryption P: Plain Text C: Cypher Text K: Key F: Encryption Algorithm (DES, RSA) • Encryption F(P,K) = C • Decryption F(C, K) = P EIDE Design Considerations

18. SYMMETRIC Same key uses for encryption and decryption. Key must be known by both parties Relative inexpensive in resource utilization ASYMMETRIC Encryption by private key Decryption by public key Sender is owner of keys Expensive in resource utilization Cryptography Basics Symmetric vs Asymmetric EIDE Design Considerations

19. Cryptography Basics XML Canonicalization Two XML messages can be formatted differently but contain the same information. Canonicalization reformats them identically. • Whitespace normalized • <ScheduleType/> becomes <ScheduleType></ScheduleType> • Attributed values delimited by double quotes • UTF encoding EIDE Design Considerations

20. Cryptographic BasicsSigning (Digital Signature) Process validates that data has not been tampered and the data is from the sender. Sender • Plain Text canonicalized and hashed to fix length string • Hash encrypted using private key producing the signature • Send plain text and signature Receiver • Plain Text canonicalized and hashed to fix length string • Request Public key from sender • Decrypts signature and compares hash values EIDE Design Considerations

21. Discussion • One of many designs • Not specific to a technology or operating system • Web Services • NT Services or Unix Daemons • Triggers EIDE Design Considerations

22. QUESTIONS? EIDE Design Considerations