pp-adic Hodge theory in rigid analytic families

We study the functors \D_{\B_\ast}(V), where \B_\ast is one of Fontaine's period rings and $V$ is a family of Galois representations with coefficients in an affinoid algebra $A$. We show that \D_{\HT}(V)=\oplus_{i\in\Z}(\D_{\Sen}(V)\cdot t^i)^{\Gamma_K}, \D_{\dR}(V)=\D_{\dif}(V)^{\Gamma_K}, and \D_{\cris}(V)=\D_{\rig}(V)[1/t]^{\Gamma_K}, generalizing results of Sen, Fontaine, and Berger. The modules \D_{\HT}(V) and \D_{\dR}(V) are coherent sheaves on \Sp(A), and \Sp(A) is stratified by the ranks of submodules \D_{\HT}^{[a,b]}(V) and \D_{\dR}^{[a,b]}(V) of "periods with Hodge-Tate weights in the interval $[a,b]$". Finally, we construct functorial \B_\ast-admissible loci in \Sp(A), generalizing a result of Berger-Colmez to the case where $A$ is not necessarily reduced.Comment: Final version. 44 page

Defending Against Sequence Number Attacks

IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks

Guidelines for Specifying the Use of IPsec Version 2

The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified

A Technique for Counting NATted Hosts

There have been many attempts to measure how many hosts are on the Internet. Many of those end-points, however, are NAT boxes (Network Address Translators), and actually represent several different computers. We describe a technique for detecting NATs and counting the number of active hosts behind them. The technique is based on the observation that on many operating systems, the IP header's ID field is a simple counter. By suitable processing of trace data, packets emanating from individual machines can be isolated, and the number of machines determined. Our implementation, tested on aggregated local trace data, demonstrates the feasibility (and limitations) of the scheme

Using Bloom Filters for Authenticated Yes/No Answers in the DNS

Some aspects of DNSSEC, such as NXDOMAIN error messages, require an authenticated answer. Producing this answer requires complex mechanisms, online storage of the zone's secret key, expensive online computations, or massive zone files. As an alternative, we propose storage of authenticated pointers to Bloom filters. This scheme provides large reductions in the size of, and computational expense to produce, partially-signed zone files

The "Session Tty" Manager

In many UNIX systems, it is possible for a program to retain access to the login terminal after the user has logged out. This poses obvious security risks and can also confuse the modem control signals. We solve this for System V by adding a layer of indirection known as the session tty driver. At login time, a session device is linked to the physical terminal. User programs have access to the session device only, and may not open the physical line. Upon logout or carrier drop, the link is severed. New login sessions are given new session devices, and are thus insulated from persistent processes. Use of session devices is controlled by a new system process known as the session manager; by means of suitable plumbing primitives, a "reconnect after line drop" facility can easily be implemented

Distributed Firewalls

Conventional firewalls rely on the notions of restricted topology and controlled entry points to function. More precisely, they rely on the assumption that everyone on one side of the entry point—the firewall—is to be trusted, and that anyone on the other side is, at least potentially, an enemy. The vastly expanded Internet connectivity in recent years has called that assumption into question. We propose a "distributed firewall", using IPSEC, a policy language, and system management tools. A distributed firewall preserves central control of access policy, while reducing or eliminating any dependency on topology

Security as a Systems Property

How do we protect systems? The answer is straightforward: each component must be evaluated independently and protected as necessary. Beware the easy answers, such as deploying stronger encryption while ignoring vulnerable end points; that's too much like looking under the streetlamp for lost keys, not because they're likely to be there but because it's an easy place to search. Remember, too, that people and processes are system components as well, and often the weakest ones ”think about phishing, but also about legitimate emails that are structurally indistinguishable from phishing attacks. I'm not saying you should ignore one weakness because you can't afford to address another serious one” but in general, your defenses should be balanced. After that, of course, you have to evaluate the security of the entire system. Components interact, not always in benign ways, and there may be gaps you haven't filled

Seers and Craftspeople

Columnist Steve Bellovin discusses the need to judge new ideas more by their potential, and less by what they leave unsolved