DOCSLIB.ORG

Internet Protocol Security (Ipsec) Guide

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Internet Protocol Security (Ipsec) Guide INTERNET PROTOCOL SECURITY (IPSEC) GUIDE www.insidesecure.com INTRODUCING IPSEC– NETWORK LAYER PACKET SECURITY With the explosive growth of the Internet, more and more enterprises are looking towards building their network infrastructure across the Internet without having to spend a lot on private leased lines. However, more and more «evil ways» of breaking into the network to gather sensitive information are also evolving. Thus, security on the Internet has been a main concern for each enterprise. IPSec provides the necessary infrastructure to extend an enterprise’s private network across the Internet to reach out to customers and business partners with the help of a «virtual private network (VPN)». | 02 VPN APPLICATIONS IPSEC MODES OF OPERATION There are three basic flavors of IPSec VPNs, each with an IPSec provides two different modes to exchange protected associated set of business requirements (Figure 1): data across the different kinds of VPNs: • Remote-Access VPNs: These let individual users connect to 1. Transport Mode: This mode is applicable only for host-to-host a corporate network. The user’s laptop usually contains a VPN security. Here protection extends to the payload of IP data. client that creates a secure tunnel to the security gateway at The IP addresses of the hosts must be public IP addresses. the corporate headquarters. Another flavor of this application is offered via creating an L2TP/PPTP session that is protected 2. Tunnel Mode: This mode is used to provide data security through IPSec. between two networks. It provides protection for the entire IP packet and is sent by adding an outer IP header corresponding to • Intranet VPNs: This type connects branch offices to the the two tunnel endpoints. The unprotected packets generated corporate headquarters, thus creating a transparent Intranet. by hosts travel through the protected «tunnel» created by the gateways on both ends. The outer IP header in Figure 2 • Extranet VPNs: These let companies connect with their corresponds to these gateways. Both intranet and extranet business partners (for example, suppliers, customers, and joint VPNs are enabled through this mode. Since tunnel mode hides ventures). the original IP header, it facilitates security of the networks with private IP address space. IP HDR Data TRANSPORT MODE ESP ESP IP HDR ESP HDR Data Trailer Auth Encrypted Authenticated TUNNEL MODE ESP ESP NEW IP HDR ESP HDR IP HDR Data Trailer Auth Encrypted Authenticated Figure 1 - IPSec VPN Applications Figure 2 - IPSec modes of operation—tunnel and transport 03 | IPSEC ARCHITECTURE Figure 3 describes the overall IPSec architecture: «pass through», the forwarding engine forwards the packet normally. The «Policy Manager» module is the interface between the user adding a security policy and the SPD. The «IKE Daemon» module • If the policy is «IPSec», the SPD entry should point to an SA does the automatic SA negotiation between two IPSec peers. in SAD. The module then fetches the corresponding SAD The «Certificate Manager» verifies and enrolls certificates for entry and checks for validity. If the SA state is expired, the authentication purposes. In short, a typical packet flow inside IKE daemon starts another SA negotiation. this architecture proceeds as follows: • The transform depicted in the SA is performed on the packet • A packet is received through the receive queue and passed with the help of the «cryptography» module. to the IPSec packet processing module. • The transformed packet is sent to the «transmit queue» for • The IPSec packet processing module extracts the «selector» transmission. from the packet and looks up the SPD for a policy. If the policy is «discard», the packet is discarded. If the policy is Policy Certificate IKE Daemon Manager Manager SPD SAD Receive Transmit Queue Queue IPSecPacketProcessingModule Incoming Outgoing Packet Packet CryptographyModule Figure 3 - IPSec architecture | 04 IPSEC PROTOCOLS IPSec standards have defined a key negotiation protocol, IKE, and two protocols to exchange data, ESP and AH. ESP is most Original IP Ext commonly used. Packet Header Hdrs TCP Data Encapsulating Security Payload (ESP) TRANSPORT MODE ESP provides data confidentiality, data integrity, and replay IP Ext ESP ESP protection for the IP payload. It uses a symmetric key algorithm Header Hdrs ESP Header TCP Data Trailer Auth (like 3DES-CBC or AES-CBC) to encrypt the payload and a Encrypted secure hash algorithm (such as SHA1 or SHA2) that takes an Authenticated authentication key as input to compute the integrity check value (ICV) over the payload. The ICV is then appended to the TUNNEL MODE New IP Ext IP Ext ESP ESP packet. The receiver decrypts the payload and re-computes Header Hdrs ESP Header Header Hdrs TCP Data Trailer Auth the ICV on the received packet and checks for equality. Encrypted Authenticated Any modifications that occurred to the packet payload during transmission can be discovered, as the ICVs will not match. Unlike AH (below), the IP header itself is not protected against data-integrity attacks. Figure 4a illustrates the ESP header. Figure 4a - IPSec ESP Transport and Tunnel formats 05 | Authentication Header (AH) Internet Key Exchange (IKE) AH provides data integrity and replay protection for the whole IKE defines the mechanism to establish SAs required to IP datagram and is an effective measure against IP-spoofing secure the packets between the two IPSec peers. The main and session-hijacking attacks. AH, like ESP, uses a secure hash components of an SA are the transform details (the algorithm algorithm to compute the ICV over the IP header plus payload. and the key) that will be used to protect data. IKE defines an The ICV is included as part of the AH header. The AH protocol automatic and secure way of negotiating these details between specifies a set of mutable IP header fields (TOS, Fragment the two peers. The protocol operates in two phases: offset and flags, TTL, Checksum) that should be excluded from the ICV computation. Figure 4b illustrates the AH header. 1. Phase I (Authentication Phase) When two peers over the Internet wish to communicate, it is assumed that no secure channel exists. Therefore, the objective of «phase I» is to establish a secure channel, authenticate the negotiating parties, and generate shared keys to protect IKE Original IP Ext Packet Header Hdrs TCP Data protocol messages. TRANSPORT MODE 2. Phase II (Key Exchange) Phase II, also called as the «Quick Mode,» is used to establish IP Ext Authent. Header Hdrs Header TCP Data the IPSec SA and to generate new keying material. Authenticated (except for mutable fields) TUNNEL MODE New IP Ext Authent. IP Ext Header Hdrs Header Header Hdrs TCP Data Authenticated (except for mutable fields in new IP Header) Figure 4b - IPSec AH Transport and Tunnel formats | 06 IPSEC PACKET PROCESSING Outbound Packet Processing Figure 5 describes IPSec operation on the security device for Outbound packets arrive from the private network and are inbound and outbound packets. destined to another private network across the Internet. These packets need to be protected. Inbound Packet Processing Engineering A High-Performance Security Gateway Inbound packets are the protected packets that arrive at the security gateway, typically coming from the public network Encryption and authentication are extremely compute- to the private network. These packets have to be decrypted, intensive functions. A security gateway that must perform at authenticated, and forwarded to the private network. wire speed with 64-byte packets cannot rely on a software- only implementation. Specialized SoC functions that perform the cryptographic computations, including encryption and authentication, are called crypto accelerators. These devices are necessary to scale to higher throughput rates. There are different types of crypto accelerators available in the market. At this point of time, these crypto accelerators seem to fall into three general categories: • Processors with Basic Algorithm Support - These processors perform basic symmetric-key operations such as 3DES, AES, and others and hash operations such as SHA1, SHA2, and others. • Packet Processors - These take in a packet along with an SA and do the complete packet processing (for example, the addition of the ESP or AH header, as required) in addition to supporting the prior functionality. • Inline Security Coprocessors - Handles SA lookup and packet handling, as well as SPD verification. Figure 5 - IPSec Packet Processing Data Flow (User Space SW implementation) 07 | INTRODUCING INSIDE SECURE’S EIP-197 PACKET ENGINE FAMILY The PacketEngine-IP-197 (EIP-197) security packet engine is comprised of an in-line streaming interface, a look-aside bus interface, an IPSec classifier, a packet transform engine and an optional post decryption processor. This packet engine is used as a bus master in the data plane of the system and processes packets with very little CPU intervention. It supports an AXI streaming interface, an AMBA SoC bus interface and can be delivered in different configurations to support multiple performance grades from 5 to 80+ Gbps, achievable even on a single SA (one half of a single tunnel) - or as many SA’s/tunnels as needed (limited only by available memory connected to the SoC). | 08 This packet engine is used as a bus master in the data plane handle the cryptographic workload due to performance or of the system and processes packets with very little CPU power limitations. The packet engine handles the security intervention. It supports an AXI streaming interface, an (protocol) operations and reduces power in high-end servers, AMBA SoC bus interface and can be delivered in different communication and network processors for: network processors configurations to support multiple performance grades from used in switch applications; data center processing and cloud 5 to 80+ Gbps, achievable even on a single SA (one half of a computing; communication and high-end security gateways. single tunnel) - or as many SA’s/tunnels as needed (limited only by available memory connected to the SoC).
Load more

