scispace - formally typeset
Search or ask a question

Security Architecture for the Internet Protocol

01 Aug 1995-Vol. 1825, pp 1-101
TL;DR: This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer, and obsoletes RFC 2401 (November 1998).
Abstract: This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]

Content maybe subject to copyright    Report

Citations
More filters
Patent
10 Dec 2007
TL;DR: In this paper, a system and methods for dynamic electronic-mail filtering for mobile devices are provided. Incoming e-mail messages are received and provided to an email inbox associated with the intended recipient, and those e-mails are evaluated to determine whether they may be desirable to the recipient.
Abstract: Systems and methods for dynamic electronic-mail filtering for mobile devices are provided. Incoming e-mail messages are received and provided to an e-mail inbox associated with the intended recipient. Those e-mail messages are evaluated to determine whether they may be desirable to the recipient. Desirability of an e-mail may be determined by such factors as the e-mail address of origin or key words in subject line. E-mail messages determined to be desirable are provided to a mobile device associated with the recipient. The recipient may then be notified concerning the desirable messages.

99 citations

01 Jan 2009
TL;DR: This document describes the current understanding of why Tor is slow, and lays out the authors' options for fixing it, and identifies six main reasons why it is slow.
Abstract: As Tor’s user base has grown, the performance of the Tor network has suffered. This document describes our current understanding of why Tor is slow, and lays out our options for fixing it. Over the past few years, our funding (and thus our development effort) has focused on usability and blocking-resistance. We’ve come up with a portable self-contained Windows bundle; deployed tools to handle the upcoming censorship arms race; further developed supporting applications like Vidalia, Torbutton, and Thandy; made it easier for users to be relays by adding better rate limiting and an easy graphical interface with uPnP support; developed an effective translation and localization team and infrastructure; and spread understanding of Tor in a safe word-of-mouth way that stayed mostly under the radar of censors. In parallel to adding these features, we’ve also been laying the groundwork for performance improvements. We’ve been working with academics to write research papers on improving Tor’s speed, funding some academic groups directly to come up with prototypes, and thinking hard about how to safely collect metrics about network performance. But it’s becoming increasingly clear that we’re not going to produce the perfect answers just by thinking hard. We need to roll out some attempts at solutions, and use the experience to get better intuition about how to really solve the problems. We’ve identified six main reasons why the Tor network is slow. Problem #1 is that Tor’s congestion control does not work well. We need to come up with ways to let “quiet” streams like web browsing co-exist better with “loud” streams like bulk transfer. Problem #2 is that some Tor users simply put too much traffic onto the network relative to the amount they contribute, so we need to work on ways to limit the effects of those users and/or provide priority to the other users. Problem #3 is that the Tor network simply doesn’t have enough capacity to handle all the users that want privacy on the Internet. We need to develop strategies for increasing the overall community of relays, and consider introducing incentives to make the network more self-sustaining. Problem #4 is that Tor’s current path selection algorithms don’t actually distribute load correctly over the network, meaning some relays are overloaded and some are underloaded. We need to develop ways to more accurately estimate the properties of each relay, and also ways for clients to select paths more fairly. Problem #5 is that Tor clients aren’t as good as they should be at handling high or variable latency and connection failures. We need better heuristics for clients to automatically shift away from bad circuits, and other tricks for them to dynamically adapt their behavior. Problem #6 is that low-bandwidth users spend too much of their network overhead downloading directory information. We’ve made a serious dent in this problem already, but more work remains here too. We discuss each reason more in its own section below. For each section, we explain our current intuition for how to address the problem, how effective we think each fix would be, how much effort and risk is involved, and the recommended next steps, all with an eye to what can be accomplished in 2009. While all six categories need to be resolved in order to make the Tor network fast enough to handle everyone who wants to use it, we’ve ordered the sections by precedence. That is, solving the earlier sections will be necessary before we can see benefits from solving the later sections.

99 citations

01 Nov 1998
TL;DR: This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP).
Abstract: This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP).

99 citations

