--- 1/draft-ietf-dots-signal-call-home-01.txt 2019-05-31 08:13:18.694644852 -0700 +++ 2/draft-ietf-dots-signal-call-home-02.txt 2019-05-31 08:13:18.746646306 -0700 @@ -1,51 +1,51 @@ DOTS T. Reddy Internet-Draft McAfee Intended status: Standards Track M. Boucadair -Expires: October 28, 2019 Orange +Expires: December 2, 2019 Orange J. Shallow - April 26, 2019 + May 31, 2019 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home - draft-ietf-dots-signal-call-home-01 + draft-ietf-dots-signal-call-home-02 Abstract This document specifies the DOTS signal channel Call Home service, which enables a DOTS server to initiate a secure connection to a DOTS client, and to receive the attack traffic information from the DOTS client. The DOTS server in turn uses the attack traffic information to identify the compromised devices launching the outgoing DDoS attack and takes appropriate mitigation action(s). - The Call Home service is not specific to the home networks; the + The DOTS Call Home service is not specific to the home networks; the solution targets any deployment which requires to block DDoS attack traffic closer to the source(s) of a DDoS attack. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 28, 2019. + This Internet-Draft will expire on December 2, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -54,39 +54,40 @@ 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 - 2. Notational Conventions and Terminology . . . . . . . . . . . 7 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 7 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 8 - 3.2.1. Mitigation Request . . . . . . . . . . . . . . . . . 8 - 3.2.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 12 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 16 - 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 16 - 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 16 - 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 17 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 9.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 8 + 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 9 + 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 9 + 3.3.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 14 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 17 + 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 17 + 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 18 + 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 18 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 9.2. Informative References . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction 1.1. The Problem The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is used to carry information about a network resource or a network (or a part thereof) that is under a Distributed Denial of Service (DDoS) attack. Such information is sent by a DOTS client to one or multiple DOTS servers so that appropriate mitigation actions are undertaken on @@ -95,30 +96,29 @@ Internet of Things (IoT) devices are becoming more and more prevalent in home networks, and with compute and memory becoming cheaper and cheaper, various types of IoT devices become available in the consumer market at affordable price. But on the downside, the main threat being most of these IoT devices are bought off-the-shelf and most manufacturers haven't considered security in the product design. IoT devices deployed in home networks can be easily compromised, they do not have an easy mechanism to upgrade, and IoT manufactures may cease manufacture and/or discontinue patching vulnerabilities on IoT - devices (Sections 5.4 and 5.5 of [I-D.irtf-t2trg-iot-seccons]). - However, these vulnerable and compromised devices will continue to be - used for a long period of time in the home, and the end-user does not - know that IoT devices in his/her home are compromised. The - compromised IoT devices are typically used for launching DDoS attacks - (Section 3 of [I-D.irtf-t2trg-iot-seccons]) on victims while the - owner/administrator of the home network is not aware about such - misbehaviors. Similar to other DDoS attacks, the victim in this - attack can be an application server, a host, a router, a firewall, or - an entire network. + devices (Sections 5.4 and 5.5 of [RFC8576]). However, these + vulnerable and compromised devices will continue to be used for a + long period of time in the home, and the end-user does not know that + IoT devices in his/her home are compromised. The compromised IoT + devices are typically used for launching DDoS attacks (Section 3 of + [RFC8576]) on victims while the owner/administrator of the home + network is not aware about such misbehaviors. Similar to other DDoS + attacks, the victim in this attack can be an application server, a + host, a router, a firewall, or an entire network. Nowadays, network devices in a home network offer network security (e.g., firewall or Intrusion Protection System (IPS) service on a home router) to protect the devices connected to the home network from both external and internal attacks. Over the years several techniques have been identified to detect DDoS attacks, some of these techniques can be enabled on home network devices but most of them are used in the Internet Service Provider (ISP)'s network. The ISP offering DDoS mitigation service can detect outgoing DDoS attack traffic originating from its subscribers or the ISP may receive @@ -256,21 +256,21 @@ | || +-----+-++----+ |Attack Source| +-------------+ Figure 1: Call Home Reference Architecture It is out of the scope of this document to identify an exhaustive list of such deployments. -2. Notational Conventions and Terminology +2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. The reader should be familiar with the terms defined in [I-D.ietf-dots-requirements]. @@ -337,23 +337,63 @@ different port number. Using this TCP connection, the DOTS server initiates a TLS connection to the DOTS client. The Happy Eyeballs mechanism explained in Section 4.3 of [I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS connections. 2. Using this (D)TLS connection, the DOTS client may request, withdraw, or retrieve the status of mitigation requests. -3.2. DOTS Signal Channel Extension +3.2. Heartbeat Mechanism -3.2.1. Mitigation Request + The Heartbeat mechanism used for the Call Home deviates from the one + defined in Section 4.7 of [I-D.ietf-dots-signal-channel]. This + section specifies the behavior to be followed by DOTS agents for the + Call Home. + + Once the (D)TLS section is established between the DOTS agents, the + DOTS client contacts the DOTS server to retrieve the session + configuration parameters (Section 4.5 of + [I-D.ietf-dots-signal-channel]). The DOTS server adjusts the + 'heartbeat-interval' to accommodate binding timers used by on-path + NATs and firewalls. Heartbeats will be then exchanged by the DOTS + agents following the instructions retrieved using the signal channel + session configuration exchange. + + It is the responsibility of DOTS servers to ensure that on-path + translators/firewalls are maintaining a binding so that the same + external IP address and/or port number is retained for the DOTS + signal channel session. A DOTS client MAY trigger their heartbeat + requests immediately after receiving heartbeat probes from its peer + DOTS server. + + When an outgoing attack that saturates the outgoing link from the + DOTS server is detected and reported by a DOTS client, the latter + MUST continue to use the signal channel even if no traffic is + received from the DOTS server. It is most likely that the outgoing + traffic is exceeding the DOTS server domain capacity. As a reminder, + the DOTS client cannot initiate a (D)TLS connection. + + If the DOTS server receives traffic from the DOTS client, the DOTS + server MUST continue to use the signal channel even if the missing + heartbeat allowed threshold is reached. + + If the DOTS server does not receive any traffic from the peer DOTS + client, the DOTS server sends heartbeat requests to the DOTS client + and after maximum 'missing-hb-allowed' threshold is reached, the DOTS + server concludes the session is disconnected. Then, the DOTS server + MUST try to resume the (D)TLS session. + +3.3. DOTS Signal Channel Extension + +3.3.1. Mitigation Request This specification extends the mitigation request defined in Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the attacker source prefixes and source port numbers. The DOTS client conveys the following new parameters in the CBOR body of the mitigation request: source-prefix: A list of attacker prefixes used to attack the target. Prefixes are represented using Classless Inter-Domain Routing (CIDR) notation [RFC4632]. @@ -399,115 +439,149 @@ information because 'target-uri' and 'target-fqdn' are optional attributes and 'alias-name' will not be conveyed in a mitigation request. In order to help attack source identification by a DOTS server, the DOTS client SHOULD include in its mitigation request additional information such as 'source-port-range' or 'source-icmp-type-range'. The DOTS client may not include such information if 'source-prefix' conveys an IPv6 address/prefix. + Only immediate mitigation requests (i.e., 'trigger-mitigation' set to + 'true') are allowed; DOTS clients MUST NOT send requests with + 'trigger-mitigation' set to 'false'. Such requests MUST be discarded + by the DOTS server with a 4.00 (Bad Request). + If a Carrier Grade NAT (CGN, including NAT64) is located between the DOTS client domain and DOTS server domain, communicating an external IP address in a mitigation request is likely to be discarded by the DOTS server because the external IP address is not visible locally to the DOTS server (see Figure 3). The DOTS server is only aware of the internal IP addresses/prefixes bound to its domain. Thus, the DOTS client MUST NOT include the external IP address and/or port number identifying the suspect attack source, but MUST include the internal IP address and/or port number. To that aim, the DOTS client SHOULD rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the internal IP address and port number which are mapped to an external IP address and port number. N | .-------------------. E | ( )-. T | .' ' W | ( ) - O | ( DOTS server -' + O | ( DOTS client -' R | '-( ) K | '-------+-----------' | | P | | R | +---+---+ O | | CGN | External Realm - V |..............|.......|...................... - I | | | Internel Realm + V |..............| |...................... + I | | | Internal Realm D | +---+---+ E | | R | | --- | .---------+---------. ( )-. .' Source Network ' ( ) - ( DOTS client -' + ( DOTS server -' '-( ) '------+------------' | +-----+-------+ |Attack Source| +-------------+ - Figure 3: Example of a CGN Between DOTS Domains + Figure 3: Example of a CGN between DOTS Domains If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the provider's domain to service its customers, the identification of an attack source bound to an IPv4 address/prefix MUST also rely on source port numbers because the same IPv4 address is assigned to multiple customers. The port information is required to unambiguously identify the source of an attack. The DOTS server MUST check that the 'source-prefix' is within the scope of the DOTS server domain in the Call Home scenario. Note that in such scenario, the DOTS server considers, by default, that any routeable IP prefix enclosed in 'target-prefix' is within the scope of the DOTS client. Invalid mitigation requests are handled as per Section 4.4.1 of [I-D.ietf-dots-signal-channel]. If a translator is enabled on the boundaries of the domain hosting - the DOTS server (a CPE with NAT enabled as shown in Figure 4, - typically), the DOTS server uses the attack traffic information - conveyed in a mitigation request to find the internal source IP - address of the compromised device and blocks the traffic from the - compromised device traffic to the attack target until the mitigation - request is withdrawn. Doing so allows to isolate the suspicious - device while avoiding to disturb other services. + the DOTS server (e.g., a CPE with NAT enabled as shown in Figures 4 + and 5), the DOTS server uses the attack traffic information conveyed + in a mitigation request to find the internal source IP address of the + compromised device and blocks the traffic from the compromised device + traffic to the attack target until the mitigation request is + withdrawn. Doing so allows to isolate the suspicious device while + avoiding to disturb other services. .-------------------. ( )-. .' Network Provider ' ( (DMS) ) - ( DOTS server -' + ( DOTS client -' '-( ) '------+------------' | | --- +--+----+ S | | CPE | External Realm - O |..............|.......|................ - U | | NAT | Internel Realm + O |..............| |................ + U | | NAT | Internal Realm R | +-------+ C | | E | .--------+----------. | ( )-. N | .' ' E | ( ) - T | ( DOTS client -' + T | ( DOTS server -' W | '-( ) O | '------+------------' R | | K | +-----+-------+ | |Attack Source| +-------------+ - Figure 4: Example of a DOTS Client Domain with a NAT Embeded in a CPE + Figure 4: Example of a DOTS Server Domain with a NAT Embeded in a CPE + .-------------------. + ( )-. + .' Network Provider ' + ( (DMS) ) + ( DOTS client -' + '-( ) + '---------+---------' + | + | + --- +-----+-----+ + S | | CPE/NAT | External Realm + O |..............| |................ + U | |DOTS server| Internal Realm + R | +-----------+ + C | | + E | .--------+----------. + | ( )-. + N | .' ' + E | ( Local Area Network ) + T | ( -' + W | '-( ) + O | '------+------------' + R | | + K | +-----+-------+ + | |Attack Source| + +-------------+ + + Figure 5: Example of a DOTS Server and a NAT Embeded in a CPE + The DOTS server domain administrator consent MAY be required to block the traffic from the compromised device to the attack target. An implementation MAY have a configuration knob to block the traffic from the compromised device to the attack target with or without DOTS server domain administrator consent. If the attack traffic is blocked, the DOTS server informs the DOTS client that the attack is being mitigated. If the attack traffic information is identified by the DOTS server or the DOTS server domain administrator as legitimate traffic, the @@ -525,42 +599,42 @@ The DOTS client is informed about the progress of the attack mitigation following the rules in [I-D.ietf-dots-signal-channel]. For example, if the DOTS server is embedded in a CPE, it can program the packet processor to punt all the traffic from the compromised device to the target to slow path. The CPE inspects the punted slow path traffic to detect and block the outgoing DDoS attack traffic or quarantine the device (e.g., using MAC level filtering) until it is remediated, and notifies the CPE administrator about the compromised device. -3.2.2. DOTS Signal Call Home YANG Module +3.3.2. DOTS Signal Call Home YANG Module -3.2.2.1. Tree Structure +3.3.2.1. Tree Structure This document augments the "dots-signal-channel" DOTS signal YANG module defined in [I-D.ietf-dots-signal-channel] for signaling the attack traffic information. This document defines the YANG module "ietf-dots-call-home", which has the following tree structure: module: ietf-dots-call-home augment /ietf-signal:dots-signal/ietf-signal:message-type /ietf-signal:mitigation-scope/ietf-signal:scope: +--rw source-prefix* inet:ip-prefix {source-signaling}? +--rw source-port-range* [lower-port] {source-signaling}? | +--rw lower-port inet:port-number | +--rw upper-port? inet:port-number +--rw source-icmp-type-range* | [lower-type] {source-signaling}? +--rw lower-type uint8 +--rw upper-type? uint8 -3.2.2.2. YANG Module +3.3.2.2. YANG Module This module uses the common YANG types defined in [RFC6991]. file "ietf-dots-call-home@2019-04-25.yang" module ietf-dots-call-home { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; prefix call-home; @@ -575,27 +649,27 @@ "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; } organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; contact "WG Web: WG List: - Editor: Konda, Tirumaleswar Reddy + Author: Konda, Tirumaleswar Reddy ; - Editor: Mohamed Boucadair + Author: Mohamed Boucadair ; - Editor: Jon Shallow + Author: Jon Shallow "; description "This module contains YANG definitions for the signaling messages exchanged between a DOTS client and a DOTS server for the Call Home deployment scenario. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. @@ -754,44 +829,44 @@ Name: ietf-call-home Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home Maintained by IANA: N Prefix: call-home Reference: RFC XXXX 5. Security Considerations This document deviates from classic DOTS signal channel usage by - having the DOTS server initiate the TLS or DTLS connection. DOTS - signal channel related security considerations discussed in - Section 10 of [I-D.ietf-dots-signal-channel] MUST be considered. - DOTS agents MUST authenticate each other using (D)TLS before a DOTS - signal channel session is considered valid. + having the DOTS server initiate the (D)TLS connection. DOTS signal + channel related security considerations discussed in Section 10 of + [I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST + authenticate each other using (D)TLS before a DOTS signal channel + session is considered valid. An attacker may launch a DoS attack on the DOTS client by having it perform computationally expensive operations, before deducing that the attacker doesn't possess a valid key. For instance, in TLS 1.3 [RFC8446], the ServerHello message contains a Key Share value based on an expensive asymmetric key operation for key establishment. Common precautions mitigating DoS attacks are recommended, such as temporarily blacklisting the source address after a set number of unsuccessful authentication attempts. DOTS servers may not blindly trust mitigation requests from DOTS clients. For example, DOTS servers can use the attack flow information in a mitigation request to enable full-fledged packet inspection function to inspect all the traffic from the compromised to the target or to re-direct the traffic from the compromised device to the target to a DDoS mitigation system to scrub the suspicious traffic. DOTS servers can also seek the consent of DOTS server domain administrator to block the traffic from the compromised device - to the target (see Section 3.2.1). + to the target (see Section 3.3.1). 6. Privacy Considerations The considerations discussed in [RFC6973] were taken into account to assess whether the DOTS Call Home extension introduces privacy threats. Concretely, the protocol does not leak any new information that can be used to ease surveillance. In particular, the DOTS server is not required to share information that is local to its network (e.g., @@ -809,21 +884,21 @@ The DOTS Call Home extension is only advisory in nature. Concretely, the DOTS Call Home extension does not impose any action to be enforced within the home network; it is up to the DOTS server (and/or network administrator) to decide whether and which actions are required. Moreover, the DOTS Call Home extension avoids misattribution by appropriately identifying the network to which a suspect attack source belongs to (e.g., address sharing issues discussed in - Section 3.2.1). + Section 3.3.1). Triggers to send a DOTS mitigation request to a DOTS server are deployment-specific. For example, a DOTS client may rely on the output of some DDoS detection systems deployed within the DOTS client domain to detect potential outbound DDoS attacks or on abuse claims received from remote victim networks. Such DDoS detection and mitigation techniques are not meant to track the activity of users, but to protect the Internet and avoid altering the IP reputation of the DOTS client domain. @@ -845,22 +920,21 @@ Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 9. References 9.1. Normative References [I-D.ietf-dots-signal-channel] K, R., Boucadair, M., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", draft- - ietf-dots-signal-channel-31 (work in progress), March - 2019. + ietf-dots-signal-channel-34 (work in progress), May 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . @@ -892,37 +966,31 @@ Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 (work in progress), January 2019. [I-D.ietf-dots-requirements] Mortensen, A., K, R., and R. Moskowitz, "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements", draft-ietf-dots-requirements-22 (work in progress), March 2019. [I-D.ietf-dots-server-discovery] - Boucadair, M., K, R., and P. Patil, "Distributed-Denial- - of-Service Open Threat Signaling (DOTS) Server Discovery", - draft-ietf-dots-server-discovery-01 (work in progress), - April 2019. + Boucadair, M. and R. K, "Distributed-Denial-of-Service + Open Threat Signaling (DOTS) Server Discovery", draft- + ietf-dots-server-discovery-03 (work in progress), May + 2019. [I-D.ietf-dots-use-cases] Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", draft-ietf-dots-use-cases-17 (work in progress), January 2019. - [I-D.irtf-t2trg-iot-seccons] - Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- - the-Art and Challenges for the Internet of Things - Security", draft-irtf-t2trg-iot-seccons-16 (work in - progress), December 2018. - [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . @@ -975,22 +1043,26 @@ Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, DOI 10.17487/RFC8513, January 2019, . [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. Jacquenet, "An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective", RFC 8517, DOI 10.17487/RFC8517, February 2019, . -Authors' Addresses + [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of + Things (IoT) Security: State of the Art and Challenges", + RFC 8576, DOI 10.17487/RFC8576, April 2019, + . +Authors' Addresses Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India Email: kondtir@gmail.com Mohamed Boucadair Orange