Network Working Group G. Nakibly
Internet-Draft National EW Research &
Updates: 3056, 5214 Simulation Center
(if approved) F. Templin, Ed.
Intended status: Informational Boeing Research & Technology
Expires: August 5, 2010 February 1, 2010
Routing Loops using ISATAP and 6to4: Problem Statement and Proposed
Solutions
draft-nakibly-v6ops-tunnel-loops-01.txt
Abstract
This document is concerned with security vulnerabilities in the
ISATAP and 6to4 tunnels. These vulnerabilities allow an attacker to
take advantage of inconsistencies between a tunnel's overlay IPv6
routing state and the native IPv6 routing state. The attacks form
routing loops which can be abused as a vehicle for traffic
amplification to facilitate DoS attacks. We describe these security
vulnerabilities and the attacks which exploit them. We further
recommend on solutions to remove the vulnerabilities.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 5, 2010.
Copyright Notice
Nakibly & Templin Expires August 5, 2010 [Page 1]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
Copyright (c) 2010 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
(http://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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Detailed Descriptions of the Attacks . . . . . . . . . . . . . 3
2.1. Attack #1: 6to4 Relay to ISATAP Router . . . . . . . . . . 4
2.2. Attack #2: ISATAP Router to 6to4 Relay . . . . . . . . . . 5
2.3. Attack #3: ISATAP Router to ISATAP Router . . . . . . . . 6
3. Recommended Solutions . . . . . . . . . . . . . . . . . . . . 7
3.1. Destination and Source Address Check . . . . . . . . . . . 7
3.1.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 8
3.2. Neighbor Cache Check . . . . . . . . . . . . . . . . . . . 9
3.3. Known IPv4 Address Check . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Nakibly & Templin Expires August 5, 2010 [Page 2]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
1. Introduction
Recent research [USENIX09] has pointed out the existence of some
security vulnerabilities in the design of the automatic tunnels
ISATAP [RFC5214] and 6to4 [RFC3056]. These vulnerabilities allow a
specially crafted packet to loop back and forth between ISATAP
routers or 6to4 relays thereby overloading them.
In automatic tunnels a packet's egress node's IPv4 address is
computationally derived from the destination IPv6 address of the
packet. This feature eliminates the need to keep an explicit routing
table at the tunnel's end points. In particular, the end points do
not have to be updated as peers join and leave the tunnel. In fact,
the end points of an automatic tunnel do not know which other end
points are currently part of the tunnel. However, all end points
operate on the implicit assumption that once a packet arrives at the
tunnel, its destination indeed is part of the tunnel. This
assumption poses a security vulnerability since it may result in an
inconsistency between a tunnel's overlay IPv6 routing state and the
native IPv6 routing state there by allowing a routing loop to be
formed.
An attacker can exploit this vulnerability by crafting a packet which
is routed over a tunnel to a node that is not participating in that
tunnel. This node may forward the packet out of the tunnel to a
native IPv6 network. In that network, the packet is routed back to
the ingress point that forwards it back into the tunnel.
Consequently, the packet will loop in and out of the tunnel.
A loop terminates only when the Hop Limit field in the IPv6 header of
the packet is zeroed out. The maximum value that can be assigned to
this field is 255. Note that when the packet is tunneled over IPv4
routers, the Hop Limit does not decrease. Every attack packet will
traverse each hop along the loop 255/N times, where N is the number
of IPv6 routers on the loop. As a result, the loops can be used as
traffic amplification tools with a ratio of 255/N. The number of IPv6
routers on the loop is determined by the positions of the two
victims. The closer the two victims are, the larger the
amplification ratio will be.
2. Detailed Descriptions of the Attacks
For the sake of completeness, this section details the three attacks
from [USENIX09] that exemplify how the security vulnerability
described above may be exploited.
Nakibly & Templin Expires August 5, 2010 [Page 3]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
2.1. Attack #1: 6to4 Relay to ISATAP Router
The two victims of this attack are a 6to4 relay and an ISATAP router.
Let IPa and IPb denote the IPv4 address of the ISATAP router and the
6to4 relay, respectively. Let Prfa denote the IPv6 64-bit prefix of
the ISATAP tunnel. The attack is depicted in Figure Figure 1. It is
initiated by sending an IPv6 packet (packet 0 in Figure Figure 1) to
a 6to4 destination address with an embedded router address of IPa,
i.e., the destination address begins with 2002:IPa::/48. The source
address of the packet is an ISATAP address with Prfa as the prefix
and IPb as the embedded IPv4 address. As the destination address is
6to4, the packet will be routed over the IPv6 network to the closest
6to4 relay. The relay receives the packet through its IPv6 interface
and processes it as a normal IPv6 packet that needs to be delivered
to the appropriate 6to4 site. Hence, the packet is forwarded over
the relay's IPv4 interface with an IPv4 header having a destination
address derived from the IPv6 destination, i.e., IPa. The source
address is the address of the 6to4 relay, IPb. The packet (packet 1
in Figure Figure 1.) is routed over the IPv4 network to the ISATAP
router. The router receives the packet on its IPv4 interface. It
processes the packet as a regular IPv4 packet that originates from
one of the end points of the ISATAP tunnel. Since the IPv4 source
address corresponds to the IPv6 source address, the packet will be
decapsulated. Since the packet's IPv6 destination is outside the
ISATAP tunnel, the packet will be forwarded onto the native IPv6
interface. The forwarded packet (packet 2 in Figure Figure 1.) is
identical to the original attack packet. Hence, it will be routed
back to the closest 6to4 relay, in which the loop will start again.
ISATAP Router 6to4 Relay
(IPa) (IPb)
| | 0
| 1 |<------
|<===============|
| 2 |
|--------------->|
| . |
| . |
1 - IPv4: IPb --> IPa
IPv6: Prfa::0200:5EFE:IPb --> 2002:IPa:*
0,2- IPv6: Prfa::0200:5EFE:IPb --> 2002:IPa:*
Legend: ====> - tunneled IPv6, ---> - native IPv6
Figure 1: Attack #1: 6to4 Relay to ISATAP Router
Nakibly & Templin Expires August 5, 2010 [Page 4]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
2.2. Attack #2: ISATAP Router to 6to4 Relay
The two victims in this attack are again a 6to4 relay and an ISATAP
router, but here they have swapped roles. This time the ISATAP
router accepts the attack packet and forwards it on its ISATAP tunnel
to the 6to4 relay, which decapsulates it and forwards it back to the
ISATAP router on the IPv6 network. Let IPa, IPa and Prfa be the same
as above. The attack is depicted in Figure Figure 2. This attack is
initiated by sending an IPv6 packet (packet 0 in Figure Figure 2)
with a destination ISATAP address having Prfa as the prefix and IPb
as the embedded IPv4 address. The source address of the packet is a
6to4 address with a router having the IPa address , i.e., the
destination address begins with 2002:IPa::/48. The packet will be
routed over the IPv6 network to the ISATAP router. The router
receives the packet through its IPv6 interface and processes it as a
normal IPv6 packet that needs to be delivered to the appropriate end
point in the ISATAP tunnel. Hence, the packet is forwarded over the
router's IPv4 interface with an IPv4 encapsulation having a
destination address derived from the IPv6 destination , i.e., IPb.
The source address is the address of the ISATAP router, IPa. The
packet (packet 1 in Figure Figure 2) is routed over the IPv4 network
to the 6to4 relay. The relay receives the packet on its IPv4
interface. It processes the packet as a normal IPv4 packet that
originates from one of the end points of the 6to4 tunnel. Since the
IPv4 source address corresponds to the IPv6 source address, the
packet will be admitted and decapsulated. Since the packet's IPv6
destination is outside the 6to4 tunnel, the packet will be forwarded
out on the native IPv6 interface. The forwarded packet (packet 2 in
Figure Figure 2) is identical to the original attack packet. Hence,
it will be routed back to the ISATAP router, in which the loop will
start again.
Nakibly & Templin Expires August 5, 2010 [Page 5]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
ISATAP Router 6to4 Relay
(IPa) (IPb)
0 | |
----->| 1 |
|===============>|
| 2 |
|<---------------|
| . |
| . |
1 - IPv4: IPa --> IPb
IPv6: 2002:IPa:* --> Prfa::0200:5EFE:IPb
0,2- IPv6: 2002:IPa:* --> Prfa::0200:5EFE:IPb
Legend: ====> - tunneled IPv6, ---> - native IPv6
Figure 2: Attack #2: ISATAP Router to 6to4 Relay
2.3. Attack #3: ISATAP Router to ISATAP Router
The two victims in this attack are two ISATAP routers -- router A and
router B -- having addresses IPa and IPb, respectively. Let Prfa and
Prfb be the prefixes of the ISATAP tunnels of router A and router B,
respectively. Note that the two routers do not participate in the
same ISATAP tunnel. However, they may reside at the same or
different sites. The attack is depicted in Figure Figure 3. It is
initiated by sending an IPv6 packet (packet 0 in Figure Figure 3)
with a destination ISATAP address having Prfa as the prefix and IPb
as the embedded IPv4 address. The source address of the packet is an
ISATAP address having Prfb as the prefix and IPa as the embedded IPv4
address. The packet will be routed over the IPv6 network to router
A. The router receives the packet through its IPv6 interface and
processes it as a normal IPv6 packet that needs to be delivered to
the appropriate end point of its ISATAP tunnel. The fact that the
source address is also an ISATAP address does not matter here; the
important thing is that the packet originated outside of the tunnel
A. Hence, the packet is forwarded over the router's IPv4 interface
with an IPv4 encapsulation having a destination address derived from
the IPv6 destination , i.e., IPb. The source address is the address
of the router A, IPa. The packet (marked with 1 in Figure Figure 3)
is routed over the IPv4 network to router B. The router receives the
packet on its IPv4 interface. It processes the packet as a regular
IPv4 packet that originates from one of the end points of its tunnel.
Since the IPv4 source address corresponds to the IPv6 source address,
the packet will be decapsulated. The packet's IPv6 destination is
outside of router B's tunnel; hence the packet is forwarded out onto
the IPv6 interface. The forwarded packet (packet 2 in Figure
Figure 3) is identical to the original attack packet. Hence, it will
Nakibly & Templin Expires August 5, 2010 [Page 6]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
be routed back to router A, in which the loop will start again.
The attack can also be launched on two ISATAP routers having private
IPv4 addresses in th same IPv4 routing region.
ISATAP Router ISATAP Router
(IPa) (IPb)
0 | |
----->| 1 |
|===============>|
| 2 |
|<---------------|
| . |
| . |
1 - IPv4: IPa --> IPb
IPv6: Prfb::0200:5EFE:IPa --> Prfa::0200:5EFE:IPb
0,2- IPv6: Prfb::0200:5EFE:IPa --> Prfa::0200:5EFE:IPb
Legend: ====> - tunneled IPv6, ---> - native IPv6
Figure 3: Attack #3: ISATAP Router to ISATAP Router
3. Recommended Solutions
This section describes the recommended solutions that mitigate the
attacks above. For each solution we shall discuss its advantages and
disadvantages.
3.1. Destination and Source Address Check
Tunnel routers can use a source address check mitigation when they
forward an IPv6 packet into a tunnel interface with an IPv6 source
address that embeds one of the router's configured IPv4 addresses.
Similarly, tunnel routers can use a destination address check
mitigation when they receive an IPv6 packet on a tunnel interface
with an IPv6 destination address that embeds one of the router's
configured IPv4 addresses. These checks should correspond to both
tunnels' IPv6 address formats, regardless of the type of tunnel the
router employs.
For example, if tunnel router A (ISATAP router or 6to4 relay)
forwards a packet into a tunnel interface with an IPv6 source address
that matches the 6to4 prefix 2002:IPa::/48, the router discards the
packet if IPa is one of its own IPv4 addresses. In a second example,
if tunnel router B (ISATAP router or 6to4 relay) receives an IPv6
packet on a tunnel interface with an IPv6 destination address that
Nakibly & Templin Expires August 5, 2010 [Page 7]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
matches the ISATAP address suffix ::0200:5EFE:IPb, the router
discards the packet if IPb is one of its own IPv4 addresses. In both
of these examples, the router can unambiguously check the addresses
IPa and IPb since both are known to be public IPv4 addresses by
definition of the 6to4 and ISATAP address formats. However, the
router cannot perform the simple check if the embedded IPv4 address
is a private one [RFC1918] since it is ambiguous in scope. This
reservation is relevant only to attacks of type #3 (a loop between
two ISATAP routers) since the other two types of attack involves a
6to4 tunnel which always embeds public IPv4 addresses.
When a tunnel router (ISATAP, 6to4) has a way of knowing whether an
embedded IPv4 address is one of its own addresses, it can avoid the
routing loop attack scenarios depicted in Figures 1, 2 and 3 by
performing the following simple checks:
o When the router forwards an IPv6 packet into a tunnel interface,
it discards the packet if the IPv6 source address is not one of
the router's configured IPv6 addresses but embeds one of the
router's configured IPv4 addresses.
o When the router receives an IPv6 packet on a tunnel interface, it
discards the packet if the IPv6 destination address is not one of
the router's configured IPv6 addresses but embeds one of the
router's configured IPv4 addresses.
This approach can be employed by an ISATAP router or 6to4 relay. As
noted above the router must perform the embedded IPv4 address
inspections for both ISATAP and 6to4 IPv6 address formats even if the
router does not implement one of those tunnels. This approach has
the advantage that it is easy to implement and that no ancillary
state is required, since checking is through static lookup in the
lists of IPv4 and IPv6 addresses belonging to the router.
As noted above, this simple approach alone cannot be used when the
embedded IPv4 address in the ISATAP address is private, because the
address may be legitimately allocated to another node in another
routing region. To apply this check the router must first
unambiguously determine the scope of the address. The following
check serves this purpose.
3.1.1. Known IPv6 Prefix Check
The known IPv6 prefix check is tied to the conceptual ISATAP link
model. It observes that an ISATAP link spans a portion of a
connected IPv4 routing region up to (but not beyond) the entire
connected IPv4 routing region itself. For example, if there were no
physical or logical segmentations (e.g., enterprise network border
Nakibly & Templin Expires August 5, 2010 [Page 8]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
gateways) the entire public IPv4 Internet would be spanned by a
single ISATAP link. Similarly, a private IPv4 address routing region
can be spanned by one or more ISATAP links that are distinct from the
links that span other private IPv4 routing regions.
Each IPv4 routing region can be segmented through logical or physical
segmentation, e.g., through ip-proto-41 filters, firewalls, etc. In
that case, each distinct segment is spanned by a distinct ISATAP
link. As for any links, multiple distinct ISATAP links can be joined
together by bridges or IPv6 routers.
Each ISATAP link configures a set of IPv6 subnet prefixes, where each
subnet prefix spans either the entire link or only a portion of the
link. Therefore, if the router can determine the full list of IPv6
subnet prefixes assigned to ISATAP interfaces attached to the link,
it can use the list to determine when static destination and source
address checks are necessary. By keeping track of the list of IPv6
prefixes assigned to ISATAP interfaces connected to the link, an
ISATAP router can perform the following checks on an ISATAP address
which embeds a private IPv4 address:
o When the ISATAP router forwards an IPv6 packet into an ISATAP
interface with a source address that matches an IPv6 prefix in the
on-link prefix list, it determines whether the packet should be
discarded or forwarded by performing the source address check
specified in Section 3.1. Otherwise, the router forwards the
packet.
o When the ISATAP router receives an IPv6 packet on an ISATAP
interface with a destination address that matches an IPv6 prefix
in the on-link prefix list, it determines whether the packet
should be discarded or accepted by performing the destination
address check specified in Section 3.1. Otherwise, the router
accepts the packet.
The disadvantage of this approach is the administrative overhead for
maintaining the list of IPv6 subnet prefixes associated with an
ISATAP link may become unwieldy should that list be long and/or
frequently updated.
3.2. Neighbor Cache Check
The neighbor cache check mitigation observes that the routing loop
attack scenarios depicted in Figures 1, 2 and 3 specifically target
the ISATAP IPv6 on-link subnet model. In this approach, hosts
configure IPv6 addresses and assign IPv6 subnet prefixes on an ISATAP
interface based on the Prefix Information Options included in the
unicast Router Advertisement (RA) messages they receive from routers.
Nakibly & Templin Expires August 5, 2010 [Page 9]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
Moreover, ISATAP hosts must first send Router Solicitation (RS)
messages to routers in order to elicit these RAs since the ISATAP
link model is Non-Broadcast, Multiple Access (NBMA). Therefore,
ISATAP routers can keep track of the hosts from which they have
recently received RS messages by maintaining entries in their ISATAP
interface neighbor cache that are keyed on the IPv6 unicast link-
local source addresses received in the RS messages. The ISATAP
router can then determine which hosts are willing participants in the
ISATAP IPv6 on-link subnets.
By keeping track of the hosts that have recently sent RS messages, an
ISATAP router can perform the following simple checks:
o When the ISATAP router forwards a packet into an ISATAP interface
with an IPv6 destination address that matches a non-link-local
prefix assigned to the interface and that embeds the IPv4 address
IPa, it discards the packet if there is no corresponding neighbor
cache entry for the interface keyed on an IPv6 unicast link-local
address that embeds the IPv4 address IPa.
o When the ISATAP router receives a packet on an ISATAP interface
with an IPv6 source address that matches a non-link-local prefix
assigned to the interface and embeds the IPv4 address IPb, it
discards the packet if there is no corresponding neighbor cache
entry for the interface keyed on an IPv6 unicast link-local
address that embeds the IPv4 address IPb.
This approach can only be employed by an ISATAP router. It has the
advantage that the ISATAP router discards only those IPv6 packets
that could cause the looping conditions, i.e., those packets with
source and/or destination addresses taken from an ISATAP IPv6 on-link
subnet prefix but for which no corresponding neighbor cache entry
exists. In contrast, other approaches could in some cases discard
IPv6 packets that pertain to legitimate communications. The approach
is also easy to implement, and naturally leverages the relationship
between the router's advertised prefix lifetimes and the interval
between the host's successive RS transmissions according to the
specifications in [RFC5214].
This approach requires the ISATAP router to maintain a neighbor cache
with entries created or updated by the reception of ISATAP host RS
messages. These entries must be retained for a duration that is at
least as long as the router's advertised prefix lifetimes, i.e., even
if the entries transition into the STALE state. This may require an
implementation to adjust its garbage-collection interval for stale
neighbor cache entries. The approach further requires that hosts
perform the RS/RA exchanges specified in Section 8.3.4 of [RFC5214],
i.e., the host-initiated RS/RA exchanges must be performed. Finally,
Nakibly & Templin Expires August 5, 2010 [Page 10]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
this approach assumes that the neighbor cache will remain coherent
and not subject to malicious attack, which must be confirmed based on
specific deployment scenarios. One possible way for an attacker to
subvert the neighbor cache is to send false RS messages with a
spoofed source address.
3.3. Known IPv4 Address Check
The known IPv4 address check method observes that each on-link IPv6
subnet prefix on an ISATAP interface is configured over a limited set
of IPv4 addresses, since each ISATAP Potential Router List will be
used only by a finite set of hosts. Therefore, only those hosts
configured from a subset of the IPv4 addresses in an IPv4 routing
region are authorized to configure IPv6 addresses and subnet prefixes
advertised by a given ISATAP router. By keeping track of the set of
IPv4 addresses that are authorized to use an ISATAP on-link IPv6
subnet, an ISATAP router can perform the following simple checks:
o When the ISATAP router forwards an IPv6 packet into an ISATAP
interface with a destination address that matches a non-link-local
prefix assigned to the interface and that embeds the IPv4 address
IPa, it discards the packet if IPa does not belong to the list of
IPv4 addresses over which the ISATAP on-link IPv6 subnet is
configured.
o When the ISATAP router receives an IPv6 packet on an ISATAP
interface with a source address that matches a non-link-local
prefix assigned to the interface and that embeds the IPv4 address
IPb, it discards the packet if IPb does not belong to the list of
IPv4 addresses over which the ISATAP on-link IPv6 subnet is
configured.
This approach can only be employed by an ISATAP router, and offers a
close analogy to the neighbor cache check discussed in Section 3.2.
Indeed, one possible interpretation of this approach is that the
router should simply cache the IPv4 addresses of hosts that have sent
it an RS message. In this interpretation, the only difference
between this approach and the neighbor cache check discussed in
Section 3.2 is the nature of the internal data structure used to
store the IPv4 addresses, which is likely to be an implementation
detail. Therefore, the same set of advantages and disadvantages as
described in Section 3.2 apply.
Alternatively, the ISATAP router could pre-configure a static list of
known IPv4 host addresses. This list would be discovered through
some unspecified means (e.g., manual configuration), and would serve
as a "Potential Host List (PHL)" for the ISATAP interface.
Nakibly & Templin Expires August 5, 2010 [Page 11]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
4. IANA Considerations
This document has no IANA considerations.
5. Security Considerations
This document aims at mitigating routing loops which involves ISATAP
routers and 6to4 relays. It contains various checks that aim to
recognize and drop specific packets that have strong potential to
cause a routing loop. These checks does not introduce new security
threats.
6. Acknowledgments
This work has benefited from discussions on the V6OPS, 6MAN and
SECDIR mailing lists. Remi Despres and Christian Huitema are
acknowledged for their contributions.
7. References
7.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
7.2. Informative References
[USENIX09]
Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6
Tunnels", USENIX WOOT, August 2009.
Nakibly & Templin Expires August 5, 2010 [Page 12]
Internet-Draft ISATAP and 6to4 Routing Loops February 2010
Authors' Addresses
Gabi Nakibly
National EW Research & Simulation Center
P.O. Box 2250 (630)
Haifa 31021
Israel
Email: gnakibly@yahoo.com
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Nakibly & Templin Expires August 5, 2010 [Page 13]