Patent
25 Oct 2006
TL;DR: In this paper, the authors present methods for detecting anomalous program executions, including modifying a program to include indicators of program-level function calls being made during execution of the program.
Abstract: Methods, media, and systems for detecting anomalous program executions are provided. In some embodiments, methods for detecting anomalous program executions are provided, comprising: executing at least a part of a program in an emulator; comparing a function call made in the emulator to a model of function calls for the at least a part of the program; and identifying the function call as anomalous based on the comparison. In some embodiments, methods for detecting anomalous program executions are provided, comprising: modifying a program to include indicators of program-level function calls being made during execution of the program; comparing at least one of the indicators of program-level function calls made in the emulator to a model of function calls for the at least a part of the program; and identifying a function call corresponding to the at least one of the indicators as anomalous based on the comparison.

98 citations

Journal ArticleDOI
TL;DR: A hierarchical key-management approach is suggested for adding data security to group communication in hybrid networks due to security additions like Internet security protocol (IPSec) or secure socket layer (SSL), and solutions to performance-related problems are suggested.
Abstract: Satellites are expected to play an increasingly important role in providing broadband Internet services over long distances in an efficient manner. Most future networks will be hybrid in nature - having terrestrial nodes interconnected by satellite links. Security is an important concern in such networks, since the satellite segment is susceptible to a host of attacks, including eavesdropping, session hijacking and data corruption. In this article we address the issue of securing communication in satellite networks. We discuss various security attacks that are possible in hybrid satellite networks, and survey the different solutions proposed to secure data communications in these networks. We look at the performance problems arising in hybrid networks due to security additions like Internet security protocol (IPSec) or secure socket layer (SSL), and suggest solutions to performance-related problems. We also point out important drawbacks in the proposed solutions, and suggest a hierarchical key-management approach for adding data security to group communication in hybrid networks.

98 citations

References
More filters
Journal ArticleDOI
TL;DR: This paper suggests ways to solve currently open problems in cryptography, and discusses how the theories of communication and computation are beginning to provide the tools to solve cryptographic problems of long standing.
Abstract: Two kinds of contemporary developments in cryptography are examined. Widening applications of teleprocessing have given rise to a need for new types of cryptographic systems, which minimize the need for secure key distribution channels and supply the equivalent of a written signature. This paper suggests ways to solve these currently open problems. It also discusses how the theories of communication and computation are beginning to provide the tools to solve cryptographic problems of long standing.

14,980 citations

01 Mar 1997
TL;DR: This document defines these words as they should be interpreted in IETF documents as well as providing guidelines for authors to incorporate this phrase near the beginning of their document.
Abstract: In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

3,501 citations

Journal ArticleDOI
TL;DR: Use of encryption to achieve authenticated communication in computer networks is discussed and example protocols are presented for the establishment of authenticated connections, for the management of authenticated mail, and for signature verification and document integrity guarantee.
Abstract: Use of encryption to achieve authenticated communication in computer networks is discussed. Example protocols are presented for the establishment of authenticated connections, for the management of authenticated mail, and for signature verification and document integrity guarantee. Both conventional and public-key encryption algorithms are considered as the basis for protocols.

2,671 citations

01 Dec 1995
TL;DR: In this paper, the authors specify version 6 of the Internet Protocol (IPv6), also referred to as IP Next Generation or IPng, and propose a new protocol called IPng.
Abstract: This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.

2,112 citations

01 Sep 1981
TL;DR: Along with TCP, IP represents the heart of the Internet protocols and has two primary responsibilities: providing connectionless, best-effort delivery of datagrams through an internetwork; and providing fragmentation and reassembly of data links to support data links with different maximum transmission unit (MTU) sizes.
Abstract: IP is a network layer (Layer 3) protocol that contains addressing information and some control information that enables packets to be routed. IP is documented in RFC 791 and is the primary network layer protocol in the Internet protocol suite. Along with TCP, IP represents the heart of the Internet protocols. IP has two primary responsibilities: providing connectionless, best-effort delivery of datagrams through an internetwork; and providing fragmentation and reassembly of datagrams to support data links with different maximum transmission unit (MTU) sizes.

1,967 citations