VPN Ipsec Tunnels with Cisco ASA/Asav VTI on Oracle Cloud Infrastructure
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Network Layer 2
Network Layer Topics • Network service models • Datagrams (packets), virtual circuits • IP (Internet Protocol) • Internetworking • Forwarding (Longest Matching Prefix) • Helpers: ARP and DHCP • Fragmentation and MTU discovery • Errors: ICMP (traceroute!) • IPv6, scaling IP to the world • NAT, and “middleboxs” • Routing Algorithms CSE 461 University of Washington 2 Dynamic Host Configuration Protocol (DHCP) Bootstrapping •Problem: • A node wakes up for the first time … • What is its IP address? What’s the IP address of its router? • At least Ethernet address is on NIC What’s my IP? CSE 461 University of Washington 4 Bootstrapping 1. Manual configuration (old days) • Can’t be factory set, depends on use 2. DHCP: Automatically configure addresses • Shifts burden from users to IT folk What’s my IP? Use A.B.C.D CSE 461 University of Washington 5 DHCP •DHCP (Dynamic Host Configuration Protocol), from 1993, widely used •It leases IP address to nodes •Provides other parameters too • Network prefix • Address of local router • DNS server, time server, etc. CSE 461 University of Washington 6 DHCP Protocol Stack •DHCP is a client-server application • Uses UDP ports 67, 68 DHCP UDP IP Ethernet CSE 461 University of Washington 7 DHCP Addressing •Bootstrap issue: • How does node send a message to DHCP server before it is configured? •Answer: • Node sends broadcast messages that delivered to all nodes on the network • Broadcast address is all 1s • IP (32 bit): 255.255.255.255 • Ethernet/MAC (48 bit): ff:ff:ff:ff:ff:ff CSE 461 University of Washington -
The GINI Router
The GINI Router: A Routing Element for User-level Micro Internet by Weiling Xu DEPARTMENT OF COMPUTER SCIENCE MCGILL UNIVERSITY, MONTREAL JUNE,2004 A THESIS SUBMITTED TO MCGILL UNIVERSITY IN PARTIAL FULFILMENT OF THE REQUlREMENTS OF THE DEGREE OF MASTER OF SCIENCE © Weiling Xu 2004 Library and Bibliothèque et 1+1 Archives Canada Archives Canada Published Heritage Direction du Branch Patrimoine de l'édition 395 Wellington Street 395, rue Wellington Ottawa ON K1A ON4 Ottawa ON K1A ON4 Canada Canada Your file Votre référence ISBN: 0-494-06476-5 Our file Notre référence ISBN: 0-494-06476-5 NOTICE: AVIS: The author has granted a non L'auteur a accordé une licence non exclusive exclusive license allowing Library permettant à la Bibliothèque et Archives and Archives Canada to reproduce, Canada de reproduire, publier, archiver, publish, archive, preserve, conserve, sauvegarder, conserver, transmettre au public communicate to the public by par télécommunication ou par l'Internet, prêter, telecommunication or on the Internet, distribuer et vendre des thèses partout dans loan, distribute and sell th es es le monde, à des fins commerciales ou autres, worldwide, for commercial or non sur support microforme, papier, électronique commercial purposes, in microform, et/ou autres formats. paper, electronic and/or any other formats. The author retains copyright L'auteur conserve la propriété du droit d'auteur ownership and moral rights in et des droits moraux qui protège cette thèse. this thesis. Neither the thesis Ni la thèse ni des extraits substantiels de nor substantial extracts from it celle-ci ne doivent être imprimés ou autrement may be printed or otherwise reproduits sans son autorisation. -
List of TCP and UDP Port Numbers - Wikipedia, the Free Encyclopedia 6/12/11 3:20 PM
List of TCP and UDP port numbers - Wikipedia, the free encyclopedia 6/12/11 3:20 PM List of TCP and UDP port numbers From Wikipedia, the free encyclopedia (Redirected from TCP and UDP port numbers) 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 communications. Originally, these port numbers were used by the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP), but are used also for the Stream Control Transmission Protocol (SCTP), and the Datagram Congestion Control Protocol (DCCP). SCTP and DCCP services usually use a port number that matches the service 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.[1] However, many unofficial uses of both well-known and registered port numbers occur in practice. Contents 1 Table legend 2 Well-known ports: 0–1023 3 Registered ports: 1024–49151 4 Dynamic, private or ephemeral ports: 49152–65535 5 See also 6 References 7 External links Table legend Color coding of table entries Official Port/application combination is registered with IANA Unofficial Port/application combination is not registered with IANA Conflict Port is in use for multiple applications (may be official or unofficial) Well-known ports: 0–1023 The port numbers in the range from 0 to 1023 are the well-known ports. They are used by system processes that provide widely-used types of network services. -
Guidelines for the Secure Deployment of Ipv6
Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. -
RFC 6349 Testing with Truespeed™ from JDSU—Experience Your
RFC 6349 Testing with TrueSpeed™ from JDSU— Experience Your Network as Your Customers Do RFC 6349 is the new transmission control protocol (TCP) throughput test methodology that JDSU co-authored along with representatives from Bell Canada and Deutsche Telecom. Recently issued by the Internet Engineering Task Force (IETF) organization, RFC 6349 provides a repeatable test method for TCP throughput analysis with systematic processes, metrics, and guidelines to optimize the network and server performance. This application note summarizes RFC 6349, “Framework for TCP Throughput Testing,” and highlights the automated and fully compliant JDSU RFC 6349 implementation, TrueSpeed, now available on the JDSU T-BERD®/MTS-6000A Multi-Services Application Module (MSAM) and T-BERD/MTS-5800 Handheld Network Tester. This application note also discusses the integration of TrueSpeed RFC 6349 with the ITU Y.1564 Ethernet service activation standard. This powerful testing combination provides a comprehensive means to ensure an optimized end-customer experience in multi-service (such as triple play) environments. RFC 6349 TCP Test Methodology RFC 6349 specifies a practical methodology for measuring end-to-end TCP throughput in a managed IP network with a goal of providing a better indication of the user experience. In the RFC 6349 framework, TCP and IP parameters are also specified to optimize TCP throughput. RFC 6349 recommends always conducting a Layer 2/3 turn-up test before TCP testing. After verifying the network at Layer 2/3, RFC 6349 specifies conducting -
Edition with Romkey, April 16, 1986 (PDF)
PC/IP User's Guide MASSACHUSETTS INSTITUTE OF TECHNOLOGY Laboratory For Computer Science Network programs based on the DoD Internet Protocol for the mM Personal Computer PC/~ release or March, 1986; document updated Aprill4, 1986 by: Jerome H. Saltzer John L. Romkey .• Copyright 1984, 1985, 1986 by the Massachusetts Institute or Technology Permission to use, copy, modlt'y, and distribute these programs and their documentation ror any purpose and without ree ls hereby granted, provided that this copyright and permission notice appear on all copies and supporting documentation, the name or M.I.T. not be used in advertising or publlclty pertalnlng to dlstrlbutlon or the programs without written prior permission, and notice be glven in supporting documentation that copying and distribution ls by permlsslon or M.I.T. M.I.T. makes no representations about the suitablllty or this software for any purpose. It is provided "as ls" without express or Implied warranty. - ii - CREDITS The PC/IP packages are bullt on the work of many people in the TCP/IP community, both at M.I.T. and elsewhere. Following are some of the people who directly helped in the creation of the packages. Network environment-John L. Romkey Terminal emulator and customizer-David A. Bridgham Inltlal TFTP-Kari D. Wright Inltlal telnet-Louls J. Konopelskl Teinet model-David D. Clark Tasking package-Larry W. Allen Development system-Christopher J. Terman Development environment-Wayne C. Gramlich Administrative Assistant-Muriel Webber October 3, 1985. This document is in cover .mss - iii- - iv Table of Contents 1. Overview of PC/IP network programs 1 1.1. -
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. -
The PTB-PTS ICMP-Based Attack Against Ipsec Gateways Vincent Roca, Saikou Fall
Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways Vincent Roca, Saikou Fall To cite this version: Vincent Roca, Saikou Fall. Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways. 2016, pp.16. hal-01178390 HAL Id: hal-01178390 https://hal.inria.fr/hal-01178390 Submitted on 19 Jul 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. IPsec Maintenance and Evolution (IPSECME) V. Roca Internet-Draft S. Fall Intended status: Informational INRIA Expires: January 7, 2016 July 6, 2015 Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways draft-roca-ipsecme-ptb-pts-attack-00 Abstract This document introduces the "Packet Too Big"-"Packet Too Small" Internet Control Message Protocol (ICMP) based attack against IPsec gateways. We explain how an attacker having eavesdropping and packet injection capabilities, from the unsecure network where he only sees encrypted packets, can force a gateway to reduce the Path Maximum Transmission Unit (PMTU) of an IPsec tunnel to the minimum, which can trigger severe issues for the hosts behind this gateway: with a Linux host, depending on the PMTU discovery algorithm in use (i.e., PMTUd versus PLPMTUd) and protocol (TCP versus UDP), the attack either creates a Denial of Service or major performance penalties. -
Exploring Usable Path MTU in the Internet
Exploring usable Path MTU in the Internet Ana Custura Gorry Fairhurst Iain Learmonth University of Aberdeen University of Aberdeen University of Aberdeen Abstract—To optimise their transmission, Internet endpoints methodologies and tools [7] [8], providing an up-to-date need to know the largest size of packet they can send across PMTUD behaviour report for both IPv4 and IPv6. a specific Internet path, the Path Maximum Transmission Unit We include an in-depth exploration of server and client (PMTU). This paper explores the PMTU size experienced across the Internet core, wired and mobile edge networks. advertised Maximum Segment Size (MSS), taking advantage Our results show that MSS Clamping has been widely deployed of existing measurement platforms, MONROE [9] and RIPE in edge networks, and some webservers artificially reduce their Atlas [10], and using or extending existing tools Netalyzr [11] advertised MSS, both of which we expect help avoid PMTUD and PATHspider [12]. failure for TCP. The maximum packet size used by a TCP We also look at ICMP quotation health and analyze a connection is also constrained by the acMSS. MSS Clamping was observed in over 20% of edge networks tested. We find a large number of ICMP quotations from a previous large- significant proportion of webservers that advertise a low MSS scale measurement campaign. These results provide important can still be reached with a 1500 byte packet. We also find more insight to inform the design of new methods that can robustly than half of IPv6 webservers do not attempt PMTUD and clamp discover the PMTU for UDP traffic where there are currently the MSS to 1280 bytes. -
ICMP Attacks Against TCP
ICMP attacks against TCP Author: Fernando Gont Email: [email protected] http:/ /www.gont.com.ar Universidad Tecnológica Nacional February 200 6 Internet -Draft / ICMP attacks against TCP OWASP Papers Program February , 2006 Table of Contents Abstract .............................................................................................................................................. 3 A1 Introduction........................................................................................................................... 4 A2 Background ............................................................................................................................ 5 A2.1 The Internet Control Message Protocol (ICMP) .................. 5 2.1.1 ICMP for IP version 4 (ICMP) ................................ ...... 5 2.1.2 ICMP for IP version 6 (ICMPv6) ................................ .... 5 A2.2 Handli ng of ICMP error messages ............................... 6 A3 Constraints in the possible solutions ................................................................................... 7 A4 General counter -measures against ICMP attacks ............................................................. 8 A4.1 TCP sequence number checking ................................ .. 8 A4.2 Port randomization ................................ ............ 8 A4.3 Fil tering ICMP error messages based on the ICMP payload ....... 9 A5 Blind connection-reset attack ............................................................................................ -
On Improved Generalization of 5-State Hidden Markov Model-Based Internet Traffic
On Improved Generalization of 5-State Hidden Markov Model-based Internet Traffic Classifiers by Grant H. R. Bartnik A Thesis presented to The University of Guelph In partial fulfilment of requirements for the degree of Master of Science in Computer Science Guelph, Ontario, Canada c Grant H. R. Bartnik, May, 2013 ABSTRACT On Improved Generalization of 5-State Hidden Markov Model-based Internet Traffic Classifiers Grant H. R. Bartnik Advisors: University of Guelph, 2013 Dr. Stefan C. Kremer The multitude of services delivered over the Internet would have been diffi- cult to fathom 40 years ago when much of the initial design was being undertaken. As a consequence, the resulting architecture did not make provisions for differentiating between, and managing the potentially conflicting requirements of different types of services such as real-time voice communication and peer-to-peer file sharing. This shortcoming has resulted in a situation whereby services with conflicting require- ments often interfere with each other and ultimately decrease the effectiveness of the Internet as an enabler of new and transformative services. The ability to passively identify different types of Internet traffic then would address this shortcoming and enable effective management of conflicting types of services, in addition to facilitating a better understanding of how the Internet is used in general. Recent attempts at developing such techniques have shown promising results in simulation environments but perform considerably worse when deployed into real-world scenarios. One possi- ble reason for this descrepancy can be attributed to the implicit assumption shared by recent approaches regarding the degree of similarity between the many networks which comprise the Internet. -
TCP/IP Explained
TCP/IP Explained PHILIP MILLER DIGITAL PRESS Boston Oxford Johannesburg Melbourne New Delhi Singapore Table of Contents Preface xvii Chapter 1 - Introduction 1 1.1 What is TCP/IP? 1 1.1.1 A Brief History of TCP/IP 2 1.1.2 The Internet Protocol Suite 3 1.2 The Internet 5 1.2.1 The Growth of the Internet 6 1.3 Summary 9 Chapter 2 - Standardization 11 2.1 The Internet Architecture Board 11 2.1.1 The Internet Engineering Task Force 12 2.1.2 The Internet Research Task Force 13 2.2 Internet Protocol Standards 13 2.2.1 Protocol States 14 2.2.2 Protocol Status 16 2.2.3 The Request For Comments (RFC) 16 2.3 Internet Protocol Architecture 17 2.3.1 The Open Systems Interconnection (OSI) Model 18 2.3.2 The OSI Model and LANs 20 2.3.3 The Internet Protocol Suite Model 23 2.4 A Comparison of Major Architectures 25 2.5 Summary 26 Chapter 3 - An Overview of Network Technologies and Relay Systems 27 3.1 Ethernet and IEEE 802.3 27 3.1.1 802.3 Specifications 27 3.1.2 Ethernet/802.3 Frame Structure 30 3.1.3 Ethernet/802.3 Operation 32 3.2 Token Ring 33 3.2.1 802.5 Specifications 34 3.2.2 802.5 Frame Structure 36 3.2.3 802.5 Operation 38 3.3 Fibre Distributed Data Interface (FDDI) 39 3.3.1 FDDI Specifications 41 3.3.2 FDDI Frame Structure 42 3.3.3 FDDI Operation 43 3.4 Relay Systems 43 3.4.1 Repeaters 44 3.4.2 Bridges 45 3.5 WAN Links 50 3.6 Summary 51 Chapter 4 - Internet Addressing 53 4.1 The Need for an Addressing Scheme 53 4.2 Internet Addressing 54 4.2.1 Dotted Decimal Notation 55 4.2.2 Identifying IP Addresses and Rules 56 4.2.3 Choosing the Right Addressing