Recommended publications
  • Ipv6-Ipsec And
    IPSec and SSL Virtual Private Networks ITU/APNIC/MICT IPv6 Security Workshop 23rd – 27th May 2016 Bangkok Last updated 29 June 2014 1 Acknowledgment p Content sourced from n Merike Kaeo of Double Shot Security n Contact: [email protected] Virtual Private Networks p Creates a secure tunnel over a public network p Any VPN is not automagically secure n You need to add security functionality to create secure VPNs n That means using firewalls for access control n And probably IPsec or SSL/TLS for confidentiality and data origin authentication 3 VPN Protocols p IPsec (Internet Protocol Security) n Open standard for VPN implementation n Operates on the network layer Other VPN Implementations p MPLS VPN n Used for large and small enterprises n Pseudowire, VPLS, VPRN p GRE Tunnel n Packet encapsulation protocol developed by Cisco n Not encrypted n Implemented with IPsec p L2TP IPsec n Uses L2TP protocol n Usually implemented along with IPsec n IPsec provides the secure channel, while L2TP provides the tunnel What is IPSec? Internet IPSec p IETF standard that enables encrypted communication between peers: n Consists of open standards for securing private communications n Network layer encryption ensuring data confidentiality, integrity, and authentication n Scales from small to very large networks What Does IPsec Provide ? p Confidentiality….many algorithms to choose from p Data integrity and source authentication n Data “signed” by sender and “signature” verified by the recipient n Modification of data can be detected by signature “verification”
    [Show full text]
  • Mist Teleworker ME
    MIST TELEWORKER GUIDE ​ ​ ​ ​ ​ Experience the corporate network @ home DOCUMENT OWNERS: ​ ​ ​ ​ Robert Young – [email protected] ​ Slava Dementyev – [email protected] ​ Jan Van de Laer – [email protected] ​ 1 Table of Contents Solution Overview 3 How it works 5 Configuration Steps 6 Setup Mist Edge 6 Configure and prepare the SSID 15 Enable Wired client connection via ETH1 / Module port of the AP 16 Enable Split Tunneling for the Corp SSID 17 Create a Site for Remote Office Workers 18 Claim an AP and ship it to Employee’s location 18 Troubleshooting 20 Packet Captures on the Mist Edge 23 2 Solution Overview Mist Teleworker solution leverages Mist Edge for extending a corporate network to remote office workers using an IPSEC secured L2TPv3 tunnel from a remote Mist AP. In addition, MistEdge provides an additional RadSec service to securely proxy authentication requests from remote APs to provide the same user experience as inside the office. WIth Mist Teleworker solution customers can extend their corporate WLAN to employee homes whenever they need to work remotely, providing the same level of security and access to corporate resources, while extending visibility into user network experience and streamlining IT operations even when employees are not in the office. What are the benefits of the Mist Teleworker solution with Mist Edge compared to all the other alternatives? Agility: ● Zero Touch Provisioning - no AP pre-staging required, support for flexible all home coverage with secure Mesh ● Exceptional support with minimal support - leverage Mist SLEs and Marvis Actions Security: ● Traffic Isolation - same level of traffic control as in the office.
    [Show full text]
  • Configuring Secure Shell
    Configuring Secure Shell The Secure Shell (SSH) feature is an application and a protocol that provides a secure replacement to the Berkeley r-tools. The protocol secures sessions using standard cryptographic mechanisms, and the application can be used similarly to the Berkeley rexec and rsh tools. Two versions of SSH are available: SSH Version 1 and SSH Version 2. • Finding Feature Information, page 1 • Prerequisites for Configuring Secure Shell, page 1 • Restrictions for Configuring Secure Shell, page 2 • Information about SSH, page 2 • How to Configure Secure Shell, page 5 • Configuration Examples for Secure Shell, page 16 • Additional References for Secure Shell, page 18 • Feature Information for SSH, page 18 Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required. Prerequisites for Configuring Secure Shell The following are the prerequisites for configuring the switch for secure shell (SSH): • For SSH to work, the switch needs an Rivest, Shamir, and Adleman (RSA) public/private key pair. This is the same with Secure Copy Protocol (SCP), which relies on SSH for its secure transport.
    [Show full text]
  • Is QUIC a Better Choice Than TCP in the 5G Core Network Service Based Architecture?
    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020 Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN Master in Communication Systems Date: November 22, 2020 Supervisor at KTH: Marco Chiesa Supervisor at Ericsson: Zaheduzzaman Sarker Examiner: Peter Sjödin School of Electrical Engineering and Computer Science Host company: Ericsson AB Swedish title: Är QUIC ett bättre val än TCP i 5G Core Network Service Based Architecture? iii Abstract The development of the 5G Cellular Network required a new 5G Core Network and has put higher requirements on its protocol stack. For decades, TCP has been the transport protocol of choice on the Internet. In recent years, major Internet players such as Google, Facebook and CloudFlare have opted to use the new QUIC transport protocol. The design assumptions of the Internet (best-effort delivery) differs from those of the Core Network. The aim of this study is to investigate whether QUIC’s benefits on the Internet will translate to the 5G Core Network Service Based Architecture. A testbed was set up to emulate traffic patterns between Network Functions. The results show that QUIC reduces average request latency to half of that of TCP, for a majority of cases, and doubles the throughput even under optimal network conditions with no packet loss and low (20 ms) RTT. Additionally, by measuring request start and end times “on the wire”, without taking into account QUIC’s shorter connection establishment, we believe the results indicate QUIC’s suitability also under the long-lived (standing) connection model.
    [Show full text]
  • Internet Protocol Suite
    InternetInternet ProtocolProtocol SuiteSuite Srinidhi Varadarajan InternetInternet ProtocolProtocol Suite:Suite: TransportTransport • TCP: Transmission Control Protocol • Byte stream transfer • Reliable, connection-oriented service • Point-to-point (one-to-one) service only • UDP: User Datagram Protocol • Unreliable (“best effort”) datagram service • Point-to-point, multicast (one-to-many), and • broadcast (one-to-all) InternetInternet ProtocolProtocol Suite:Suite: NetworkNetwork z IP: Internet Protocol – Unreliable service – Performs routing – Supported by routing protocols, • e.g. RIP, IS-IS, • OSPF, IGP, and BGP z ICMP: Internet Control Message Protocol – Used by IP (primarily) to exchange error and control messages with other nodes z IGMP: Internet Group Management Protocol – Used for controlling multicast (one-to-many transmission) for UDP datagrams InternetInternet ProtocolProtocol Suite:Suite: DataData LinkLink z ARP: Address Resolution Protocol – Translates from an IP (network) address to a network interface (hardware) address, e.g. IP address-to-Ethernet address or IP address-to- FDDI address z RARP: Reverse Address Resolution Protocol – Translates from a network interface (hardware) address to an IP (network) address AddressAddress ResolutionResolution ProtocolProtocol (ARP)(ARP) ARP Query What is the Ethernet Address of 130.245.20.2 Ethernet ARP Response IP Source 0A:03:23:65:09:FB IP Destination IP: 130.245.20.1 IP: 130.245.20.2 Ethernet: 0A:03:21:60:09:FA Ethernet: 0A:03:23:65:09:FB z Maps IP addresses to Ethernet Addresses
    [Show full text]
  • The Internet Protocol, Version 4 (Ipv4)
    Today’s Lecture I. IPv4 Overview The Internet Protocol, II. IP Fragmentation and Reassembly Version 4 (IPv4) III. IP and Routing IV. IPv4 Options Internet Protocols CSC / ECE 573 Fall, 2005 N.C. State University copyright 2005 Douglas S. Reeves 1 copyright 2005 Douglas S. Reeves 2 Internet Protocol v4 (RFC791) Functions • A universal intermediate layer • Routing IPv4 Overview • Fragmentation and reassembly copyright 2005 Douglas S. Reeves 3 copyright 2005 Douglas S. Reeves 4 “IP over Everything, Everything Over IP” IP = Basic Delivery Service • Everything over IP • IP over everything • Connectionless delivery simplifies router design – TCP, UDP – Dialup and operation – Appletalk – ISDN – Netbios • Unreliable, best-effort delivery. Packets may be… – SCSI – X.25 – ATM – Ethernet – lost (discarded) – X.25 – Wi-Fi – duplicated – SNA – FDDI – reordered – Sonet – ATM – Fibre Channel – Sonet – and/or corrupted – Frame Relay… – … – Remote Direct Memory Access – Ethernet • Even IP over IP! copyright 2005 Douglas S. Reeves 5 copyright 2005 Douglas S. Reeves 6 1 IPv4 Datagram Format IPv4 Header Contents 0 4 8 16 31 •Version (4 bits) header type of service • Functions version total length (in bytes) length (x4) prec | D T R C 0 •Header Length x4 (4) flags identification fragment offset (x8) 1. universal 0 DF MF s •Type of Service (8) e time-to-live (next) protocol t intermediate layer header checksum y b (hop count) identifier •Total Length (16) 0 2 2. routing source IP address •Identification (16) 3. fragmentation and destination IP address reassembly •Flags (3) s •Fragment Offset ×8 (13) e t 4. Options y IP options (if any) b •Time-to-Live (8) 0 4 ≤ •Protocol Identifier (8) s e t •Header Checksum (16) y b payload 5 •Source IP Address (32) 1 5 5 6 •Destination IP Address (32) ≤ •IP Options (≤ 320) copyright 2005 Douglas S.
    [Show full text]
  • The State of the Authenticated Encryption 1
    Ø Ñ ÅØÑØÐ ÈÙ ÐØÓÒ× DOI: 10.1515/tmmp-2016-0038 Tatra Mt. Math. Publ. 67 (2016), 167–190 THE STATE OF THE AUTHENTICATED ENCRYPTION Damian Vizar´ ABSTRACT. Ensuring confidentiality and integrity of communication remains among the most important goals of cryptography. The notion of authenticated encryption marries these two security goals in a single symmetric-key, crypto- graphic primitive. A lot of effort has been invested in authenticated encryption during the fifteen years of its existence. The recent Competition for Authenticated Encryption: Security, Applicability, and Robustness (CAESAR) has boosted the research activity in this area even more. As a result, the area of authenticated encryption boasts numerous results, both theoretically and practically oriented, and perhaps even greater number of constructions of authenticated encryption schemes. We explore the current landscape of results on authenticated encryption. We review the CEASAR competition and its candidates, the most popular con- struction principles, and various design goals for authenticated encryption, many of which appeared during the CAESAR competition. We also take a closer look at the candidate Offset Merkle-Damg˚ard (OMD). 1. Introduction Perhaps the two most fundamental goals of symmetric-key cryptography are providing confidentiality (privacy) and authenticity (together with integrity1) of messages that are being sent over an insecure channel. These two security properties of communication have traditionally been studied separately; they were formalized in separate notions [13], [14], and achieved by separate primitives (e.g., CBC mode for confidentiality and CBCMAC for authentication). c 2016 Mathematical Institute, Slovak Academy of Sciences. 2010 M a t h e m a t i c s Subject Classification: 94A60.
    [Show full text]
  • 61A Lecture 35 Distributed Computing Internet Protocol Transmission
    Announcements • Homework 9 (6 pts) due Wednesday 11/26 @ 11:59pm ! Homework Party Monday 6pm-8pm in 2050 VLSB • Guest in live lecture, TA Soumya Basu, on Monday 11/24 • Optional Scheme recursive art contest due Monday 12/1 @ 11:59pm 61A Lecture 35 • No lecture on Wednesday 11/26 (turkey) • No lab on Tuesday 11/25 & Wednesday 11/26 • The week of 12/1: Homework 10 due Wednesday 12/3 & Quiz 3 due Thursday 12/4 on SQL Monday, November 24 ! The lab on SQL (12/2 & 12/3) will be an excellent place to get homework help 2 Distributed Computing A distributed computing application consists of multiple programs running on multiple computers that together coordinate to perform some task. • Computation is performed in parallel by many computers. • Information can be restricted to certain computers. • Redundancy and geographic diversity improve reliability. Distributed Computing Characteristics of distributed computing: • Computers are independent — they do not share memory. • Coordination is enabled by messages passed across a network. • Individual programs have differentiating roles. Distributed computing for large-scale data processing: • Databases respond to queries over a network. • Data sets can be partitioned across multiple machines (next lecture). 4 Network Messages Computers communicate via messages: sequences of bytes transmitted over a network. Messages can serve many purposes: • Send data to another computer • Request data from another computer • Instruct a program to call a function on some arguments. Internet Protocol • Transfer a program to be executed by another computer. Messages conform to a message protocol adopted by both the sender (to encode the message) & receiver (to interpret the message).
    [Show full text]
  • How Secure Is Textsecure?
    How Secure is TextSecure? Tilman Frosch∗y, Christian Mainkay, Christoph Badery, Florian Bergsmay,Jorg¨ Schwenky, Thorsten Holzy ∗G DATA Advanced Analytics GmbH firstname.lastname @gdata.de f g yHorst Gortz¨ Institute for IT-Security Ruhr University Bochum firstname.lastname @rub.de f g Abstract—Instant Messaging has gained popularity by users without providing any kind of authentication. Today, many for both private and business communication as low-cost clients implement only client-to-server encryption via TLS, short message replacement on mobile devices. However, until although security mechanisms like Off the Record (OTR) recently, most mobile messaging apps did not protect confi- communication [3] or SCIMP [4] providing end-to-end con- dentiality or integrity of the messages. fidentiality and integrity are available. Press releases about mass surveillance performed by intelli- With the advent of smartphones, low-cost short-message gence services such as NSA and GCHQ motivated many people alternatives that use the data channel to communicate, to use alternative messaging solutions to preserve the security gained popularity. However, in the context of mobile ap- and privacy of their communication on the Internet. Initially plications, the assumption of classical instant messaging, fueled by Facebook’s acquisition of the hugely popular mobile for instance, that both parties are online at the time the messaging app WHATSAPP, alternatives claiming to provide conversation takes place, is no longer necessarily valid. secure communication experienced a significant increase of new Instead, the mobile context requires solutions that allow for users. asynchronous communication, where a party may be offline A messaging app that claims to provide secure instant for a prolonged time.
    [Show full text]
  • Lesson-13: INTERNET ENABLED SYSTEMS NETWORK PROTOCOLS
    DEVICES AND COMMUNICATION BUSES FOR DEVICES NETWORK– Lesson-13: INTERNET ENABLED SYSTEMS NETWORK PROTOCOLS Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 1 Raj Kamal, Publs.: McGraw-Hill Education Internet enabled embedded system Communication to other system on the Internet. Use html (hyper text markup language) or MIME (Multipurpose Internet Mail Extension) type files Use TCP (transport control protocol) or UDP (user datagram protocol) as transport layer protocol Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 2 Raj Kamal, Publs.: McGraw-Hill Education Internet enabled embedded system Addressed by an IP address Use IP (internet protocol) at network layer protocol Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 3 Raj Kamal, Publs.: McGraw-Hill Education MIME Format to enable attachment of multiple types of files txt (text file) doc (MSOFFICE Word document file) gif (graphic image format file) jpg (jpg format image file) wav format voice or music file Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 4 Raj Kamal, Publs.: McGraw-Hill Education A system at one IP address Communication with other system at another IP address using the physical connections on the Internet and routers Since Internet is global network, the system connects to remotely as well as short range located system. Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 5 Raj Kamal, Publs.: McGraw-Hill Education
    [Show full text]
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns
    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]
  • Network Layer Security Adaptation Profile
    Recommendation for Space Data System Standards NETWORK LAYER SECURITY ADAPTATION PROFILE RECOMMENDED STANDARD CCSDS 356.0-B-1 BLUE BOOK June 2018 Recommendation for Space Data System Standards NETWORK LAYER SECURITY ADAPTATION PROFILE RECOMMENDED STANDARD CCSDS 356.0-B-1 BLUE BOOK June 2018 RECOMMENDED STANDARD FOR NETWORK LAYER SECURITY ADAPTATION PROFILE AUTHORITY Issue: Recommended Standard, Issue 1 Date: June 2018 Location: Washington, DC, USA This document has been approved for publication by the Management Council of the Consultative Committee for Space Data Systems (CCSDS) and represents the consensus technical agreement of the participating CCSDS Member Agencies. The procedure for review and authorization of CCSDS documents is detailed in Organization and Processes for the Consultative Committee for Space Data Systems (CCSDS A02.1-Y-4), and the record of Agency participation in the authorization of this document can be obtained from the CCSDS Secretariat at the e-mail address below. This document is published and maintained by: CCSDS Secretariat National Aeronautics and Space Administration Washington, DC, USA E-mail: [email protected] CCSDS 356.0-B-1 Page i June 2018 RECOMMENDED STANDARD FOR NETWORK LAYER SECURITY ADAPTATION PROFILE STATEMENT OF INTENT The Consultative Committee for Space Data Systems (CCSDS) is an organization officially established by the management of its members. The Committee meets periodically to address data systems problems that are common to all participants, and to formulate sound technical solutions to these problems. Inasmuch as participation in the CCSDS is completely voluntary, the results of Committee actions are termed Recommended Standards and are not considered binding on any Agency.
    [Show full text]