Recent work in the area of network security, such as IPsec, provides mechanisms for securing the trac between any two interconnected hosts. However, it is not always possible, economical, or even practical from an administration and operational point of view to upgrade the software and con guration of all the nodes in a network to support such security protocols. One apparent solution to this problem is the use of security gateways that apply the relevant security protocols on behalf of the protected nodes, under the assumption that the \last hop" between the security gateway and the end node is safe without cryptography. Such a gateway can be set to enforce speci c security policies for dierent types of trac. While this solution is appealing in static scenarios (such as building so-called \intranets"), the use of Layer-3 (network) routers as security gateways presents some transparency and con guration problems with regards to peer authentication in the automated key management prot...

Most implementations of IP security are deeply entwined in the source of of the protocol stack. However, such source code is not readily available for MS-DOS systems. We implemented a version using the packet driver interface. Our module sits between the generic Ethernet driver and the hardware driver; it emulates each to the other. Most of the code is straightforward; in a few places, though, we were forced to compensate for inadequate interface definitions. 1 Introduction The Internet Engineering Task Force (IETF) is in the process of adopting standards for IP-layer encryption and authentication (IPSEC) [3, 1, 2]. Not surprisingly, most of the original implementations are being developed for various flavors of the Unix 1 operating system. While this is good---indeed, we are primarily Unix system users ourselves---much of the world feels differently, and prefers MS-DOS 2 systems. For many reasons, it seemed desirable to develop an IPSEC implementation for a MS-DOS system. Our ...

Formal methods have been successfully applied to exceedingly abstract system specifications to verify high level security properties such as authentication, key exchange, and fail-safe revocation. Furthermore, considerable research exists on evaluating particular ciphers and secure hash functions used to implement high level security properties. However, verifying that less abstract system specifications satisfy low level security properties has been largely impractical. This is evidenced by innumerable system vulnerabilities where high level properties are not attained due to failed assumptions of low level properties. This paper presents ongoing work on investigating known and chosen ciphertext pairs using the NRL Protocol Analyzer. We give a formal characterization of known and chosen pairs, and map it to the NRL Protocol Analyzer model. We also describe the use of the Analyzer to rediscover attacks on an early version of the ESP protocol, and show how our experience in using it has...

Corporate network firewalls are well-understood and are becoming commonplace. These firewalls establish a security perimeter that aims to block (or heavily restrict) both incoming and outgoing network communication. We argue that these firewalls are neither effective nor appropriate for academic or corporate research environments needing to maintain information security while still supporting the free exchange of ideas. In this paper, we present the Stanford University Research Firewall (SURF), a network firewall design that is suitable for a research environment. While still protecting information and computing resources behind the firewall, this firewall is less restrictive of outward information flow than the traditional model; can be easily deployed; and can give internal users the illusion of unrestricted e-mail, anonymous FTP, and WWW connectivity to the greater Internet. Our experience demonstrates that an adequate firewall for a research environment can be constructed for minim...

Wireless and satellite networks have non-negligible error rates that can significantly influence TCP performance because TCP considers every packet loss as an indicator of congestion, and thus throttles the packet transmission rate. Explicit transport error notification (ETEN) mechanisms can aid TCP in distinguishing packets that are lost due to congestion from ones that are lost due to corruption. If TCP can retransmit a packet lost due to corruption without needlessly reducing the transmission rate, a performance benefit can be realized.

Abstract not found

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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

need to share high-value data across multiple domains of different classification levels while enforcing information flow policies. The architecture allows users with different security authorizations to securely collaborate and exchange information using commodity computers and familiar commercial client software that generally lack the prerequisite assurance and functional security protections. MYSEA seeks to meet two compelling requirements, often assumed to be at odds: enforcing critical, mandatory security policies, and allowing access and collaboration in a familiar work environment. Recent additions to the MYSEA design expand the architecture to support a cloud of cross-domain services, hosted within a federation of multilevel secure (MLS) MYSEA servers. The MYSEA cloud supports single-sign on, service replication, and network-layer quality of security service. This new crossdomain, distributed architecture follows the consumption and delivery model for cloud services, while maintaining the federated control model necessary to support and protect crossdomain collaboration within the enterprise. The resulting architecture shows the feasibility of high-assurance, cross-domain services hosted within a community cloud suitable for interagency, or joint, collaboration. This paper summarizes the MYSEA architecture and discusses MYSEA's approach to provide an MLS-constrained cloud computing environment.

Among the responsibilities assigned to the Office of the Manager, National Communications System, is the management of the Federal Telecommunications Standards Program. Under this program, the NCS, with the assistance of the Federal Telecommunications Standards Committee identifies, develops, and coordinates proposed Federal Standards which either contribute to the interoperability of functionally similar Federal telecommunications systems or to the achievement of a compatible and efficient interface between computer and telecommunications systems. In developing and coordinating these standards, a considerable amount of effort is expended in initiating and pursuing joint standards development efforts with appropriate technical committees of the International Organization for Standardization, the International Telecommunication Union-Telecommunications Standardization Sector, and the American National

draft-ietf-mobileip-ipv6-22.txt