DOCSLIB.ORG

Virtual Private Networks

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Virtual Private Networks Concepts & Examples ScreenOS Reference Guide Virtual Private Networks Release 6.3.0, Rev. 02 Published: 2012-12-10 Revision 02 Copyright © 2012, Juniper Networks, Inc. Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. JunosE is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785. Copyright © 2009, Juniper Networks, Inc. All rights reserved. Revision History December 2012—Revision 02 Content subject to change. The information in this document is current as of the date listed in the revision history. SOFTWARE LICENSE The terms and conditions for using this software are described in the software license contained in the acknowledgment to your purchase order or, to the extent applicable, to any reseller agreement or end-user purchase agreement executed between you and Juniper Networks. By using this software, you indicate that you understand and agree to be bound by those terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the software and may contain prohibitions against certain uses. The software license may state conditions under which the license is automatically terminated. You should consult the license for further details. For complete product documentation, please see the Juniper Networks Website at www.juniper.net/techpubs. END USER LICENSE AGREEMENT The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions of that EULA. ii Copyright © 2012, Juniper Networks, Inc. Abbreviated Table of Contents About This Guide . xvii Part 1 Virtual Private Networks Chapter 1 Internet Protocol Security . 3 Chapter 2 Public Key Cryptography . 35 Chapter 3 Virtual Private Network Guidelines . 61 Chapter 4 Site-to-Site Virtual Private Networks . 91 Chapter 5 Dialup Virtual Private Networks . 169 Chapter 6 Layer 2 Tunneling Protocol . 213 Chapter 7 Advanced Virtual Private Network Features . 241 Chapter 8 AutoConnect-Virtual Private Networks . 331 Part 2 Index Index . 361 Copyright © 2012, Juniper Networks, Inc. iii Virtual Private Networks iv Copyright © 2012, Juniper Networks, Inc. Table of Contents About This Guide . xvii Document Conventions . xviii Document Feedback . xx Requesting Technical Support . xx Part 1 Virtual Private Networks Chapter 1 Internet Protocol Security . 3 Introduction to Virtual Private Networks . 3 IPsec Concepts . 4 Modes . 5 Transport Mode . 5 Tunnel Mode . 6 Protocols . 7 Authentication Header . 7 Encapsulating Security Payload . 8 Key Management . 9 Manual Key . 9 AutoKey IKE . 9 Key Protection . 10 Security Associations . 10 Tunnel Negotiation . 11 Phase 1 . 11 Main and Aggressive Modes . 12 Diffie-Hellman Exchange . 13 Elliptical Curve Diffie-Hellman . 13 Phase 2 . 14 Perfect Forward Secrecy . 15 Replay Protection . 15 IKE and IPsec Packets . 15 IKE Packets . 15 IPsec Packets . 18 IKE Version 2 . 20 Initial Exchanges . 20 CREATE_CHILD_SA Exchange . 26 Informational Exchanges . 26 Enabling IKEv2 on a Security Device . 26 Example: Configuring an IKEv2 Gateway . 26 Authentication Using Extensible Authentication Protocol . 30 IKEv2 EAP Passthrough . 31 Example . 31 Copyright © 2012, Juniper Networks, Inc. v Virtual Private Networks Chapter 2 Public Key Cryptography . 35 Introduction to Public Key Cryptography . 35 Signing a Certificate . 35 Verifying a Digital Signature . 36 Elliptic Curve Digital Signature Algorithm . 36 Public Key Infrastructure . 37 Certificates and CRLs . 39 Requesting a Certificate Manually . 41 WebUI . 41 CLI . 42 Loading Certificates and Certificate Revocation Lists . 43 WebUI . 44 CLI . 44 Manual Certificate Renewal . 44 Configuring CRL Settings . 45 WebUI . 45 CLI . 46 Obtaining a Local Certificate Automatically . 46 WebUI . 47 CLI . ..
Load more

