317 research outputs found

    ICMP: an Attack Vector against IPsec Gateways

    Get PDF
    In this work we show that the Internet Control Message Protocol (ICMP) can be used as an attack vector against IPsec gateways. The main contribution of this work is to demonstrate that an attacker having eavesdropping and traffic injection capabilities in the black untrusted network (he only sees ciphered packets), can force a gateway to reduce the Path MTU of an IPsec tunnel to a minimum, which in turn creates serious issues for devices on the trusted network behind this gateway: depending on the Path MTU discovery algorithm, it either prevents any new TCP connection (Denial of Service), or it creates major performance penalties (more than 6 seconds of delay in TCP connection establishment and ridiculously small TCP segment sizes). After detailing the attack and the behavior of the various nodes, we discuss some counter measures, with the goal to find a balance between ICMP benefits and the associated risks

    ICMP: an Attack Vector against IPsec Gateways

    No full text
    In this work we show that the Internet Control Message Protocol (ICMP) can be used as an attack vector against IPsec gateways. The main contribution of this work is to demonstrate that an attacker having eavesdropping and traffic injection capabilities in the black untrusted network (he only sees ciphered packets), can force a gateway to reduce the Path MTU of an IPsec tunnel to a minimum, which in turn creates serious issues for devices on the trusted network behind this gateway: depending on the Path MTU discovery algorithm, it either prevents any new TCP connection (Denial of Service), or it creates major performance penalties (more than 6 seconds of delay in TCP connection establishment and ridiculously small TCP segment sizes). After detailing the attack and the behavior of the various nodes, we discuss some counter measures, with the goal to find a balance between ICMP benefits and the associated risks

    Linux Access Point and IPSec Bridge

    Get PDF
    [[abstract]]The main idea of this paper is to present an upper-layer security solution to solve security problems of the wireless network. The IEEE 802.11 standard defines the Wired Equivalent Privacy (WEP) Protocol. The goal of WEP is to provide data privacy to the wireless network. It is generally believed that the current wireless access points have a big security problem with WEP protocol. To solve this problem, a combination of Linux-based access point and IPSec bridge has been brought up to secure the wireless network.[[notice]]補正完畢[[journaltype]]國

    Securing Internet of Things with Lightweight IPsec

    Get PDF
    Real-world deployments of wireless sensor networks (WSNs) require secure communication. It is important that a receiver is able to verify that sensor data was generated by trusted nodes. In some cases it may also be necessary to encrypt sensor data in transit. Recently, WSNs and traditional IP networks are more tightly integrated using IPv6 and 6LoWPAN. Available IPv6 protocol stacks can use IPsec to secure data exchange. Thus, it is desirable to extend 6LoWPAN such that IPsec communication with IPv6 nodes is possible. It is beneficial to use IPsec because the existing end-points on the Internet do not need to be modified to communicate securely with the WSN. Moreover, using IPsec, true end-to-end security is implemented and the need for a trustworthy gateway is removed. In this paper we provide End-to-End (E2E) secure communication between an IP enabled sensor nodes and a device on traditional Internet. This is the first compressed lightweight design, implementation, and evaluation of 6LoWPAN extension for IPsec on Contiki. Our extension supports both IPsec's Authentication Header (AH) and Encapsulation Security Payload (ESP). Thus, communication endpoints are able to authenticate, encrypt and check the integrity of messages using standardized and established IPv6 mechanisms

    Beyond Modes: Building a Secure Record Protocol from a Cryptographic Sponge Permutation

    Get PDF
    Abstract. BLINKER is a light-weight cryptographic suite and record protocol built from a single permutation. Its design is based on the Sponge construction used by the SHA-3 algorithm KECCAK. We examine the SpongeWrap authen-ticated encryption mode and expand its padding mechanism to offer explicit do-main separation and enhanced security for our specific requirements: shared se-cret half-duplex keying, encryption, and a MAC-and-continue mode. We motivate these enhancements by showing that unlike legacy protocols, the resulting record protocol is secure against a two-channel synchronization attack while also having a significantly smaller implementation footprint. The design facilitates security proofs directly from a single cryptographic primitive (a single security assump-tion) rather than via idealization of multitude of algorithms, paddings and modes of operation. The protocol is also uniquely suitable for an autonomous or semi-autonomous hardware implementation of protocols where the secrets never leave the module, making it attractive for smart card and HSM designs

    Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways

    Get PDF
    International audienceThis work introduces the "Packet Too Big"-"Packet Too Small" ICMP based attack against IPsec gateways. We explain how an attacker having eavesdropping and packet injection capabilities, from the insecure network where he only sees encrypted packets, can force a gateway to reduce the Path MTU of an IPsec tunnel to the minimum, which triggers severe issues for the hosts behind this gateway: depending on the Path MTU discovery algorithm in use, the attack either creates a Denial of Service or major performance penalties. This attack highlights two fundamental problems that we discuss, along with potential counter-measures to mitigate the attack while keeping ICMP benefits

    A Survey of Methods for Encrypted Traffic Classification and Analysis

    Get PDF
    With the widespread use of encrypted data transport network traffic encryption is becoming a standard nowadays. This presents a challenge for traffic measurement, especially for analysis and anomaly detection methods which are dependent on the type of network traffic. In this paper, we survey existing approaches for classification and analysis of encrypted traffic. First, we describe the most widespread encryption protocols used throughout the Internet. We show that the initiation of an encrypted connection and the protocol structure give away a lot of information for encrypted traffic classification and analysis. Then, we survey payload and feature-based classification methods for encrypted traffic and categorize them using an established taxonomy. The advantage of some of described classification methods is the ability to recognize the encrypted application protocol in addition to the encryption protocol. Finally, we make a comprehensive comparison of the surveyed feature-based classification methods and present their weaknesses and strengths.Šifrování síťového provozu se v dnešní době stalo standardem. To přináší vysoké nároky na monitorování síťového provozu, zejména pak na analýzu provozu a detekci anomálií, které jsou závislé na znalosti typu síťového provozu. V tomto článku přinášíme přehled existujících způsobů klasifikace a analýzy šifrovaného provozu. Nejprve popisujeme nejrozšířenější šifrovací protokoly, a ukazujeme, jakým způsobem lze získat informace pro analýzu a klasifikaci šifrovaného provozu. Následně se zabýváme klasifikačními metodami založenými na obsahu paketů a vlastnostech síťového provozu. Tyto metody klasifikujeme pomocí zavedené taxonomie. Výhodou některých popsaných klasifikačních metod je schopnost rozeznat nejen šifrovací protokol, ale také šifrovaný aplikační protokol. Na závěr porovnáváme silné a slabé stránky všech popsaných klasifikačních metod

    Options for Securing RTP Sessions

    Get PDF
    The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism

    A Layer 2 Protocol to Protect the IP Communication in a Wired Ethernet Network

    Get PDF
    The IP protocol is the preferred data communication mechanism used nowadays. Data encapsulated using IP can be compromised if it is sent in clear text or without integrity protection, and even using known protocols to protect the confidentiality, integrity and authenticity of this data, the EtherType field of the Ethernet frames and the header of the IP packets in a wired Ethernet network still remain exposed opening possibilities for an attacker to gain knowledge of the network, cause a denial of service attack or steal information. In this thesis, we propose a new protocol that protects the confidentiality, integrity and authenticity of the IP communication in a wired Ethernet network. This new protocol operates in the layer 2 of the OSI model, and for each Ethernet frame, it encapsulates the EtherType field and the entire IP packet into a new PDU structure that is partially encrypted. Integrity and authenticity are assured by an HMAC value or a digital signature calculated over the entire frame. We ran several tests to analyze the security characteristics and performance impact of our proposed solution; the results of these tests demonstrate that all traffic is effectively protected and that an attacker or eavesdropper wouldn\u27t know the type of protocols, IP addresses or any other data travelling across the network. It is also demonstrated that under certain conditions, performance is not highly impacted and is feasible to protect the network communication with our new protocol
    • …
    corecore