| TOC |
|
The objective of this document is to describe one method of providing notifications to web browsers that has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system can be used by an ISP to provide near-immediate notifications to their users, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection, for example. There are other proprietary systems that can perform such notifications but these systems utilize Deep Packet Inspection (DPI) technology. This document describes one example of a system that does not rely upon DPI, and is instead based in open standards and open source applications. While the system described herein is in some ways specific to the Data-Over-Cable Service Interface Specifications (DOCSIS) networks used by most cable-based broadband ISPs, components and concepts described in this document could generally be applied to many different types of networks.
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 September 30, 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.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
1.
Requirements Language
2.
Introduction
3.
High-Level Design of the System
4.
Design Requirements
4.1.
General
4.2.
Web Proxy
4.3.
ICAP Server
4.4.
Messaging Service
5.
Functional Overview
5.1.
Functional Components Described
5.2.
Functional Diagram
6.
High Level Communication Flow
7.
Communication Between Web Proxy and ICAP Server
8.
End-to-End Web Notification Flow
8.1.
Step-by-Step Description of the End-to-End Web Notification Flow
8.2.
Diagram of the End-to-End Web Notification Flow
9.
Example HTTP Headers and JavaScript for a Web Notification
10.
Deployment Considerations
11.
Security Considerations
12.
IANA Considerations
13.
Acknowledgements
14.
References
14.1.
Normative References
14.2.
Informative References
Appendix A.
Document Change Log
§
Authors' Addresses
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
| TOC |
Internet Service Providers (ISPs) have a need for a system that is capable of communicating with customers in a nearly immediate manner, to convey critical service notices such as warnings concerning likely malware infection. Given the prevalence of the web browser as the predominant client software in use by Internet users, the web browser is an ideal vehicle for providing notifications. This document describes a system that has been deployed by Comcast, a broadband ISP, to provide near-immediate notifications to web browsers. This type of system is also designed to provide a non-intrusive, though obvious, notification to a user's web browser.
In evaluating potential solutions, most commercially available systems were either proprietary and/or utilized inline-based Deep Packet Inspection (DPI) technology. Other ISPs may also desire to use a system based on open standards, non-proprietary software, and which does not require the use of DPI, which is one of the motivations for producing this document. While the system described herein is specific to the Data-Over-Cable Service Interface Specifications (DOCSIS, [CableLabs DOCSIS] (CableLabs, “Data-Over-Cable Service Interface Specifications,” .)) networks used by most cable-based broadband ISPs, components and concepts described in this document can generally be applied to many different types of networks.
| TOC |
The web notification system design is based on the use of the Internet Content Adaptation Protocol [RFC3507] (Elson, J. and A. Cerpa, “Internet Content Adaptation Protocol (ICAP),” April 2003.). The design uses open source applications such as Squid Web Proxy, GreasySpoon ICAP server, and Apache Tomcat. The ICAP protocol allows for message transformation or adaptation. An ICAP client passes a HyperText Transport Protocol (HTTP, [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.)) response to an ICAP server for content adaption. The ICAP Server in turn responds back to the client with the HTTP response containing the notification message.
Message modification itself may then be provided via either a HTTP request or HTTP response. However, for the specific system described in this document, only the HTTP response is modified, by using the 'respmod' method defined in Section 3.2 of [RFC3507] (Elson, J. and A. Cerpa, “Internet Content Adaptation Protocol (ICAP),” April 2003.).
| TOC |
This section describes all of the requirements taken into consideration for the design of this system.
| TOC |
- REQ1:
- TCP Port 80: The system should provide notifications via TCP port 80, the well-known port for HTTP traffic.
- REQ2:
- Whitelisting: It is possible that the HyperText Markup Language (HTML, [RFC1866] (Berners-Lee, T. and D. Connolly, “Hypertext Markup Language - 2.0,” November 1995.)) or JavaScript [RFC4329] (Hoehrmann, B., “Scripting Media Types,” April 2006.) used for notifications may cause problems while accessing a particular website. Therefore, such a system should be capable of using a whitelist of website Uniform Resource Indicators (URIs, [RFC2396] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” August 1998.)) or Fully Qualified Domain Named (FQDNs, Section 5.1 of [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)) that conflict with the system, to instruct the system to not provide a notifications related to certain sites, in order to reduce any errors or unexpected results.
- REQ3:
- Instant Messaging (IM): Some IM clients use TCP port 80 in their communications, often as an alternate port when standard, well-known ports do not work. This system should not conflict with or cause unexpected results for IM clients (or any other client types).
- REQ4:
- Handling of Active Sessions: To the extent that a web notification system must temporarily route TCP port 80 traffic in order to provide a notification, previously established TCP port 80 sessions should not be disrupted and should be routed to the proxy layer.
- REQ5:
- No TCP Resets: The use of TCP resets has been widely criticized, both in the Internet community generally as well as in [RFC3360] (Floyd, S., “Inappropriate TCP Resets Considered Harmful,” August 2002.). As such, except for the case of unintentional errors, the use of TCP resets must be avoided.
- REQ6:
- Non-Disruptive: The web notification system should not disrupt the end user experience, such as causing significant clients errors.
- REQ7:
- Notification Acknowledgement: Once a user responds and acknowledges a notification, the notification should immediately stop.
- REQ8:
- Non-Modification of Content: Such a system should not significantly alter the content of the HTTP response from any website the user is accessing.
- REQ9:
- Unexpected Content: The system should transparently handle traffic for which it cannot provide a web notification. Thus, widely varying content should be expected, and all such unexpected traffic should be able to be handled by the system without generating errors or unexpected results.
- REQ10:
- No Caching: Web content must not be cached by the system.
- REQ11:
- No Advertising Replacement or Insertion: The system must not be used to replace any advertising provided by a website, or insert advertising into websites where none was intended by the owner of a given website.
| TOC |
- REQ12:
- Open-Source Software: The system should use an open source web proxy server, such as Squid. (While it is possible to use any web proxy, the use of open source, and openly documented software is recommended.)
- REQ13:
- ICAP Client: The web proxy server should have an integrated ICAP client.
- REQ14:
- Access Control: Access to the proxy should be limited exclusively to the IP addresses of users for which notifications are intended, and only for limited periods of time. Furthermore, if a Session Management Broker (SMB) is utilized, as described in Section 5.1 (Functional Components Described) below, then the proxy should restrict access only to the address of the SMB.
| TOC |
- REQ15:
- Request and Response Support: The system should support both request and response adaptation.
- REQ16:
- Consistency: The system must be able to consistently provide a specific notification.
- REQ17:
- Multiple Notification Types: The system must be able to provide many different types of notifications.
- REQ18:
- Simultaneous Differing Notifications: The system must be able to simultaneously serve multiple notifications, including notifications of varying types, to different users. As a result, User A should be able to get the notification intended specifically for User A, at the same time that User B receives an entirely different notification, which was intended specifically for User B.
| TOC |
- REQ19:
- Messaging Service: The Messaging Service, as described in Section 5.1 (Functional Components Described) below caches the notifications for each specific user. Thus, by caching the notification messages, the system may provide notifications without significantly affecting the web browsing experience of the user.
- REQ20:
- Process Acknowledgements: The Messaging Service should process acknowledgements to properly remove entries from the cache and forward acknowledgements to the Messaging Service.
- REQ21:
- Ensure Notification Targeting Accuracy: The Messaging Service must ensure that notifications are presented to the intended users.
- REQ22:
- Keep Records for Customer Support: The Messaging Service should maintain some type of record that a notification has been presented and/or acknowledged, in case a user inquires with customer support personnel.
| TOC |
This section defines the various core functional components of the system. These components are then shown in a diagram to describe how the various components are linked and relate to one another.
| TOC |
Please note that when a specific software package is cited below, it is but one example of a possible selection for each component and should not be considered the only possible option. Though this accurately list describes the initial software packages used by the system described herein, those selections are subject to change for a variety of reasons.
- 5.1.A.
- Web Proxy: The system uses Squid Proxy, an open source web proxy application in wide use, and one which supports an integrated ICAP client.
- 5.1.B.
- ICAP Server: This should be an open source application capable of supporting content adaptation in both request and response modes. The ICAP Server retrieves the notifications from the Messaging service cache when content adaption is needed. The initial version of this system uses GreasySpoon, an open source application.
- 5.1.C.
- Customer Database: The Customer Database holds the user information including the notifications setup for each user. The database may also hold status of which users were notified and users pending notification.
- 5.1.D.
- Messaging Service: This is a process engine that retrieves specific web notification messages from a catalog of possible notifications. When a notification for a specific user is not in cache, the process retrieves this information from the Customer Database and populates the cache for a specific period of time. The initial version of this service uses Apache Tomcat, an open source application.
- 5.1.E.
- Session Management Broker: A Load Balancer (LB) with a customized layer 7 inspection policy is used to differentiate between HTTP and non-HTTP traffic on TCP port 80. The SMB functions as a full stateful TCP proxy with the ability to forward packets from existing TCP sessions that do not exist in the internal session table. New HTTP sessions are load balanced to the web proxy layer either transparently or using source Network Address Translation (NAT [RFC1631] (Egevang, K. and P. Francis, “The IP Network Address Translator (NAT),” May 1994.)) from the SMB, with additional layer 7 inspection as needed. Non-HTTP traffic for established TCP sessions not in the SMB session table is simply forwarded to the destination transparently via the TCP proxy layer.
| TOC |
+--------+ +------------+ +----------+
| ICAP | <----> | Messaging | <----> | Customer |
| Server | | Service | | Database |
+--------+ +------------+ +----------+
^
| +----------+
| | |
| +-------> | Internet | <-------+
| | | | |
| | +----------+ |
| | ^ |
v v | |
+----------+ v v
|+--------+| +-------+ +--------+
|| ICAP || <----> | SMB | <---> | Access |
|| Client || +-------+ | Router |
|+--------+| +--------+
|| SQUID || ^
|| Proxy || |
|+--------+| v
+----------+ +----------+
| Network |
| Element* |
+----------+
^
|
v
+------+
| PC |
+------+
* An access network element, such as a Cable Modem Termination
System (CMTS).
| Figure 1: Web Notification System - Functional Components |
| TOC |
- 6.A.
- Setup Differentiated Services (DiffServ): Using DiffServe [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.) [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.) [RFC2597] (Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, “Assured Forwarding PHB Group,” June 1999.) [RFC3140] (Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” June 2001.) [RFC3246] (Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, “An Expedited Forwarding PHB (Per-Hop Behavior),” March 2002.) [RFC3260] (Grossman, D., “New Terminology and Clarifications for Diffserv,” April 2002.) [RFC4594] (Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes,” August 2006.), set a policy to direct TCP port 80 traffic to the web notification system's web proxy.
- 6.B.
- Session Management: TCP port 80 packets are routed to a Session Management Broker which distinguishes between HTTP or non-HTTP traffic and between new and existing sessions. HTTP packets are forwarded to the web proxy by the SMB. Non-HTTP packets such as instant messaging (IM) traffic are forwarded to a TCP proxy layer for routing to destination or the SMB operates as the full TCP proxy and forwards the non-HTTP packets to the destination. Pre-established TCP sessions on port 80 are identified by the SMB and forwarded with no impact.
- 6.C.
- Web Proxy Forwards Request: The web proxy forwards the HTTP request on to the destination site, a web server, as a web proxy normally would do.
- 6.D.
- On Response, Send Message to ICAP Server: When the HTTP response is received from the destination server, the web proxy sends a message to the ICAP server for the web notification.
- 6.E.
- Messaging Service: The Messaging Service should respond with appropriate notification content or null response if notification is not cached.
- 6.F.
- ICAP Server Responds: The ICAP server responds and furnishes the appropriate content for the web notification to the web proxy.
- 6.G.
- Web Proxy Sends Response: The web proxy then forwards the HTTP response to the client web browser containing the web notification.
- 6.H.
- User Response: The user observes the web notification, and clicks an appropriate option, such as: OK/acknowledged, snooze/remind me later, etc.
- 6.I.
- More Information: Depending upon the notification, the user may be provided with more information. Using the example of a web notification to a user explaining that it is highly likely that they have been infected with a virus or malware, the user may click an acknowledgement that indicates that clicking that will take them to a page with information about virus/malware scanning and remediation.
- 6.J.
- Turn Down DiffServ: Once the notification transaction has completed, remove any special DiffServ settings.
| TOC |
+------------+ | www URI | +------------+ ^ | (2)| |(3) | v +--------+ (4) +--------+ (4) +--------+ | |------------>| |------------>| | | | (5) | | (5) | | | Proxy |<------------| ICAP |<------------| ICAP | | Module | (6) | Client | (6) | Server | | |------------>| |------------>| | | | (7) | | (7) | | | |<------------| |<------------| | +--------+ +--------+ +--------+ ^ | (1)| |(8) | v +------------+ (9) +------------+ | |----------------------------->| | | Browser | (10) | Web Server | | |<-----------------------------| | +------------+ +------------+ (1) - HTTP GET (TCP 80) (2) - Proxy HTTP GET (TCP 80) (3) - HTTP 200 OK w/ Response (4) - ICAP RESPMOD (5) - ICAP 200 OK (6) - TCP Stream - Encapsulate Header (7) - ICAP 200 OK Insert Message (8) - HTTP 200 OK w/ Response + Message Frame (9) - HTTP GET for Message (10) - HTTP 200 w/ Message Content
| Figure 2: Communication Between Web Proxy and ICAP Server |
| TOC |
| TOC |
8.1.1. Policy-Based Routing
8.1.2. Web Proxy
| TOC |
The two figures below show the communications flow from the Web Browser, through the Web Notification System.
The first figure below illustrates what occurs when a notification request cannot be inserted because the notification type for the user's IP address is not cached in the Messaging Service.
ICAP ICAP Message Customer
Browser Proxy Client Server Service Internet DB
| HTTP | | | | | |
| GET | Proxy | | | | |
+------->| Request | | | | |
| +---------|---------|--------|------->| |
| | | | | 200 OK | |
| |<--------|---------|--------|--------+ |
| | ICAP | | | | |
| | RESPMOD | ICAP | | | |
| +-------->| RESPMOD | Check | | |
| | +-------->| Cache | | |
| | | | for IP | | |
| | | | Match | | |
| | | +------->| | |
| | | | Cache | | |
| | | | Miss | | |
| | | |<-------+ Request| |
| | | 204 No | | Type | |
| | | Modif. | +--------|------->|
| | | Needed | | | |
| | No |<--------+ | | Type |
| | Insert | | | |Returned|
| 200 OK |<--------+ | |<-------|--------+
| w/o | | | | | |
| Insert | | | | | |
|<-------+ | | | | |
| | | | | | |
| Figure 3: End-to-End Web Notification Flow - With Cache Miss |
The figure below illustrates what occurs when a notification request for the user's IP address is cached in the Messaging Service.
ICAP ICAP Message Customer
Browser Proxy Client Server Service Internet DB
| HTTP | | | | | |
| GET | Proxy | | | | |
+------->| Request | | | | |
| +---------|---------|--------|------->| |
| | | | | 200 OK | |
| |<--------|---------|--------|--------+ |
| | ICAP | | | | |
| | RESPMOD | ICAP | | | |
| +-------->| RESPMOD | Check | | |
| | +-------->| Cache | | |
| | | | for IP | | |
| | | | Match | | |
| | | +------->| | |
| | | | Cache | | |
| | | | Hit | | |
| | | Insert |<-------+ | |
| | Return | Type | | | |
| | 200 OK |<--------+ | | |
| | with | | | | |
| | Insert | | | | |
| 200 OK |<--------+ | | | |
| w/ | | | | | |
| Notify | | | | | |
|<-------+ | | | | |
| | | | | | |
| Figure 4: End-to-End Web Notification Flow - With Cache Hit |
| TOC |
The figure below shows an example of a normal HTTP GET request from the user's web browser to www.example.com, a web server on the Internet.
------------------------------------------------------------------------
1. HTTP Get Request to www.example.com
------------------------------------------------------------------------
http://www.example.com/
GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14)
Gecko/20080404 Firefox/2.0.0.14
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
------------------------------------------------------------------------
| Figure 5: Example HTTP Headers for a Web Notification - HTTP Get |
In the figure below, the traffic is routed via the Web Proxy, which communicates with the ICAP Server and returns the response from www.example.com. In this case that response is a 200 OK, with the desired notification message inserted.
------------------------------------------------------------------------ 2. Response from www.example.com via PROXY ------------------------------------------------------------------------ HTTP/1.x 200 OK Date: Thu, 08 May 2008 16:26:29 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT Etag: "b80f4-1b6-80bfd280" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8 Age: 18 X-Cache: HIT from localhost.localdomain Via: 1.0 localhost.localdomain (squid/3.0.STABLE5) Proxy-Connection: keep-alive ------------------------------------------------------------------------
| Figure 6: Example HTTP Headers for a Web Notification - HTTP Response |
The figure below shows an example of the web notification content inserted in the 200 OK response, in this example JavaScript code.
------------------------------------------------------------------------
3. Example of JavaScript containing Notification Insertion
------------------------------------------------------------------------
<!--all elements used in a notification should have css properties
defined to avoid unwanted inheritance from parent page-->
<style type="text/css">
#example {
position: absolute; left: 100px; top: 50px;
z-index: 9999999; height: auto; width: 550px;
padding: 10px;
border: solid 2px black;
background-color:#FDD017;
opacity: 0.8; filter: alpha(opacity = 80);
}
</style>
<script language="javascript" type="text/javascript">
// ensure that content is not part of an iframe
if (self.location == top.location) {
// this is a floating div with 80% transparency
document.write('<div id="example" name="example">');
document.write('<h2>IMPORTANT MESSAGE</h2>');
document.write('<p>Lorem ipsum dolor sit amet, consecteteur ');
document.write('adipisicing elit, sed do eiusmod tempor ');
document.write('incididunt ut labore et dolore magna aliqua. ');
document.write('Ut enim ad minim veniam, quis nostrud ');
document.write('exercitation ullamco laboris nisi ut aliquip ex ');
document.write('ea commodo consequat.');
document.write('</div>');
}</script>
------------------------------------------------------------------------
| Figure 7: Example JavaScript Used in a Web Notification |
| TOC |
The components of the web notification system should be distributed throughout the network and close to end users. This ensures that the routing performance and the user's web browsing experience remains acceptable. It is also recommended that a HTTP-aware load balancer is used in each datacenter where servers are located, so that traffic can be spread across N+1 servers and the system can be easily scaled out.
| TOC |
This web notification system was conceived in order to provide an additional method of notifying ISP customers that their computer was infected with malware. Depending upon the nature of the alert contained in the web notification, such as the malware alert, users could fear that it is some kind of phishing attack. As a result, care should be taken with the text and any links contained in the web notification itself. For example, the ISP may find it best to provide a general URI or a telephone number. In contrast to that, the ISP should NOT ask for login credentials or for someone to follow a link in the web notification in order to change their password since these are common phishing techniques. Finally, care should be taken to provide confidence that the web notification is valid and from a trusted party, and/or that the user has an alternate method of checking the validity of the web notification.
| TOC |
There are no IANA considerations in this document.
NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO PUBLICATION.
| TOC |
The authors wish to thank Alissa Cooper for her review of and comments on the document, as well as others who reviewed the document.
| TOC |
| TOC |
| TOC |
| [CableLabs DOCSIS] | CableLabs, “Data-Over-Cable Service Interface Specifications,” CableLabs Specifications Various DOCSIS Reference Documents. |
| [RFC3360] | Floyd, S., “Inappropriate TCP Resets Considered Harmful,” BCP 60, RFC 3360, August 2002 (TXT). |
| TOC |
[RFC Editor: This section is to be removed before publication]
-00 version:
| TOC |
| Chae Chung | |
| Comcast Cable Communications | |
| One Comcast Center | |
| 1701 John F. Kennedy Boulevard | |
| Philadelphia, PA 19103 | |
| US | |
| Email: | chae_chung@cable.comcast.com |
| URI: | http://www.comcast.com |
| Alex Kasyanov | |
| Comcast Cable Communications | |
| One Comcast Center | |
| 1701 John F. Kennedy Boulevard | |
| Philadelphia, PA 19103 | |
| US | |
| Email: | alexander_kasyanov@cable.comcast.com |
| URI: | http://www.comcast.com |
| Jason Livingood | |
| Comcast Cable Communications | |
| One Comcast Center | |
| 1701 John F. Kennedy Boulevard | |
| Philadelphia, PA 19103 | |
| US | |
| Email: | jason_livingood@cable.comcast.com |
| URI: | http://www.comcast.com |
| Nirmal Mody | |
| Comcast Cable Communications | |
| One Comcast Center | |
| 1701 John F. Kennedy Boulevard | |
| Philadelphia, PA 19103 | |
| US | |
| Email: | nirmal_mody@cable.comcast.com |
| URI: | http://www.comcast.com |
| Brian Van Lieu | |
| Unaffiliated | |
| Bethlehem, PA 18018 | |
| US | |
| Email: | brian@vanlieu.net |