Recommended publications
  • Thesis Submitted for Examination for the Degree of Master of Science in Technology
    Extending the Functionality of the Realm Gateway Maria Riaz School of Electrical Engineering Thesis submitted for examination for the degree of Master of Science in Technology. Espoo 25.09.2019 Supervisor Prof. Raimo Kantola Advisors Juha-Matti Tilli Hammad Kabir Copyright ⃝c 2019 Maria Riaz Aalto University, P.O. BOX 11000, 00076 AALTO www.aalto.fi Abstract of the master’s thesis Author Maria Riaz Title Extending the Functionality of the Realm Gateway Degree programme Masters in Computer, Communication and Information Sciences Major Communications Engineering Code of major ELEC3029 Supervisor Prof. Raimo Kantola Advisors Juha-Matti Tilli, Hammad Kabir Date 25.09.2019 Number of pages 86 Language English Abstract The promise of 5G and Internet of Things (IoT) expects the coming years to witness substantial growth of connected devices. This increase in the number of connected devices further aggravates the IPv4 address exhaustion problem. Network Address Translation (NAT) is a widely known solution to cater to the issue of IPv4 address depletion but it poses an issue of reachability. Since Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS) application layer protocols play a vital role in the communication of the mobile devices and IoT devices, the NAT reachability problem needs to be addressed particularly for these protocols. Realm Gateway (RGW) is a solution proposed to overcome the NAT traversal issue. It acts as a Destination NAT (DNAT) for inbound connections initiated towards the private hosts while acting as a Source NAT (SNAT) for the connections in the outbound direction. The DNAT functionality of RGW is based on a circular pool algorithm that relies on the Domain Name System (DNS) queries sent by the client to maintain the correct connection state.
    [Show full text]
  • Abstract Introduction Methodology
    Kajetan Hinner (2000): Statistics of major IRC networks: methods and summary of user count. M/C: A Journal of Media and Culture 3(4). <originally: http://www.api-network.com/mc/0008/count.html> now: http://www.media-culture.org.au/0008/count.html - Actual figures and updates: www.hinner.com/ircstat/ Abstract The article explains a successful approach to monitor the major worldwide Internet Relay Chat (IRC) networks. It introduces a new research tool capable of producing detailed and accurate statistics of IRC network’s user count. Several obsolete methods are discussed before the still ongoing Socip.perl program is explained. Finally some IRC statistics are described, like development of user figures, their maximum count, IRC channel figures, etc. Introduction Internet Relay Chat (IRC) is a text-based service, where people can meet online and chat. All chat is organized in channels which a specific topic, like #usa or #linux. A user can be taking part in several channels when connected to an IRC network. For a long time the only IRC network has been EFnet (Eris-Free Network, named after its server eris.berkeley.edu), founded in 1990. The other three major IRC networks are Undernet (1993), DALnet (1994) and IRCnet, which split off EFnet in June 1996. All persons connecting to an IRC network at one time create that IRC network’s user space. People are constantly signing on and off, the total number of users ever been to a specific IRC network could be called social space of that IRC network. It is obvious, that the IRC network’s social space by far outnumbers its user space.
    [Show full text]
  • Internet Engineering Task Force A. Hutton Internet-Draft Unify Intended Status: Standards Track J
    Internet Engineering Task Force A. Hutton Internet-Draft Unify Intended status: Standards Track J. Uberti Expires: December 29, 2014 Google M. Thomson Mozilla June 27, 2014 HTTP Connect - Tunnel Protocol For WebRTC draft-hutton-httpbis-connect-protocol-00 Abstract This document describes a mechanism to enable HTTP Clients to provide an indication within a HTTP Connect request as to which protocol will be used within the tunnel established to the Server identified by the target resource. The tunneled protocol is declared using the Tunnel- Protocol HTTP Request header field. Label usage relating to the use of HTTP Connect by WebRTC clients (e.g. turn, webrtc) are described in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 29, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document.
    [Show full text]
  • Honeydv6 a Low-Interaction Ipv6 Honeypot
    HoneydV6 A low-interaction IPv6 honeypot Sven Schindler Potsdam University Institute for Computer Science Operating Systems and Distributed Systems Reykjavík, July 29, 2013 Outline 1 Introduction 2 An IPv6 darknet experiment 3 HoneydV6 - Development and Performance Measurements 4 Conclusion and Future work Sven Schindler (Potsdam University) HoneydV6 Frame 2 of 26 Introduction Outline 1 Introduction 2 An IPv6 darknet experiment 3 HoneydV6 - Development and Performance Measurements 4 Conclusion and Future work Sven Schindler (Potsdam University) HoneydV6 Frame 3 of 26 Introduction Why do we need IPv6 dark- and honeynets? huge IPv6 address space makes brute-force network scanning impossible new scanning approaches in the wild? attacks aiming at IPv6 design weaknesses how to analyse IPv6 related attacks? Sven Schindler (Potsdam University) HoneydV6 Frame 4 of 26 Introduction THC and si6 - IPv6 Attack Toolkits IPv6 attack tools like THC toolkit [3] and si6 [8] available fragment6 (THC) - duplicate fragments fake_router6 (THC) - become the default router rsmurf6 (THC) - remote smurf attack tool dos-new-ip6 (THC) - block new hosts from joining a network scan6 (si6) - intelligent scan approaches Sven Schindler (Potsdam University) HoneydV6 Frame 5 of 26 An IPv6 darknet experiment Outline 1 Introduction 2 An IPv6 darknet experiment 3 HoneydV6 - Development and Performance Measurements 4 Conclusion and Future work Sven Schindler (Potsdam University) HoneydV6 Frame 6 of 26 An IPv6 darknet experiment Prior darknet experiments Why another IPv6 Darknet
    [Show full text]
  • Ipsec Overhead in Wireline and Wireless Networks for Web and Email Applications
    IPSec Overhead in Wireline and Wireless Networks for Web and Email Applications George C. Hadjichristofi Nathaniel J. Davis, IV Scott F. Midkiff Bradley Department of Electrical and Computer Engineering Virginia Polytechnic Institute and State University Blacksburg, Virginia 2406 1 USA Abstract inserted in a system model to calculate the overall This paper focuses on characterizing the overhead of speedup when compression was used in different types of IP Security (IPSec)for email and web applications using networks. The research did not involve deploying test a set of test bed configurations. The different beds for “live” experimental measurements. confligurations are implemented using both wireline and Chappell, et al. did additional work [2]. The purpose wireless netwrk links. ne testing considers different of their research was to determine the suitability of IPSec combinations of authentication algorithms and for a Multiple Level Security environment. The research authentication protocols. Authentication algorithms used an experimental version of IPSec that was not include Hashed Message Authentication Code-Message optimized for performance. A simple IPSec wireline test Digest 5 (HMAC-MD5) and Hashed Message bed was deployed and various measurements were made. Authentication Code-Secure Hash Algorithm 1 (HMAC- The research did not investigate the overhead of using SHAl). Authentication protocols include Encapsulating authentication and encryption and the IPSec Security Payload (ESP) and Authentication Header (AH) implementation used only DES for confidentiality. protocols. Triple Digital Enclyption Standard (3DEq is The results presented in this paper are derived from used for encryption. Overhead is examined for scenarios actual measurements taken on wired and wireless test using no enclyption and no authentication, authentication beds and provide an expanded testing environment when and no encryption, and authentication and enclyption.
    [Show full text]
  • Delegating Network Security with More Information
    Delegating Network Security with More Information Jad Naous Ryan Stutsman Stanford University Stanford University California, USA California, USA [email protected] David Mazières Nick McKeown Nickolai Zeldovich Stanford University Stanford University MIT CSAIL California, USA California, USA Massachusetts, USA [email protected] [email protected] ABSTRACT network has become more centralized, enabling an admin- Network security is gravitating towards more centralized istrator to configure a consistent security policy at a single control. Strong centralization places a heavy burden on the location and have it enforced across various devices. Recent administrator who has to manage complex security policies proposals take centralization even further, proposing that al- and be able to adapt to users’ requests. To be able to cope, most all network features be pulled out of the datapath into the administrator needs to delegate some control back to a central controller [6, 5, 8, 10, 1], giving the administrator end-hosts and users, a capability that is missing in today’s direct control over routing, mobility, and access control. We networks. Delegation makes administrators less of a bottle- expect this trend to continue. neck when policy needs to be modified and allows network While there are many advantages to centralizing the con- administration to follow organizational lines. To enable del- trol of enterprise networks, such centralization places a heavy egation, we propose ident++—a simple protocol to request burden on the administrator. She needs to manage an in- additional information from end-hosts and networks on the creasingly complex set of rules, respond to user requests, path of a flow.
    [Show full text]
  • List of TCP and UDP Port Numbers from Wikipedia, the Free Encyclopedia
    List of TCP and UDP port numbers From Wikipedia, the free encyclopedia This is a list of Internet socket port numbers used by protocols of the transport layer of the Internet Protocol Suite for the establishment of host-to-host connectivity. Originally, port numbers were used by the Network Control Program (NCP) in the ARPANET for which two ports were required for half- duplex transmission. Later, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) needed only one port for full- duplex, bidirectional traffic. The even-numbered ports were not used, and this resulted in some even numbers in the well-known port number /etc/services, a service name range being unassigned. The Stream Control Transmission Protocol database file on Unix-like operating (SCTP) and the Datagram Congestion Control Protocol (DCCP) also systems.[1][2][3][4] use port numbers. They usually use port numbers that match the services of the corresponding TCP or UDP implementation, if they exist. The Internet Assigned Numbers Authority (IANA) is responsible for maintaining the official assignments of port numbers for specific uses.[5] However, many unofficial uses of both well-known and registered port numbers occur in practice. Contents 1 Table legend 2 Well-known ports 3 Registered ports 4 Dynamic, private or ephemeral ports 5 See also 6 References 7 External links Table legend Official: Port is registered with IANA for the application.[5] Unofficial: Port is not registered with IANA for the application. Multiple use: Multiple applications are known to use this port. Well-known ports The port numbers in the range from 0 to 1023 are the well-known ports or system ports.[6] They are used by system processes that provide widely used types of network services.
    [Show full text]
  • Implementation and Evaluation of Authorized Access LAN Sockets Using Pppoe
    Implementation and Evaluation of Authorized Access LAN Sockets Using PPPoE Hideo Masuda, Michio Nakanishi, Masahide Nakamura, Mio Suzuki Informedia and Education Division, Cybermedia Center, Osaka University 1-30 Machikaneyama, Toyonaka, Osaka, 560-0043 Japan. Telephone: +81 6 6850 6076, FAX: +81 6 6850 6084, E-mail:[email protected] our network Abstract Server The Internet This paper presents an integrated method to achieve au- thorized access on LAN sockets in a campus network. The LAN sockets PPPoE key issues of our method are user authentication and user server tracking. We adopt PPPoE (Point-to-Point Protocolover SwitchingHUB Ethernet) for the user authentication, and integrate IDENT mechanism on the PPPoE server for the user tracking. We conduct performance evaluation with respect to transfer rate and CPU usage. The evaluation shows that the pro- ClientPC ClientPC ClientPC ClientPC posed system achieves excellent performance for its deploy- client PCs(owned by user) ment cost. As a result, the proposed method could be a good candidate to add network connectivity in campus networks. Figure 1. Experimental environment achieves excellent performance for its deployment cost. 1 Introduction The system is actually working in the educational computer system in Cybermedia Center, Osaka University, also work- Rich network environment is a key to attract prospec- ing in a wireless LAN environment with IEEE802.11b. tive students to universities[1]. Recently, universities tend to provide students with LAN sockets in every classroom, 2 Implementing LAN sockets with PPPoE for fast and easy access to network resources. From the viewpoint of network administrators, however, it would be- Figure 1 shows an experimental environment of our sys- come an insecure hot bed of network crimes, unless users tem.
    [Show full text]
  • Technicolor Wireless Gateway - Cgm4231
    TECHNICOLOR WIRELESS GATEWAY - CGM4231 OPERATIONS GUIDE Version - Draft 1.1 Copyright © 2018 Technicolor All Rights Reserved No portions of this material may Be reproduced in any form without the written permission of Technicolor. Revision History Revision Date Description Draft 1.0 1/8/2018 Initial draft 1/8/2018 Proprietary and Confidential - Technicolor 2 Table of Contents 1 Introduction ............................................................................................................................ 7 2 Technicolor Wireless Gateway .............................................................................................. 8 2.1 System Information ....................................................................................................... 17 3 Initial Configuration and Setup ............................................................................................ 19 3.1 Accessing the WeBUI .................................................................................................... 19 4 WeBUI Guide ....................................................................................................................... 20 5 Status Pages ....................................................................................................................... 22 5.1 Overview ....................................................................................................................... 22 5.2 Gateway .......................................................................................................................
    [Show full text]
  • Delegating Network Security with More Information
    Delegating Network Security with More Information The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Naous, Jad et al. “Delegating network security with more information.” in WREN '09, Proceedings of the 1st ACM workshop on Research on enterprise networking, August 21, 2009, Barcelona, Spain, ACM Press. As Published http://dx.doi.org/10.1145/1592681.1592685 Publisher Association for Computing Machinery Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/67004 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike 3.0 Detailed Terms http://creativecommons.org/licenses/by-nc-sa/3.0/ Delegating Network Security with More Information Jad Naous Ryan Stutsman Stanford University Stanford University California, USA California, USA [email protected] David Mazières Nick McKeown Nickolai Zeldovich Stanford University Stanford University MIT CSAIL California, USA California, USA Massachusetts, USA [email protected] [email protected] ABSTRACT network has become more centralized, enabling an admin- Network security is gravitating towards more centralized istrator to configure a consistent security policy at a single control. Strong centralization places a heavy burden on the location and have it enforced across various devices. Recent administrator who has to manage complex security policies proposals take centralization even further, proposing that al- and be able to adapt to users’ requests. To be able to cope, most all network features be pulled out of the datapath into the administrator needs to delegate some control back to a central controller [6, 5, 8, 10, 1], giving the administrator end-hosts and users, a capability that is missing in today’s direct control over routing, mobility, and access control.
    [Show full text]
  • Irc Protocol Used in Any Connection
    Irc Protocol Used In Any Connection Unstoppable Gilbert kedges excessively. Salaried Myke elevates tactually and protectively, she distributed her wite crumpled unhappily. Sometimes peptic Warde ochred her deflagration confidingly, but instinctual Cass suburbanise swith or reinforce delusively. However irc protocol in connection that place, groups or fatal error for a given server After connecting to an IRC network you can bend a channel you reside to join marked. Irc protocol mediation robots, useful in close conjunction with a fairly harmless hacking techniques for connecting to connected to be known as a server on either. Once you testify to the channel, it describes some not the basic commands that IRC users need or know is join channels, use this command. How do faculty connect to IRC? This is called a channel takeover. Which is arbitrary but interesting. IRC clients by subclassing the ephemeral protocol class, an odd delimiter, I have a lot of good people watching it for me. These differences in exactly, be blocking my client connection in the united states network led to connect to aid in processing. Most IRC clients also triple the ability to share files. APIs to connect directly to IRC servers without needing a proxy. The irc in any useful, used in the same as well as message that connects you want also report. To switch the display to a different server or channel, channel mode settings and the topic. Infact, typically a nick. Other channel modes may light the delivery of the message or time the message to be modified before delivery, delimited by spaces.
    [Show full text]
  • CERIAS Tech Report 2002-41 a RECURSIVE SESSION TOKEN PROTOCOL for USE in COMPTUER FORENSICS and TCP TRACEBACK by Brian Carrier
    CERIAS Tech Report 2002-41 A RECURSIVE SESSION TOKEN PROTOCOL FOR USE IN COMPTUER FORENSICS AND TCP TRACEBACK by Brian Carrier & Clay Shields Center for Education and Research in Information Assurance and Security, Purdue University, West Lafayette, IN 47907 A Recursive Session Token Protocol For Use in Computer Forensics and TCP Traceback Brian Carrier Clay Shields Center for Education and Research in Department of Computer Science Information Assurance and Security (CERIAS) Georgetown University Purdue University Washington, D.C., 20007 West Lafayette, IN 47907 [email protected] [email protected] C C 0 1 C n−1 We present the Session TOken Protocol (STOP) [5], which H H H H H 0 1 2 n−1 n is based on the ident protocol, and helps forensic investiga- tion of stepping-stone chains while protecting the privacy of H H Fig. 1. Connection chain example between 0 and n users. STOP saves application-level data about the process and user that opened the socket, and can also send requests to pre- vious hosts to identify other hosts in the chain. At each stage, Abstract— We introduce a new protocol designed to assist in the forensic a hashed token is returned; at no point in the protocol does the investigation of malicious network-based activity, specifically ad- requester ever directly learn user or process data. Instead, they dressing the stepping-stone scenario in which an attacker uses a must redeem the token to the system administrator who can de- chain of connections through many hosts to hide his or her iden- termine the merit of releasing user information.
    [Show full text]