Top Banner

of 118

vpn ipsec research report

Apr 03, 2018

Download

Documents

mohammedakbar88
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • 7/28/2019 vpn ipsec research report

    1/118

    INFORMATION TO USERS

    This manuscr ipt has been reproduced trom the microfilm master. UMI filmsthe text diredly from the original or copy submitted. Thus, sorne thesis anddissertation copies are in typewriter face, while others may be tram any type ofcomputer printer.

    The quailly of thl. reproduction 1. dependent upon the quail ly of thecopy submltted. Broken or indistind print, colored or poor quality illustrationsand photographs, print bleedthrough, substandard margins. and improperalignment can adversely affect reproduction.

    ln the unl ikely event that the author did not sand UMI a complete manuscr iptand there are missing pages, these will be noted. Also, if unauthorizedcopyright material had to be removed, a note will indicate the deletion.

    Oversize materials (e.g., maps, drawings, charts) are reproduced bysectioning the original, beginning at the upper left-hand corner and continuingtrom left ta right in equal sections with small overlaps.

    ProQuest Information and Leaming300 North Zeeb Raad, Ann Arbor, MI 481Q6.1346 USA800-521-0600

  • 7/28/2019 vpn ipsec research report

    2/118

  • 7/28/2019 vpn ipsec research report

    3/118

    IPSec Base Virtual Private Network

    Carlton Roy DavisSchool of Computer Science

    McGill University, Montreal, Canada.May 2000

    A thesis submitted ta the faculty of Graduate Studies and Research inpartial fulfillment of the requirement for the degree of Master in

    Computer Science.

    Carlton Roy Davis 2000

  • 7/28/2019 vpn ipsec research report

    4/118

    I ~ I ~ and AcquiIitioI. etBibIiognIphic SeMees . . . . bibliographique

    The autbor bas granted a DOD-exclusive licence aIlowing theNatioaal LibJary ofCanada tareproduce, loan, distnbute or seOcopies of tbis thesis in microfonn,paper or electroDic formats.

    The author retaiDs ownersbip of thecopyrisbt in this thesis. Neither thetbesis Dor substantial extracts from itmay be printed or otherwisereproduced without the author'spermissioD.

    L \9auteur a accord une licence DOBexclusive permettant laBibliothque oatiouale du Canada dereproduire, prter, distribuer ouvendre des copies de cette thse sousla forme de m i c r o f i c h e l ~ dereproduction sur papier ou sur formatlectronique.L'auteur conserve la proprit dudroit d'auteur qui protge cette thse.Ni la thse Di des extraits substantielsde celle-ci ne doivent tre imprimsou autrement reproduits sans sonautorisatioD.

    0-612-70700-8

    Canadl

  • 7/28/2019 vpn ipsec research report

    5/118

    Abstract

    The Internet evolved from an experiential packet-switching network called theARPANET. This network has grown exponentially since its conversion from an experimental to an operational network in 1975. H o w e v e r ~ the need for confidential andsecure data channel has dissuaded manyenterprises from using this ubiquitous public infrastructure. The IPSec protocol sui te developed by the Internet EngjneeringTask Force (IETF) makes it possible to implement secure communication channelsor virtual private network (VPN) over the Internet. Corporations cao benefit fromsubstantial financial savings by utilizing VPN for inter-company or intra-companycommunications rather than using expensive lease or privately own network infrastructure with its associated high main tenance costs. In this thesis, we will discussthe architecture, design and use of IPSec base VPN.

    RsumL'internet a volu d'un rseau exprimental de "paeket-switching" appel

    ARPANET. Ce rseau a grandi exponentiellement depuis sa transformation d'unrseau exprimenta l un rseau opra tionnel en 1975. C e p e n d a n t ~ les besoins demdia de transfert de donnes la fois confidentiels et scuritaires ont dissuad beaucoup d'entreprises d'utiliser cette infrastructure publique omniprsente. La sui te deprotocoles IPSec dvelope par la Internet Engeneering Task Force (IETF) rend possible rimplmentation de canaux de communication ou de rseau.x privs virtuels(VPN) par-dessus Internet. Les entreprises peuvent bnficier d!conomies montairessubstantielles en utilisant les VPN pour leurs communications internes ou externesplutt que d'utiliser des inf rastruc tures prives coteuses qui de plus cotent trscher maintenir . Dans ce mmoire, nous discuterons l ' a r c h i t e c t u r e ~ la conception etrutilisation d'un V P ~ bas su r le protocole IPSec.

  • 7/28/2019 vpn ipsec research report

    6/118

    Acknowledgement

    1 would lib to express my appreciation to my supervisor Prof. Ratzer for the helphe provided for this research project. 1 wish also ta say a special thank you to LueBoulianne for spurring my interest initially in this subject area. Thanks also tu Prof.Dini and his research colleagues at C R I ~ 1 who provided sorne assistance during theearly stage of the research.

    1 am very grateful for the support and encouragement 1 received Crom my familyand friends.

    Finally, 1 wish to say thanks to McGill University for providing the facilities forme to do the research.

  • 7/28/2019 vpn ipsec research report

    7/118

    Contents

    1 Introduction 41.1 fvlotivation . . .. . . . -l1.2 Thesis Organization. . .. .. . .. .. 6

    2 Tep /IP Overview 82.1 Sorne History .. .. .. . . . ... 82.2 Tep jIP Protocol architecture . 9

    2.2.1 Data-link Layer . 102.2.2 Network Layer 102.2.3 Transport Layer . 172.2.4 Application Layer . . 18

    3 Cryptographie Techniques 193.1 The Data Encryption Standard 193.1.1 DES ~ [ o d e of Operation 283.1.2 DES implementation .. .. .. . . 303.1.3 Triple DES .. .. .. .. .. . . . . . . . . . . 303.1.4 Other Private Key Cryptosystems . 31

    3.2 Public Key Cryptosystems 323.2.1 RSA Cryptosystem 333.2.2 EIGamal Cryptosystem . 343.2.3 Diffie-Hellman Key Exchange 353.2.4 Other Public-key Cryptosystems . .. .. .. .. .. 37

    1

  • 7/28/2019 vpn ipsec research report

    8/118

    3.2.5 Comparison of Private and Public-key Cryptosystems ..3.3 Hash Functions and ~ I A C .

    3.3.1 MD5 Hash Function3.3.2 Secure Hash Aigorithm (SHA-l) .3.3.3 HMAC . . . . .

    3.4 Digital Signatures .3.4.1 Digital Signature Standard .

    4 IP Security Architecture4.1 What IPSec Does .4.2 How IPSec Works ..4.3 Security Association4.4 Security Association Databases

    4.4.1 Security Poliey Database ..4.4.2 Security Association Database .

    383839434546-17

    505051

    535355

    5.15 Authentication Header

    Authentication Header Fonnat .Authentication Header ~ [ o d e s5.2.1 AH Transport ~ [ o d e5.2.2 AH Tunnel ~ [ o d e

    5.3 AH Processing .5.3.1 Outbound Processing .5.3.2 Inbound Processing ..

    6 Encapsulating Security Payload6.1 ESP Packet Fonnat .6.2 ESP :\-[odes . . . . . .

    6.2.1 ESP Transport ~ [ o d e ..6.2.2 ESP Tunnel ~ I o d e6.3 ESP Processing . . . . . . .

    2

    57585959

    ..... 61636364

    6666686868iD

  • 7/28/2019 vpn ipsec research report

    9/118

    6.3.16.3.2

    Outbound Processing . .Inbound Processing .

    7072

    7 Internet Key Exchange7.1 ISAKMP .

    7.1.1 I S A K ~ I P Header Format ..7.1.2 ISAKrvlP Payloads Formats

    7.2 Excha nge s . . . . . . . . .7.2.1 Exchange Phases7.2.2 Exchange ~ I o d e s

    7.3 Oakley Groups . . . . .8 VPN Solutions8.1 Interconnecting Branch Offices .

    8.2 Interconnecting Different Company's Intra-net8.3 Addressing Issues8.4 Routing Issues.

    9 Conclusion

    3

    7575757987878896

    9899102102103

    106

  • 7/28/2019 vpn ipsec research report

    10/118

    Chapter 1Introduction

    1.1 MotivationIn th e rnid 1960's [Tan96] in th e height of th e cold war, th e Department of Defense(000) in th e USA wanted a c om ma nd a n d control network that could survive a nuclear war. Th e DoD consequently cornmissioned its research arm- ARPA (AdvanceResearch Project Agency)-to invent th e technology that could get data to its destination reliably even if arbitrary part of th e network disappeared without warning asa result of a nuclear attack.

    Traditional telephone technology called circuit switching would not work becauseit had serious drawbacks. In circuit switching, a route for dat a ta get from one placet o a no th er is se t up by using relays ta make physicaI connections among pieces ofcable. Therefore, i f part of th e circuit fails, a new circuit must he set up. whichcould he quite difficult a nd t im e consuming depending on th e severity of t he d am ag e[CQ93}.

    ARPA used a different kind of technology called packet switching. Th e idea ofpacket switching network was proposed by Paul Saran (Bar64]. In packet S\\;tching,data to he sent over th e network is divided up into discrete parts called packets. Eachpacket is routed independently from one computer ta the next over th e network untilit reaches its final destination.

    Th e first experimental network-calle1 th e ARPANET- w e n t into being in De-

  • 7/28/2019 vpn ipsec research report

    11/118

    cember 1969. It consisted of subnets an d hosts computers. Th e subnets consisted ofminicomputers called INIPs (Interface ~ [ e s s a g e Processors) connected by transmissionlines. This network contained four oodes, one each at UCLA (University of Califomiaat Los AngelesL UCSB (University of Califomia at Santa Barbara), SRI (StanfordResearch Institute) an d University of Utah. Each node o f t he network composed ofan Il'JIP an d an hast in t he sa me room, connected by wires. These four sites werechosen because all ha d large ARPA contracts; additionally, all four sites ha d differentand completely incompatible computers. This experimental network grew rapidly: inJuly 1970 it grew to eight nodes, by ~ [ a r c h 1971 i t expanded ta sixteen nodes, inApril 1972 it grew ta twenty three nodes an d by September 1972 it consisted of thirtyfour nodes [Tan96J.

    In th e 1983 TC P /IP protocois were adopted as th e only official protocol o f theARPANET. During the same year the term Internet came into common usage. Th eold ARPANET was divided into ~ n L ~ E T , th e unclassified p ar t o f the Defense Data

    ~ e t w o r k (DON), an d a new smaller ARPANET. Th e "Internet" was used to referto th e entire network: th e ~ n L N E T plus the ARPANET [Hun98J. Many regionalnetworks in th e USA joined up to the Internet. In the rnid 1 9 8 0 ~ s trans-Atlantic fiberoptic cables were laid an d consequently, networks in Europe, th e Pacifie region andCanada were conneeted to th e Internet. Growth of the Internet eontinued exponen

    t i a l l y ~ an d by 1995 there were multiple backbones, hundreds of regional networks, tensof thousands of Local Area :'1etworks ( L A ~ ' s ) , millions of hasts, and tens of millionsof users. At th e close of the twentieth century almost every nation is connected tothe Internet.

    Th e ubiquitous nat ure of t he Internet has raised many security concerns. Th eprincipal concern over th e years is the fact that IP packets are inherently insecure.It is relative easy to forge IP addresses, modify th e contents of IP packets. replay oidcontent an d inspect th e content of packets in transit. Therefore, there is no guaranteet ha t t he IP datagrams originated from th e source it daims to originate f r o m ~ or thati t will get to the intended destination, or that the contents have no t been modifiE'd orexamined by a t hi rd p a rt y while i t was in transit from the source to the destination.

    5

  • 7/28/2019 vpn ipsec research report

    12/118

    These security concems have dissuaded many corporation from using the Internetto transmit sensitive electronic data even though the price of bandwidth over theInternet has fallen considerably over the years. These corporations continue to useexpensive leased or privately own oetworks infrastructure with their high associatesupport and maintenance cost to transmit intra or inter-company electronic data.

    IPSec-the IP security protocol developed by the Internet Engineering Task Force(IETF) in the late 199's-has addressed most of the security issues of the IP datagram. With IPSec authenticatioo, i t is possible to detect if an original IP datagramhas been modified, thus adding sorne guarantee to the origin and integrity of the data;it also provides data content confidentially and replay protection.

    The main contribution of this thesis is to examine the components of IPSec andpresent different designs of IPSec based Virtual Private Network (VP:'I) that enterprises can use to transmit confidential electronic data over the Internet.

    1.2 Thesis OrganizationThis thesis is organized as follows: Chapter 2 gives an overview of TCP IIP. Section2.1 gives a brier history presenting the motivation for the development of this protocolsuite; and Section 2.2 looks at the TCPIIP protocol architecture and the four layersof the TCPIIP protocol stack.

    Chapter 3 gives an overnew of cryptographie techniques relevant to the IPSec protocol. Section 3.1 examines the Data Encryption Standard (DES) and other privatekey cryptographic protocols. Section 3.2 looks at the design principle and applicationof commonly used public-key cryptosystems. Section 3.3 examines the design of twocryptographie hash functions and a ~ [ e s s a g e Authentication Code ( ~ I A C ) . The finalSection in this chapter looks at digital signatures and examines the Digital SignatureStandard COSS).

    Chapter 4 examines the IPSec architecture and introduces sorne of the camponents of this seeurity protocol. Section 3.1 explains what IPSec d o e s ~ section 3.2explains how IPSec works. section 3.3 presents the concept of Security Association

    6

  • 7/28/2019 vpn ipsec research report

    13/118

    (SA), section 3.4 looks at IPSec Security Association Databases and finally, Section3.5 looks at SA and key management.

    Chapters 5 to 7 give detail OD the main components of IPSec. Chapters 5 and6 look at IPSec Authentication Header (AH) and Encapsulating Security Payload(ESP) respectively; each chapter discusses the the component's format, the differentmodes of these components, and the processing of the components. Chapter 7 looksat the Internet Key Exchange (IKE) protocol. Section 7.1 examines the cornponentsof Internet Security Association and Key Management Protocol (ISAK:\tlP) that IKEutilizes. Section 7.2 discusses the IKE exchange types; and the final section in thischapter presents the groups that cao be utilized for the Dffie-Hellman key e.xchange.

    Chapter 8 presents sorne IPSec based VPN solutions; and discusses relevant issues.such as addressing and routing. Finally, Chapter 9 concludes the research and makesorne recommendations for further study.

    7

  • 7/28/2019 vpn ipsec research report

    14/118

    Chapter 2TCP /IP Overview-2.1 Sorne HistoryIn December 1969 ARPA (Advance Research Project Agency)-the research ar m ofth e USA Department of Defense (000) commissioned the first experimental network.This network-called th e A R P A ~ E T consisted of four nodes, one each at CCLA(University of California at Los Angeles), UCSB (University of California at SantaBarbara), SR I (Stanford Research Institute) and University of Vtah. Th e network wasdeveloped in response ta th e DoD desire for a network that could withstand a oudear\Var. Th e DoD \Vanted a network that \Vould keep connections intact provided thatthe source an d the destination machines were functioning, even if sorne componentsof th e network disappear without warning. This network worked weIl in its earlystage when there \Vere few nodes. H o w e v e r ~ as th e number of nodes increased thenetwork was subjected to a number of system crashes [An098]. Additionally! whensatellite an d radio networks \Vere added to th e ARPANET in th e early 1970's. ~ e t w o r kControl Protocol C ~ C P ) [ ~ K P C 7 0 I , the existing protocol of the ARPAXET! hadtrouble working \Vith these networks. As a r e s u l t ~ research for a new protocol that\Vas robust an d able to \Vork well with different kinds of network! started in th e early1970's. Th e research effort culminated with the development of th e TC P /I P protocolsuite in 1974 [CK74]. A later perspective of this protocol is given in [ L C P ~ I 8 5 ] an dit s design philosophy is describe in [CIa88) .

    8

  • 7/28/2019 vpn ipsec research report

    15/118

    The Tep /IP protoeol suite prove

    1 FTP Il TELNETII DNS Il SMTP 11 1 1TCP UDP

    1 IP 1 1 ICMP 1 1 IGMP 1

    1 ARP t 1 RARP[

    Application layer

    Transport layerNetwork layer

    Data-link layer

    Figure 2.1: Protocols at the four layers of the TCP /IP protocol suite.

    9

  • 7/28/2019 vpn ipsec research report

    16/118

    2.2.1 Data-link LayerThe data-link layer is a1so called the link or network access layer. 1t is the lowestlayer of the Tep/IP protocol stack. Example of data-link layers are Ethernet, TokenRing and ATM (Asynchronous Transfer Mode). For information on Ethernet refer ta[MB76], for information on Token Ring see [LR..-\92], and for further detail on ATMsee [FWWD94], [Gor95] and [Kya95]. The protocols in data-link layer provide meansfor the system ta deliver data ta other devices on the network. These protocols mustknow details such as the packet structure and addressing scheme of the underliningnetwork. Two of the protocols in tbis layer are ARP (Address Resolution Protocol)!which maps IP address to Ethernet address; and R...\RP (Reverse Address ResolutionProtocol), which maps Ethernet address to IP address. See [Plu821 and [ F T ~ [ T 8 4 ]for further information on these protocols.\Vhen the data-link layer receives a packet from the network layer-the layer

    above i t - i t encapsulates the packet with the appropriate header then sends it via thephysical network to the specified device. The reverse occurs when a packet arrivesfrom the physical network to the data-link layer: the layer removes the data-linkheader then sends the packet up to the network layer for processing. This is illustratedin Figure 2.2.

    2.2.2 Network LayerThe network layer is also called the internet layer. This layer is responsible for therouting of packets from the source to the destination. The network layer consistsof three protocols: Internet Control Protocoi ( I C ~ f P L Internet Group ~ I a n a g e m e n tProtocoi ( I G ~ I P ) and Internet Protocol (IP).

    The official spec:fication of ICMP is outlined in [Pos81bl. I C ~ I P is the protocolthat is used ta communicate error conditions that occurred during the transmission ofIP packets. The I C ~ [ P message is usually encapsulated in the IP datagram. Anotherimportant raIe of I C ~ ! P is the debug of network connectivity problems. The populardebugging tools: ping and traceroute use this protocol.

    10

  • 7/28/2019 vpn ipsec research report

    17/118

    Application layer I H ~ I Data 1T ~ ~ r t l ; Y ~ ~ - - - - - - - - - - - - - - - - - - - - - ~ - " - - - - - - - -

    1Head 1Header : Data 1~ e ~ ~ k ~ ; ~ - - - - - - - - - - - - - - - - - - - ~ - - - - ~ - - - - - - - -

    1Header 1Header : Header : Data 1D ~ ~ ~ ~ ~ ~ ~ ; - - - - - - - - - - - - ~ - - - - - - - - - - ~ - - - - - - - -

    IHeadctl Header: Header : Header : Data+ Send . . Rcceive

    Figure 2.2: Encapsulation and de-capsulation of data as it goes down and up theprotocol stack, respectively.

    IGAfP is the protocol that is used by hosts and routers ta ascertain informationabout the hosts in a multicast groups: groups of hasts ta which IP datagrams are tobe sent simultaneously. As is the case with ICNIP, IG messages are encapsulatedin IP datagrams. For further detail on IGNIP rerer to [Dee89] which contains theoriginal specification of I G ~ [ P .

    IP is the protocol that holds the whole Tep /IP protocol suite architecture together. The data of the protocols in all of the layers of the Tep /IP protocol s t a c k ~except the data-link l a y e r ~ are transmitted as IP datagrams. IP allows hosts to inject packets into the data-link layer-which eventually puts them on the physicalnetwork-and have them travel on potentially different networks to their final destination. IP offers a connectionless service. In connectionless s e r v i c e s ~ each message ordatagram carries the full destination address, and is routed independently of the otherdatagrams. \Vith connectionless services, it is possible for the datagrams to arrive at

    Il

  • 7/28/2019 vpn ipsec research report

    18/118

    their destination in ditrerent order that they were sent. Whereas, this is not possiblewith connection-oriented services, since the latter is like a telephone system whichestablishes a connection or a path from the host to the destination, uses the path tosend data, then releases the connection after the data transmission is completed.

    There are two versions of IP that are available for use with the TCP/IP protocolsuite: IPv4 and IPv6 l . The format of the datagrams of these t"'o protocols a rediscussed in the following two sections.

    IPv4 Datagrams FormatAn IP datagram consists of a header portion and a data portion. The header portionconsists of a 20 bytes fixed part and a variable length optionai par t. The data portionis of variable length. Figure 2.3 shows the format of an IPv4 datagram. An IPdatagram is transmitted in big endian byte order: from left to right! that is, lowerorder bytes are transmitted first. This is the byte ordering required for ail binaryintegers in the TCP/IP headers as they traverse a network. This is called networkbyte order. ~ I a c h i n e s such as Pentiums, which uses Little endian byte ordering formatmust convert header values to network byte order before transmitting the data.

    The version field indicates the version of the IP protocol that the data belongs.This field is usually use for b a c k w ~ r d compatibility.

    The [HL field is the length of the header in 32-bits words. The minimum value is5 words (20 bytes) whicb is the case when no options are present: and the ma."

  • 7/28/2019 vpn ipsec research report

    19/118

    32-bits -----------.....4-bits li 4-bits IS-bits type of service 16-bits total lengthversion IHL

    16-bit identification 3-bits 1 13-bits fragments offsettlagsS-bit time to live l S-bit protocol 16-bit checksum

    32-bit source address32-bit destination address

    , option (0 or more words length)

  • 7/28/2019 vpn ipsec research report

    20/118

    preventing datagram from looping infinitely within a network segment. The TTLfield is set ta a default value by the hast. Each router that the datagram passesthrough, decrements the TTL value byone. If a router receives a datagram with aTIL value of 1, it discards the datagram and sends an ICMP message to the sourceindicating that the TTL value of the datagram has expired.

    The protocol field tells which transport protocol is used for the data encapsulatedwithin the IP datagrarn. It allows destination hosts to demultiplex IP datagramsamong the different transport protocols.

    The header checksum is computed on the IP header and is used ta determine theintegrity of the IP header. It should he ootoo that the checksum is not encryptedand it can easily he forged.

    The source and destination address fields indicate the 4 bytes IP address of thehast that generated the datagram, and the destination hast respectively.

    The variable length options field carries optional information about a datagramsuch as the security and handling restriction. This field is rarely used and is usuallyignored by most routers.

    The data portion of the IP datagram is of variable length and it contains the IPpayload. For fur ther detail regarding the format of the data or header portion ofan IPv4 datagram refer to [PosSI] which contains the official specification of IPv4protocol.IPv6 Datagram FormatIPv4 suffers from a major l imitation: i t l imits IP address to 32 bits . \Vith the currentrate of growth of the Internet. there is a real possibility that if the size of IP addressesdoes not i n c r e a s e ~ then there IDight not be enough IP addresses to rneet the demand.The designated successor of IPv4: I P v 6 ~ overcomes this limitation as weIl as simplifiesthe IP header and adds more flexibility to the IP datagram. Sorne of the changesfrom IPv4 to IPv6 are outl ined helow.

    IPv6 increases the IP address size from 32 bits to 128 bits . thus increasing theaddressahle nodes by many foids.

    14

  • 7/28/2019 vpn ipsec research report

    21/118

    Th e number of header fields is reduced from 13 in IPv4 to 7 in IPv6. Th esmaller number of headers allows r ou te rs t o process packets faster an d therefore,increases throughput.

    IPv6 provides better support for options. Th e options a re t re at ed as separateheaders instead of being a part to the IP header. This change allows routersto skip over headers that ar e not intended for them. This feature sp eeds uppacket processing time; it also allows for less stringent limits on th e length ofoptions an d provides greater ftexibility for th e introduction of new options inth e future.

    IPv6 provides new capability ta label paekets belonging ta particular traffiestream for which th e sender requests special handling, such as non-default quaIity of service.

    IPv6 does not support any fragmentation for packets in transit. Th e host thatgenerates th e paeket must perform path ~ [ T U to ascertain th e ma."

  • 7/28/2019 vpn ipsec research report

    22/118

    ..

    4-bits II 4-bits 1 24-bits tlow labelversion priority16-bits payload length 1 8-bits next header 1 8bits hop limit

    - -~ 128-bits source address -r- -

    - -

    -- 128bits destination addrcss -! - - -Figure 2.4: IPv6 Header Format.

    header compared to that of IPv4. It tells which extension h e a d e r ~ if any, follows thisone; if this header is the last IP h e a d e r ~ it tells which transport protocol the packetshould he passed to. For information on the number assigned to each protocol see[RP94].

    The hop limit field is the same as the TTL field in IPv4; see Setion 2.2.2.The source and destination address fields represent the 128-bits IPv6 addresses of

    the source and intended recipient of the packet, respectively.

    Extension Headers

    IPv6 introduced the concept of optional extension headers. These headers can besupplied to provide additional information. There are currently 6 extension headersdefined by I P v 6 ~ and each has a unique identification number (described in [RP94]).The extension headers, if p r e s e n t ~ are inserted between the IPv6 header and the

    16

  • 7/28/2019 vpn ipsec research report

    23/118

    transport header. I f more than one extension header is present, the order of theheaders is important and should be as detailed in [DH95] (the original specificationof IPv6).

    2.2.3 Transport LayerThe layer above the network layer in the Tep /IP protocol stack is the transport layer.This layer provides a 80w of data between two hasts, for the application layer above.Two protocols are implemented at the transport layer: Tep (Transmission ControlProtocol) and UDP (User Datagram Protocol).

    Tep is a reliable connection-oriented 2 protocol that allows bytes streams from ahost to be delivered without error to any other hosts on networks that are reachable.Tep protocol also breaks up packets it received from the application layer into apprpriate fragment sizes, acknowledges received packets, re-assembles packet fragmentsit received from the network layer, and perform ftow control ta ensure that a fasthosts does oot ~ w a m p a slower host with more packets that it cao handle. See RFC793 [Pos8Ie] (the original specification document for TCP) for further detail on thisprotocol.

    UDP, unlike TCP, offers an unreliable connectionless J service. It does not perforrnany error checking or flow control; It just sends datagram from one host to anotherand does not provide any guarantee that the datagram will get ta its destination.There is mueh less overhead involves in processing UDP d a t a g r a m ~ compared to Teppackets. Consequently, the throughput for COP datagrams is usually greater thanthat of TCP. UOP protocol is usually use by applications for which prompt deliveryis more important than accurate delivery; such as in the transmission of speech orvideo. RFC 768 [PasSn] outlined the original specification of CDP.

    2Section 2.2.2 on page 123Seetion 2.2.2 on page 11

    l i

  • 7/28/2019 vpn ipsec research report

    24/118

    2.2.4 Application LayerThe top of the Tep /IP protocol stack is the application layer. This layer includesail processes that use the transport layer protocols to deliver data. Application layerprotocols usually provide services to the users of the system. There are many ap-plication protocols. The ones that just about ail Tep /IP implementation providesinclude:

    Teinet: The Network Terminal Protocol, which provides remote login. FTP: File Transfer Protocol, which is used for file transfer ta or from remote

    hosts. SMTP: Simple ~ I a i l Transfer Protocol, which delivers electronic mail. SNMP: Simple N"etwork ~ I a n a g e m e n t Protocol, which is used for monitoring

    network segments. DNS: Domain N"ame Service! which is used for mapping host names ooto their

    IP addresses. HTTP: Hypertext Transfer Protocol! which is used for fetching web pages on

    the \Vorld \\de \Veb.

    18

  • 7/28/2019 vpn ipsec research report

    25/118

    Chapter 3Cryptographie Techniques

    3.1 The Data Encryption StandardIn 1973 th e USA :"Iational Bureau of Standards ( ~ B S ) , currently known as NationalInstitute of Standards and Technology ( N I S T ) ~ issued a request for proposai for anational cryptosystem standard. A number of cipher systems \Vas proposed. ACtera review of the proposals NBS adopted the cryptosystem developed at IB)W[ as theData Encryption Standard (DES) on July 1977. This cipher system is based ona cryptographie algorithm caUed LUCIFER [Fie73] that a research team at I B ~ I -headed by Horst Feistel-deveJoped in 1971.

    DES became th e most widely used cipher system in the world. It was reaffirmedas national standard in 1983, 1988, 1993 and on October 25, 1999 NIST adoptedtriple D E S - a more secure variant of D E S - a s th e national standard.

    .-\ complete description of DES is given in Federal Information Processing Standards Publication 46-3 (FIPS P L a 46-3) [:'IIST99]. DES takes a 64-bit black ofplaintext x and a 56-bit key K an d output 64-bit ciphertext c. Th e DES algorithmproceeds in three stages:

    1. Th e 64-bit black plainte.xt x is first ran through to an initial permutation functian IP which gives a 64-bit output IO ' \Ve can represent this as xo = 1P(x) =

    L o R o ~ where Lo represents the th e first 32 bits of xo, and Ro represents th e last

    19

  • 7/28/2019 vpn ipsec research report

    26/118

    32 bits. The permutation function IP is shawn in Table 3.I(a). It is interpretedas follows: the first three bits of the output from this function are the 58th,50th and 42nd bits of the input to the thi s function; s i m i l a r l y ~ the 62nd, 63rdand 64 th bits of the output are the 23rd, 15th and 7th bits respectively of theinput bit string.

    2. Xo is then subjected ta 16 iterations of key-dependent computations involvinga cipher function f and a key scheduling function K S. I f we represents theoutput from each iteration as Xi = LiRt, where 1 ~ i ~ 16, thenLi = ll-lRt = Li E9 f(ll-l' Ki)where denotes the exclusive-or of two bi t strings. The Ki's are 48-bi t blackswhich are derived from the original 56-bit key using the key scheduling functionK S. The key scheduling function. the derivation of th e KI s. and the cipherfunction f will be discussed later.

    3. The inverse permutation function 1p -L is then applied to R 16 L 16 to give a 64bi t block ciphertext c. that is, c = 1p- L(R L6L 16 ) . ~ o t e the change in arderof R L6 and L16 The inverse permutation function is shown in Table 3.I(h).It is the inverse of IP: if it is applied ta the output of (P, the result would beidentical ta the bi t string inputted ta IP; that is, IP-l(IP(x)) = 1. Figure 3.1illustrates the DES algorithm.

    The cipher function f involves the following steps: The Rt!s is subjected ta an expansion permutation E which takes as its inputthe 32-bit black Rt and yields a 48-bit black output. The expansion pennutationis shawn in Table 3.2(a). l t is interpreted as follows: The first three bit s of the48-bit output E(R,,) are the bits in positions 32, 1 and 2 of ~ ; whereas. thelast 3 bits of the output are the bits in pos it ions 31. 32 and 1 of ~ .

    20

  • 7/28/2019 vpn ipsec research report

    27/118

    64-bit input---+Lo

    c, IP )t~ -

    ---

    _----t------ K 1

    --- ---- - - - - - - - ~ : _ - ---1 ,, ,______5_=_R_1_-'__ ---i1 1R15 = L 14 e f ( R 1 4 ~ K 1s) 1

    ~ - c b ~ -11 R16 = L 15 f(R 1S , K 16 ) 1 L 16 = R1s

    L-I ....,..-- 1+C 1_P- _1- - )t64-bit output

    Figure 3.1: Illustration of DES encryption algorithm.

    21

  • 7/28/2019 vpn ipsec research report

    28/118

    Table 3.1: Initial permutation (IP) and inverse permutation 1p-l functions.(a) IP

    58 50 42 34 26 18 10 260 52 44 36 28 20 12 462 54 46 38 30 22 14 664 56 48 40 32 24 16 857 49 41 33 25 17 9 159 51 43 35 27 19 Il 361 53 45 37 29 21 13 563 55 47 39 31 23 15 7

    (h) IP- l-l0 8 18 16 56 24 64 3239 7 47 15 55 23 63 3138 6 46 14 54 22 62 3037 15 45 13 53 21 61 2936 4 44 12 52 20 60 2835 3 43 Il 51 19 59 ? --,34 2 42 10 50 18 58 2633 1 41 9 49 17 57 25

    The 48-bit output E(Rd of the expansion permutation is exclusive-or with the48-bit Kt>

    The -l8-bit output tbat resulted from the E(R;) a Kt operation is broken upinta eight 6-bit blacks and each block is passed through aS-box which givesan output of length 4 bits. The eight S-boxes are shown in Table 3.4. Thepermutation of the S-boxes can be described as fallows: The first and tbe lastbits of a 6-bit input of a given S-box Si forms a 2-bit binary number to select

    22

  • 7/28/2019 vpn ipsec research report

    29/118

    Table 3.2: Expansion function and permutation function P.1 (a) E bit-selection table32 1 2 3 4 54 5 6 7 8 9

    18 9 10 Il 12 1312 13 14 15 16 1716 17 18 19 20 2120 21 22 23 24 2524 25 26 27 28 2928 29 30 31 32 1

    (d) P16 720 2129 12 28 17

    115 23 26 11

    ;) 18 31 10 ;1

    2 8 24 14 1

    1

    32 27 3 913 30 6191 1122 I l -1 ? - i-v ,1 !

    one of the four rows in Si; whereas! the inner four bits form a binary numberin the range 0 to 15 to select one of the 16 columns in Si ' For example. if aninput to St is 101011. The 2-bit binary number obtained from the first and thelast bits is Il the decimal equivalent is 3; therefore! the row 3 is selected. Theinner four bits are 0101. the decimal equivalent is 10; hence! column 10. Thenumber in the 3rd row and 10th column of St is 9; therefore! the output fromSt for this example is IOOI! which is the -l-bit binary representation of 9.

    23

  • 7/28/2019 vpn ipsec research report

    30/118

    32-bit R++

    Figure 3.2: Illustration of f( R. K) calculation.

    The 4-hit output of each the eight S-boxes is concatenated as shown in Figure3.2 ta yield a 32-bit output which is then fed into a permutation function P.Finally! P yields an output of 32 bits which is the result of f ( ~ , Kt). Thepermutation function P is shown in Table 3.2(b) and Figure 3.2 illustrates thecomputation of feR, K).

    The key scheduling function K S is used to generate the 48-bit Ki!s from the 56-bitoriginal key. :\ctuaIly! DES keys are 64 bits in length. However. 8 of the bits are usedfor error detection: the bits in positions 8, 16! 24,. ..! 64 are used for assuring thateach byte has an odd parity! that is! each byte has an odd number of 1!s. KS invalvestwo permutation functions: permutation choice one (PC-l) and permutation chaicetwo (PC-2). The functions are shawn in Table 3.-1. The algorithm far determing theKi's where. 1 ~ i ~ 16. cao be described as follows:

    24

  • 7/28/2019 vpn ipsec research report

    31/118

    Table 3.3: Tables used for DES key schedule calculation.(a) PC-l

    57 49 41 33 25 17 91 58 50 42 34 26 1810 2 59 51 43 35 2719 Il 3 60 52 44 3663 55 47 39 31 23 157 63 54 46 38 30 2214 6 61 53 45 37 29

    r 21 13 5 28 20 12 4

    (b) Schedule of left shiftsIteration number 1 2 3 .. 5 6 7 8 9 10 Il 12 13 14 15 16

    left shifts 1 1 2 2 2 2 2 2 1 2 2 2 2 2 2 1 j1

    (c) PC-214 17 11 24 1 ,)3 28 15 6 21 1023 19 12 -l 26 816 7 27 20 13 24 - ? 31 37 47 55J_30 40 51 45 33 48

    i 44 49 39 56 34 53i 46 42 50 36 29 32

    25

  • 7/28/2019 vpn ipsec research report

    32/118

    56-bit key+( PC-I)

    io Do~ +@J+ +

    C l Do 1---... (PC-2)-1 KI, ,@ @1 11 1, ,Ci. Di 1---... (PC-2)-----1 KI1

    1, ,(LS I6) ( LS I6)1 +C l6 D I6 1---'" (PC-2)--1 K 16Figure 3.3: Illustration of DES key schedule calculation.

    1. Given a 64-bit key discards the 8 parity bits and apply the the fixed permutation PC-l to the remaining 56 bits of K. \Ve can represents this asPC-l(K) = CoDa, where Co and Do represent the tirst and last 28 bits of K.respectively. [n Table 3.4(aL PC-l is divided into two halves. The tirst halfdetermines the bits in Co and the second half determines the bits in Do.

    2. Compute Ci. and Di! such thatCi = LSi(Ci.-dDi = LSt(Di-d!where LSi is either 1 or 2 and it represents the number of cyclic left shifts thatthe bit s in Ci or Di. are to be shi fted bYe Table 3.4(c) shows the LSi 's for the16 iterations.

    26

  • 7/28/2019 vpn ipsec research report

    33/118

    3. Concatenate the bits of Ci and Di and apply the fixed permutation PC-2 tothe result. The output from PC-2 is the key Ki, ie Ki =PC-2(Ci Di ) . The keyschedule computations are illustrated in Figure 3.3.

    Table 3.4: DES eight S-boxers.

    14 4o 154 115 12

    13 17 414 88 2

    214134

    15 Il2 136 29 1

    8 3 101 10 6Il 15 127 .:> Il

    6 12 512 I l 99 733 14 10

    9 05 310 5o 6

    15 13 13o 1413 8

    8 14 64 7 15 I l 1010 1 3

    I l 3 4 9 72 8 14 12 04 13 5 815 4 2 I l 6

    2 13 12 01 10 6 912 6 9 37 12 0 5

    5Il214

    10 !5159

    1013131

    o 97 06 410 13

    14 69 39 8o 6

    34159

    15638

    510o7

    12Il4

    13 128 51 215 14

    7 I l 4 214 12 I l 1512 5 10 143 Il 5 2

    81712

    7 13 14 313 8 Il 510 6 9 03 15 0 6

    o 66 1512 Il10 1

    9 10 1 2o 3 4 77 13 15 113 8 9 4

    27

    8235

    5 I l 12 14 1512 1 10 14 914 5 2 8 -1Il 12 7 2 14

  • 7/28/2019 vpn ipsec research report

    34/118

    2 121 14 I l4 2I l 8

    4 12 121 I l12 7

    557 10 I l 6 84 7 13 1 510 13 7 8 151 14 2 13 6

    5 3 15 13 0o 15 10 3 99 12 5 6 315 0 9 10 -1

    148o5

    96143

    12 1 10 15 910 15 -1 2 79 14 15 5 24 3 2 12 9

    21285

    6 8 0 13956 112 3 7 015 10 Il 14

    3 413 144 101 7

    14o16

    7 5Il 313 I lo 8

    I l8613

    41316

    I l 2 14 15 0o Il 7 -1 94 I l 13 12 3I l 13 8 1 4

    8 13 31 10 147 14 1010 7 9

    12 93 515 65 0

    7 512 28 015 14

    10 615 85 92 3

    16212

    15 Il 1 10 93 ( -1 12 5

    13172

    2 8 -115 13 8Il -1 11 14 7

    6109-1

    12 1410 8

    20613 15 12

    3 14 56 I l 010 13 1590 3

    o143

    12956

    728Il

    The deciphering of DES utilizes the same key and algorithm as that which isused for enciphering, except that the algorithm is applied in th e reverse arder.

    3.1.1 DES Mode of Opera tionThe specification of DES specified four possible modes of operation. :\ brief descrip-tion of each of the four modes is given below.

    28

  • 7/28/2019 vpn ipsec research report

    35/118

    Electronic Godebook (EGS) mode: This is the direct application of the DESa1gorithm as described in the pervious section: given a bitstring of plaintextx = XIX2 . , break up the bitstring in blocks of 64 bits X i and apply the DESalgorithm to each X i to produce a block of ciphertext, Ci. \Ve write Ci = Ek(X 1 ),where eft: is the DES encipering algorithme The complete ciphertext C is theconcatenation of the c;'s in numerical order. That is, C = CIC2

    Gipher Bl ac k Ghaining ( GBG ) mode: Given a bitstring of plaintext x = X1X2 where the Xi 's are 64-bi t blocks; the first black Xl is first exclusive-ored witha 64-bit ini tial vector then the DES encryption algorithm is applied to theresult to give the first block of 64-bit ciphertext Ct. The consequent blocks ofplaintext Xi'S are then exclusive-ored with the previous block of ciphertext C1-land the encryption algorithm applied. This can be represented as:Cl = eft:(xl e I V ) ~ C2 = eft:(x2 e cd and Ci = ek(xi a Ci-d

    Cipher Feedback (CFS) mode: This mode uses previosly generated ciphertextas input to the DES algorithm to generate pseudo-random outputs which areexclusive-ored with the plaintext ta produce the ciphertext. The steps can bedescribed as follows: apply DES algor ithm to an in it ia l vector IV' to producea cipher output Zh then e.xclusive-or X l with Zl ta produce the first block ofciphertext Cl. The subsequent blocks of ciphertext c; 's are produced by applyingthe DES algorithm ta the previous block of ciphertext, then exclusive-or theoutput with the corresponding block of plaintext Xi, ieZl = e k ( I ~ r ) , Cl = Xt f f i z t , Z2 = ek(cd, C2 = X2e Z2, Zi = ek(c,-d and Ci = X i e Z i

    O utput Feedback (OFB) mode: This mode is similar to the CFB mode, exceptthat OFB does not chain the ciphertext; instead, the ini tial vector IV is encrypted in turn ta produce the =1 's. Sa,Zl = e k ( I l r ~ ) , Cl = X l a oZ, = ek(zi-d and Ci = Xl e Zt

    29

  • 7/28/2019 vpn ipsec research report

    36/118

    3.1.2 DES implementationThe popularity of DES can be attributed to the fact that the algorithm can be implemented very efficently in either software and hardware. The only computationsthat are involved in the DES encipher or deciphering are exclusive-or operations.The permutation and expansion functions can be implemented using lookup tables;therefore, these operations cao ail he performed in constant time. This cont ras tswith puhlic-key cryptographie aJgorithms which usually involve computationly intensive operation such as the exponentation of large numhers. DES enciphering anddeciphering can therefore be performed much more quickly than all of the currentpublic-keyencryption algorithm. As a result! DES or variants of the DES algorithmhave enjoyed widespread use, particularly in applications where the speed of encrypting and decrypting the data is of much importance.

    3.1.3 Thiple DESGiven a 64-bit plaintext x and the corresponding 64-bit ciphertext c that resulted fromenciphering x with DES, the 56-bit DES key K can he found within 256 operations.As the speed ofcomputing systems increases it becomes more feasihle to perform largenumber of operations within limited time periods. In 1997, RSA laboratories issued achallenge which involved a reward of$lO!OOO ta find the DES key of a ciphertext whichwas perceded by a known block of text which contained the the phrase 'the unknownmessage is: l ' . A project! headed by Roche Verse-an independent consultant-whichinvolved over 70,000 computer systems linked over the Internet used a brute-force Lprogram to find the correct DES key in approximatly 96 days [RSA97J. This successfulattack on DES accelerated the search for a more secure replacement of DES. InOctober 25, 1 9 9 9 ~ ~ I S T affirmed triple DES as the new data encryption standard forthe Federal Bureau.

    The triple DES algorithm can be described as follows: Let ek(x) and dk(x) represents the encryption and decryption of the 64-bit bitstring x using the DES algorithmla brute-force attack involves tr)'ing all possible keys untiI the correct one is round.

    30

  • 7/28/2019 vpn ipsec research report

    37/118

    with key K, then the 54-bit ciphertext x is obtained by performing the following operation:

    c = eK3(dK'l(eKl (x)))Where Kil K 2 and K 3 are 56-bit DES keys.

    The deciphering of triple DES to derive the plaintext x from the ciphertext c isthe reverse of the enciphering process and it can be described as:

    For greater s e c u r i t y ~ the three keys should all be different; this in essence corresponds to enciphering with a key of length 168 bits-which should be relativelysecure against brute-force attack for many years. For data requiring a lesser degreeof security, KI can be equal to K 3 In this case, the key is effectively of length 112bits.

    3.1.4 Other Private Key CryptosystemsOver the years, a number of private key cryptosystems have been proposed as possiblereplacement for DES. Sorne of these cryptosysems will be introduced below.

    Blowfisb: Blowfish was developed by Bruce Schneier [Sch93]. It uses a keyof variable length: from 32 to -.148 bits to encrypt blocks of 64-bit plaintextinto blocks of 64-bit ciphertext. Blowfish has a simple structure which makes iteasy to implement. Currently, Blowfish is one of the fastest encryption system.The variable length key allows for varied degree of security. It is believed thatblowfish is very s e c u r e ~ particularly when longer keys are used.

    CAST-128 CAST was developed by Carlisle Adams and Stafford Tavares[Ada97]. It uses a key that varies for 40 to 128 bits in l e n g t h ~ in 8-bits increments; and produce 64-bit blocks cipherte.xt from blocks of 64-bit plaintext.The CAST algorithm involves 16 rounds of computations which are quite complex. This algorithm has received widespread re"iew and it is believed to bequite sare.

    31

  • 7/28/2019 vpn ipsec research report

    38/118

    International Data EncryptioD Algorithm (IDEA): IDEA was developedby Xuejia Lai and James ~ l a s s e y at the Swiss Insti tute of Technology. Theoriginal specifications and later modifications are outlined in [ L ~ 1 9 0 } and (LM91]respeetively. IDEA uses a 128-bit key and and encrypts plaintext in bloeks of64 bits and output 64-bits block ciphertext. IDEA enciphering algorithm hasreceived a fair bit of attention and it is believed that i t should ta he quite securefor a number of years.

    RC2 RC2 was developed by Ronald Rivest (Riv98]. ft is was designed to beeasily implement on 16-bit mieroprocessors. The algorithm uses a key ofvariablelength: from 8 bytes ta 128 bytes and enciphers blacks of 64-bit plaintext andoutputs blacks of ciphertext of length 64 bits.

    RC5 RC5 was developed by Ronald Rivest (Riv94}; a later description is givenin [BR96]. RC5, like DES is suitable for both hardware and software implementation. It is adaptable ta processor of different word length: the number of bitsin the processor 7s word is one of the input to the RC5 algor ithm. RC5 algor ithmaIso has variable number of rounds, which allows tradeoff between higher speedand higher security. The algorithm uses a variable length key to encrypt blacksof 32, 64 or 128 bits plaintext and output blacks of ciphertext of correspondinglength. RC5 has a low memory requirement; which therefore makes it sui tableta be used in applicat ions sueh as smart cards which have limited memory.

    3.2 Public Key CryptosystemsPrivate-key cryptosystems suffer from a major drawback. These cryptosystems aresymmetric, that is, the same key is use for encrypting and deerypt ing the data:therefore, the sender and receipent of the message need to exchange the "secref 'cryptographie key \-;a a relatively secure c h a n n e l ~ which may not be available. Publickey cryptosystems address t his issue. These systems are asymmetric systems: thekey that is used to decipher the data is different from that which is used to encipher

    32

  • 7/28/2019 vpn ipsec research report

    39/118

    it . The encrypting keys-commonly refered to as the public keys-do no t need to bekept secret. This therefore eliminates the need for a secure channel to exchange keys.

    The ideas on which public-key cryptosystems are based was first published in1976 by Whitfield Dime and ~ [ a r t i n Hellman [DH76). These systems are based onthe concept of trapdoor one-way functions. One-way functions are functions thatare easy to compute bu t hard to invert. Whereas, trapdoor one-way functions areone-way functions which cao he inverted eMily with the knowledge of sorne additionalinformation; this additional information is refered to as the trapdoor.

    Over the years a numher of public-key cryptosystems have heen proposed; threeof the more commonly used ones will be presented in this section.

    3.2.1 RSA CryptosystemThe RSA cryptosystem was developed in 1977 by Ronald Rivest, '-\'rii Shamir and LenAdlemar at ~ n T [RSA781. This system is based on the difficulty of factoring largeintegers. The RSA system can he described as follows:

    1. Generate two large primes p and q.2. Compute the product of the primes n = pq.

    3. Compute the numher of integers that are less than n and relatively prime 2 ton. This is equal to the Euler phi function cP(n) = (p - 1) (q - 1).

    4. Select a random number b such that 1 < b < tj)(n) and b is relatively prime tan, ie gcd(b.dJ(n)) = 1.

    5. Compute a = b- l morl cP(n).6. Keep a, p and q secret and make n and b available to any one who wishes to

    send you encrypted messages.The primes p and q should he large enough such that, given their product n, it

    should be computationally infeasihle ta factor n without prior knowledge of either pZTwo numbers a and b are relatively prime if gcd(a, b) = 1.

    33

  • 7/28/2019 vpn ipsec research report

    40/118

    or q. For secure systems it is recommended that n be at least 200 digits which isequivalent ta 200 x [092 10 ~ 664 bits in length. We will now turn to to question ofhow are these primes of suitable Bize generated. Currently, th e MOst practical wayof doing this is use a pseudo-random number generator to generate sufficiently largead d numbers, then use a probabilistic primality testing algorithm ta determine if th enumber is a prime. A commonly used algorithm that tests for prime is the i\lillerRabin primal ity tes ting algorithm. This algorithm along with other probabilisticprimality testing algorithms ar e outlined in [Sti95}.

    T h e Encryption Decryption ProcessesPlaintext ar e encrypted in blacks. Each block should be less than th e binary representation of n in bits, that is, each block should be less than {092 n bits in length. Fora block of plaintext x, th e public keys (b, n) are used to generate th e correspondingblock of ciphertext c by computing: c = x b mod n. Th e black of plaintext x can thenbe generated from the block of ciphertext c by calculating: x = c! mod n.

    3.2.2 EIGamal CryptosystemTh e EIGamal cryptosystem was developed by EIGamal an d published in 1985 in[EIG85]. This system is based on the Discrete Logarithm problem. Th e DiscreteLogarithm problem can he described as follows: Consider th e equation /3 = fT mod p,if p is carefully chosen it is considered to be very difficult to compute the values ofx given ;3, 9 an d p. However, ,3 can he computed quite efficiently if g, x an d p a r egiven. In other words, exponentiation modulo p is a one-way function for suitahle p.

    \Ve will no\,.. describe th e EIGamal system. First, a suitable prime p is choosesuch that th e Discrete Logarithm prohlem is difficult for integers less that p. Thensuitahle 3, 9 an d a are chosen such that 3 == gQ mod p. 3 9 an d p are then madepublic an d a kept private.

    34

  • 7/28/2019 vpn ipsec research report

    41/118

    Encryption and Decryption ProcessesTo encipher a plaintext x, Alice chooses a secret random integer k such that k

    Responder

    HDa-, HA8H(2). SA, Nr[KE], [IDi, IDr]

    In the first message, the initiator sends a Hash, a SA-which encapsulatesone or more Proposai Payload(s), which encapsulated one or more TransformPayload(s)-and a Nonce Payload, and optional key exchange material andidentification information ta the responder. If Perleet Forwarded Secrecy 2 isrequired then key exchange material must be included in the this message. TheHash Payload contains the message digest-using the negotiated prf- of the

    ~ f e s s a g e ID ( ~ f s g I D ) from the I S A K ~ [ P header concatenated with the entiremessage that follows the the Hash Payload, including aIl payload headers. Thatis,HASH(l) = prf(SKEYSTR_a, ~ [ s g I D SA 1 Ni [ 1 KE ] [ IDi IDr)The generation of the keying materiaIs (SKEYSTR or SKEYSTR_*) will beaddress momentarily.

    The payloads in the second message are similar ta those in the first message.The finger print contained in Hash(2) is generated similarly as that for Hash(l),except that the initiator's nonce Ni minus the payload header is added after

    ~ 1 [ s g I D but before the complete message.HASH(2) = prf(SKEYSTR_a, ~ [ s g I D NLb: SA ' :.'ir [ KE] [ i IDi IDr)

    The third message is used ta authenticate the previous exchanges and it consistsof only the I S A K ~ [ P header and a Hash Payload. The message digest in theHash Payload is generated using as input: a byte of 0 concatenated with ~ [ s g I D ,

    2The term Perfeet Forwarded Secrecy is used to describe the phenomenon where th e derivationof the keying material is of sucb that if a single key is comprised, this will not affect the security ofthe data protected by other keys.

    93

  • 7/28/2019 vpn ipsec research report

    100/118

  • 7/28/2019 vpn ipsec research report

    101/118

    Generation of Keying MaterialWe have discussed the generation of keying material for Quick ~ I o d e exchanges; however, we have Dot yet discussed how keying material are generated for :\'[ain andAggressive ~ [ o d e exchanges. We will present this information now. C u r r e n t l y ~ threemethods of authentication are allowed for both Main ~ l o d e and Aggressive l'vIode exchanges: digital s i g n a t u r e ~ authentication with public-key encryption and pre-sharedkey. The value of SKEYSTR depends on the method of authentication.1. For digital signature

    SKEYSTR = pr f(1VLb Il.Vr_b, g%Y)2. For public-key encryption

    SKEYSTR = pr f(Hash(iVi_b 1 lV r _b, CK-I Ck-R)3. For pre-shared keys

    SKEYSTR = prf(pre-shared-key, ~ L b 1 ~ r_b)Both ~ I a i n ~ I o d e and Aggressive ~ I o d e exchanges generate three groups of au

    thenticated keying material. These keying material are derived similarly for bothexchange modes and they are t ransported in the "Key Exchange Data" field of theKE Payload. The derivations are as follows:SKEYSTR-2 = prf(SKEYSTR, fTY 1 Ck-I 1 Ck-R 1 0)SKEYSTR.-a = prf(SKE)rSTR, SKEYSTR_d 1 g.rt} ' Ck-I Ck-R i l )SKEYSTR..e = prf(SKEYSTR, SKEYSTR..a 1 g.rtJ 1 Ck-I 1 Ck-R : 2)The values D,land 2 in the above expressions are the I-hyte representations of thesevalues. The exchanges are authenticated by the generation of HASH-i and HASH-rby the ini tiator and the responder respectively, of the exehanges. \VhereHASH..i = prf(SKEYSTR, gr i ! g.l:r: Ck-I 1 Ck-R SALbHASH..!" = prf(SKEYSTR, gr r g.l: i j Ck-R Ck-I 1 SALb

    IDiLb)IDir_b)

    The necessary keys for e n c r y p t i o n ~ digital signature and ~ I e s s a g e AuthenticationCode algorithms are derived from the keying materials in algorithmic specifie man-

    95

  • 7/28/2019 vpn ipsec research report

    102/118

    ners.

    7.3 Oakley GroupsThe IKE protocol allows negotiation of the group for Diflie-Hellman exchange. Theoriginal specification of IKE [HC98) defined four groups that originated from theGakley Protocol. These groups are presented below.

    First Oakley GroupThis group is a modular exponentation group ( ~ ! E G ) and it is the default group forboth the Oakley and IKE protocols. The assigned group ID is l .The prime is: 2

    768 - 270 -1 - 1 + 264 * {[2638 1r] + 149686}The generator is : 2

    Second OaldeyGroupThe second group group is also a ~ [ E G and it is assigned a group ID of 2.The prime is: 21024 - 2960 - 1 + 264 * {[2894 rr] + 129093}The generator is : 2

    Third Oaldey GroupThis is an elliptie curve group defined over the Galois Field GF[2 155 ]. This group hasgroup ID 3. The field size is 155 and the irreducible polYnomial for the field is:u155 + U62 + 1.The equation for the elliptic curve is:y 2 + xy =x3 +ax2 +bGroup Prime/lr reducible Polynomial: OxOS00000000000000000000004000000000000001Group Generator 1: Ox7bGroup Curve A: OxOGroup Curve B: Ox07338fGroup Order: OX0800000000000000000057db5698537193aef944

    96

  • 7/28/2019 vpn ipsec research report

    103/118

    When this group is used the! the data in the "Key Exchange Data" field of the KEPayload is the value of x from the solution (x,y), the point on the curve chosen bytaking the randomly secret Ka *P, where "*,, is the repetition of the group additionand double operations, and P is the point on the curve with x coordinate equals toGenerator 1 and the y coordinate determined from the equation of the elliptic curve.

    Fourth Oakley GroupThis is an elliptic curve group defined over the Galois Field GF[2 185Land has groupID 4. The field size is 185. The irreducible polYnomial for the field is:U L85 + U69 + 1The equation for the elliptic curve is:y2 + xy = x3 + ax2 + bGroup Prime/lrreducible Polynomial:

    Ox020000000000000000000000000000200000000000000001Group Generator 1: Ox18Group Curve A: OxOGroup Curve B: Oxlee9Group Order: OXOlf1Jfffffffffffffffffffdbf2f889b73e484175f94ebc\Vhen this group is used, the data in the ' ~ K e y Exchange Data" field of the KEPayload is generated similarly as indicated for the Third Oakley group.

    This concludes our discussion of the IKE protocol. For addit ion information onthis protocol. please refer to [Reg8] which contains the original specification.

    97

  • 7/28/2019 vpn ipsec research report

    104/118

    Chapter 8VPN SolutionsIn the previous chapters, we examined the security protocols that comprise the IPSecProtocol suite. [n this chapter, we are going to illustrate how these security servicescan be used to provide different VPN solutions. H o w e v e r ~ before we proceed. it isnecessary to define sorne terms that we will he using throughout this chapter .

    Notations VPN: For the purpose of our discussion, Virtual Private Networks (VPl' i) are

    secure communication channels which offer data protection via the use of strongcryptographie authentication and/or encryption algorithms. VPN consists ofcomputers (IPSec enabled servers or workstations) and communication links;optionally VPN can also involve routers, m;tches and security gateways.

    Security Gateway: A secur ity gateway is an access point ta a network. A se-curity gateway often includes a firewal1 (see next entry), and it provides accesscontrol; thus only allowing authorized traffic to transverse the network i t pro-tects.

    Firewall: A firewall is a packet filtering entity that examines the protocol head-ers of packets and either accepts the packets and forward them ta the destinationhosts. or reject them. depending on how the selectors in the packets headers-

    98

  • 7/28/2019 vpn ipsec research report

    105/118

    source and destination IP address, Transport or Application Layer protocols!source and destination ports, etc.-matches the firewall access control mies.

    8.1 Interconnecting Branch OfficesLet us consider a company with has a number of branch offices that are located at different geographical areas. For example, we will assume that the company has officesin Asia, Europe and North America. Ta interconnect these offices, the company basically has two choices: utilize private network inCrastructures or V P ~ . Let us considerthe options Cor the former: the company will need ta either lease dedicated communication channels from telecommunication providers; set up satellite data feed; orinstalled Trans-Atlantic data channels. The cost of even the most cost-effective implementation of any oC these options, is mu ch more prohibitive than a VPN solution;considering that each of these options involves the purchasing or leasing of additionalequipment-network cables and supporting infrastructures-plus there are high as5ociated maintenance cost5. \Vhereas! a V P ~ solution typically involves the purchasingof the V P ~ software and the necessary licenses and perhaps a few addit ional computers; and providing the necessary training for ~ e t w o r k or Security Administratorswho will administer the VP:'1.Figure 8.1 i llustra tes an example of how the branch offices of an enterprise can

    be interconnected via VPN using the Internet as a backbone network. Each branchoffice has a secur ity gateway that provides an interface with the Internet and thecompany!s internai network. These security gateways are configured to enforce theaccess control policies of the respective branch office. There are a number of securityservice options that can be employed when a host on any of the company!s intra-netwishes to communicate with a entity on the intra-net of another branch office. Wewill examine the option that offers the greatest level of security.

    99

  • 7/28/2019 vpn ipsec research report

    106/118

    Braneh Office B

    Figure 8.1: VPN interconnecting branches using Internet as backbone network.

    End-to-end Authentication and EncryptionThis option is employed when a high degree of security for the data traffic is requiredand the internaI network cannot be fully trusted. In employing this opt ion. a hostnegotiates a Securi ty Association (SA) with a peer on the intra-net of another branchoffice. The SA will specify the securi ty services required (AH and/or E S P ) ~ themode of operation of these s e r v i c e s ~ and the required authentication and encryptionaIgorithms. Interne t Key Exchange protocol ( IKE) will then generate and put inplace on the communicating peers, the necessary cryptographie keys.

    Figure 8.2 illustrates a typical end-to-end secure tunnel connecting communicatingpeers on the internaI network of two branch offices. In this scenario. since there isa secur ity gateway on the intra-net of bath branch offices, the hasts will typicallynegotiate transport mode for the authentication and eneryption services that will be

    100

  • 7/28/2019 vpn ipsec research report

    107/118

    Hoste

    End-to-end tunnelBraneh Office B

    Figure 8.2: Secure end-to-end tunnel connecting cornmunicating peers on internainetwork of two branch offices.

    applied the trafflc that they will exchange. As explained in Chapter 5 and 6, transportmode of operation for AH or ESP protects the data that the upper layer protocolsencapsulate, but this mode of operation does not protect the IP header. However.when the packet from host A-destined to host C-is forwarded to branch office :\security gate, the security gateway will typically negotiate a SA with the destinationhoses security gateway. which will involve tunnel mode of operation for the requiredsecurity services. ESP tunnel mode confidentiali ty service will protect both the dataand the identity of sending entity (host .-\ in our example) while the packet is intransit Conn one security gateway to the next via the Internet.

    \Vhen the packet arrives at branch office C's security gateway, it will check itsSecurity Policy Database, first to determine whether or not it should accept the

    101

  • 7/28/2019 vpn ipsec research report

    108/118

    packet. If the packet should be given access, the security gateway will then consultits SA datahase to ascertain the SA for the traffic, then authenticates the packet usingthe authentication algorithm that the SA specifies. I f the authentication succeeded,it will forward the packet to the intended destination-host C.

    When host C receives the packet it will consult i ts SA database to identifies theSA that is applicable to this packet1 then authenticates the packet to ensure thatit has not been modified while it was in transit fonn the secur ity gateway. Finally.if the authentication succeeded, has t C will decrypt the packet using the algorithmspecified by the SA for the traffic.

    8.2 Interconnecting Different Company's Intra-netThere are situations where it rnight be necessary for a company ta gve restrictiveaccess ta other company, ta its intra-net. Consider for exarnple, a supplier whowishes ta gve clients access ta its database servers that contains relevant informationthe clients might wish to access. The end-to-end authentication encryption scenarioexplained in the previous section can also be adopted to this situation as weIl. Inthis case, the supplier's security gateway will he configure

    8.3 Addressing IssuesFor bath VPN solutions discussed in the previous sections. the enterprises can useeither globally unique (public) or globally ambiguous (private) IP addresses. Let usfirst consider the scenario where VPN is used ta interconnect branch offices. I f thecompany uses private IP addresses for the hosts on the intra-nets of the different

    102

  • 7/28/2019 vpn ipsec research report

    109/118

    branch offices; this will have very little bearing on the effectiveness of the VPN solution, pravided that security gateways have unambiguous IP addresses. The securitygateways with public IP addresses provide the interface for the hosts on the intra-netwith entities on extemaI networks. When a hast 00 any of the internaI networkswishes ta communicate with an entity outside the company!s domainT it forwardsthe packets it wishes to sent to the its security gateway; the security gateway thenmodifies the packetsT IP header and inserts its IP address in the 04source IP address"field, then Corward the packet ta their intended destination(s). The identities of theprivate IP addresses for the hosts on the internai network are therefore protected.If an eotity on any of the company's intra-nets needs to communicate with anotherhast on another intra-net, and the destination hosts needs to know the identity ofthe source node, the security gateway can accommodate this requirement! while protecting the identity of the source node from unauthorized entit ies, by using tunnelmode ESP confidentiality service. As explained in Chapters 6, when ESP is used intunnel mode! the entire IP datagram is encrypted and a new unencrypted IP headeris inser ted in front of the original IP header. The new IP header typicaIly containsthe security gate IP address as the source IP address.

    The same argument cao be applied ta the case where the hasts on the enterprise'sintra-net have unambiguous IP addresses. The identities of the hasts can he protectedin a s imi lar manner as outl ined above. Similarly, the same holds for the situationwhere a company needs to give enti ties on another company's intra-net access to itsinternai network, except that if either of the enterprises uses ambiguous IP addresses.then the network administrators must ensure the entities that need ta communicatedo not have the same IP address.

    8.4 Routing Issues~ I o s t medium size ta large scaIe V P ~ will need to employ an IP routing protocol.Routing protocols exchange routing information with neighbouring routers so thateach router can leam about the topology of neighbouring networks and be able ta

    103

  • 7/28/2019 vpn ipsec research report

    110/118

    ascertain the Most efficient way of reaching hosts that the entities on its network needto communicate with. Consider either of the VPN solutions outlined in this chapter;assume that a routing protocol is deployed on the security gateways. These gatewayswould need to exchange sensitive information such as the IP addresses of the haststhat are reachable from their network. This information obviously requires protec-tion from unauthorized entities. V P ~ also provides this protect ion. Each securitygateway can negotiate a SA with its security gateway neighbours and set up a securecommunicating channel with each of i ts neighbours by using ESP security services.Figure 8.3 illustrates how the security gateways can exchange routing informationusing secure communication channels.

    Brancb Office B

    Figure 8.3: Secure communication channels for the exchange of routing informationbetween security gateways.

    Since the security gateways are acting as e n d - h o s t s ~ they will typically utilize ESPin transport mode because there is no need ta conceal their IP addresses: they are

    104

  • 7/28/2019 vpn ipsec research report

    111/118

    gateways to their intra-nets, hence their identities must he public. These securitygateways can also be configured to exchange non-confidential infonnation with othernon-IPSec enabled routers. This can be done by including entries in the SecurityPoliey Database (SPD) that stipulate tbat packets originated from extemal networks,whether or not they are protected with any of the IPSec security services. if they aredestined to certain service port (such as the ports that routing protocols or SimpleTransfer ~ l a i l Protocol use), then they cao be given restrictive access. This oftenis necessary in arder ta facilitate communications such as sending and receiving ofelectronic mails to and from external hosts.

    Evidently, entities that are part of a VPN-whether they are hasts. rauters orsecurity gateways-can exchange information in a secure manner while protectingtheir identities if needs he. The security gateways for VPN can limit access ta onlytraffic that originated from entities that are apart of the VPN. However, as explainedabove, IPSec VPN are interoperable with non-IPSec enabled n e t w o r k s ~ since they donot necessarily preclude traffic fram the lat ter.

    105

  • 7/28/2019 vpn ipsec research report

    112/118

    Chapter 9ConclusionThe purpose of this research was ta present the components of IPSec and to illustratehow these components can be used to provide secure communication channels betweencommunicating e n t i t i e s ~ using the Internet as backbone network.

    First, we gave a brief history of the Internet which covers the period frorn itsinception in the form of an experimental network in 1969, to its current state. \\lethen gave a brier overview of the cornponents of the TCP /IP protocol suite. IPSec canbe considered as an extension of the IP protocol. Therefore! in arder to understandIPSec. it is necessary to have a firm grasp of the relevant cornponents of the TCP jlPprotocol suit.

    Next, we presented an overview of cryptographie techniques. The security servicesthat IPSec offer are based on strong cryptographie algorithms; consequently, for anin-depth llnderstanding of IPSec and to be cognizant with the degree of protectionthat its security service can o f f e r ~ it is necessary ta have a good understanding ofthe cryptographie techniques that this protocol ernploys. \Ve gave a detailed presentation of Data Encryption Standard (DES) and Triple-DES, then we introducedsorne other commonly used private-key cryptographie algorithms and discussed theirsecurity. Following this, we presented sorne public-key encryption algorithrns anddiscussed the performance, in generaL of public-key encryption algorithms comparedto that of private-key enciphering algorithms. \Ve also presented sorne cornmonlyused hash functions, message authentication code, and digital signature schemes. \Ve

    106

  • 7/28/2019 vpn ipsec research report

    113/118

    then examined the IP Security architecture: we explained what IPSec does, we intro-duced the datahases and protocols that IPSec uses, and gave an overview of how thedifferent IPSec entities interact to provide the required security services.

    Following this, we presented the AH and ESP protocols. We described theirheader formats, discussed the modes of operation (transport mode and tunnel mode)and their processing. We then descrihed IKE-the protocol that is used to negotiateSA for the IPSec services; and generates and put in place necessary cryptographiekeys that the services require.

    Finally, we presented different VPN solutions and illustrated how the IPSec secu-ritYservices can he utilized to provide secure communication channels for data trafficover the Internet hackbone.

    Currently IPSec hase VPN offers excellent protection for unicast hosts. that is, ifthe address of the host is a single IP address; however, there are more work ta be donein arder to extend a similar measure of security ta hasts in multicast groups. Thedifficulties lie mainly in the design and implementation of an efficient key exchangepratocol for multicast groups. Future research in the domain of IPSee base VP!'Ishould address the issue of extending security services eurrently offered ta unicastaddress to multicast address as weil. Also, the processing of IPSec traffie has arelatively high overhead cast. Another possible focus for future IPSec VP:'I relatedresearch, is to find more efficient ways of processing IPSec packets. in arder ta increasethroughput.

    107

  • 7/28/2019 vpn ipsec research report

    114/118

    Bibliography(Ada97] A d a m s ~ C., "The C:\ST-128 Encryption A l g o r i t h m ~ " Request ForComments

    (RFC 2144), ~ I a y 1997.(Ano98} A n o n y m o u s ~ "Maximum Security A Hacker's Guide to Protect Your Internet

    and Site Network," Saros Publishing, 2nd e d . ~ August 1998.(BR96} Baldwin, R., Rivest, R., .. The RC5, RC5-CBC, RC5-CSC-Pad, and RC5

    CTS Aigorithms," Request for Comments (RFC 2040), October 1996.(Bar641 Baran. Paul, "On Distributed Communications: I. Introduction ta

    Distributed Communications ~ e t w o r k , " ~ I E ~ I O R .. N D C ~ 1 RJ\.I-3420-PR.RAND Corporation, August 1964.

    [CQ93] C a r l - ~ t i t c h e l l , Smoot and Quarterman, John S., "Practical Internetworking\Vith TCP/IP and U ~ L X , " Addison-\Vesley Publishing Company, 1993.

    [CK74} Cerf, V. and Kahn R., "A Protocol for Packet l\;etwork Interconnection:'IEEE Trans. on Communication, Vol. CONI-22, pp. 637-648, ~ l a y 1974.

    [CIa88] Clark, D.D, "'The Design Philosophy of the DARPA Internet Protocols,"Proc. S I G C O ~ I ~ 1 88 Conf., A C ~ I , pp. 106-114, 1988.

    [Dee89] Deering, S.E., ;'Host Extensions for IP ~ f u l t i c a s t i n g , " Request For Comments (RFC 1112), August 1989.

    [DH95] Deering, S.E. and Hinden, R., "'Internet P r o t o c o l ~ Version 6 (IPv6) Specification ,"1 Request For Comments (RFC 1883), December 1995.

    108

  • 7/28/2019 vpn ipsec research report

    115/118

    [DH76] Diflie, W. and Hellman, ~ l . , " ~ I u l t i u s e r s Cryptographie Techniques," Pro-ceedings of the AFIPS ~ a t i o n a l Computer Conference, June 1976.

    [EIG85] EIGamal, T. , "A Public Key Cryptosystem and A Signature Scheme BasedOn Discrete Logarithms," IEE Transactions on Information Theory, Vol. 31,pp. 469-472, 1985.

    [Fie73] Feistel , Horst . "Cryptography and Computer Privacy," Scientifie America,~ I a y 1973.

    [FTMT84] Finlayson, R., Timothy, M., ~ f o g u l , J. , Theimer, "A Reverse Address Resolution Protocol," Network \Vorking Group Request For Comments(RFC 903), June 1984.

    [F\V\VD94] ischer, \V., \Vallmeier, E., \Vorster, T., Davis, S.P., Hayter, A., "DataCommunication Using A T ~ I : Architecture, Protocols and Resource ~ I a n a g e -ment." IEEE Communication ~ I a g a z i n e , Vol. 32, pp. 24-33, August 1994.

    [Gor95] Goralski, \V.J., "Introduction to AT)'I Networking," ~ e \ V York: ~ l c G r a w -Hill, 1995.

    [HC98) Harkins, D., Carrel, D.. "Internet Key Exchange (IKE);' Request for Comments (RFC 2409), November 1998.

    [Hun98] Hunt, Craig, "TCP/IP ~ e t \ V o r k Administration," 'Reilly and AssociatesInc. , 2nd ed.. 1998.

    [IAXAOO] Internet Assigned ~ u m b e r s Authority ( I A ~ A L .IProtocol ~ u m b e r s andAssigned Services", http://www.iana.org/numbers.html.

    [KA98] Kent, S., Atkinson, Il, "IP Authentication Header" Request for Comments(RFC 2402), Novernber 1998.

    ~ K B C 9 7 ] Krawczyk. H., Bellare, ),,1.. and Canetti, R.. ' I H ~ [ A C : Keyed-Hashing for~ I e s s a g e Authentication!" Request for Cornments (RFC 2104), February1997.

    109

  • 7/28/2019 vpn ipsec research report

    116/118

    [Kra96] Krawczyk, H., "SKEl\'IE: A versitile Secure Key Exchange Mechanism forInternet", IEEE Proceedings of Symposium on Network and Distr ibutedSystems Security, 1996.

    [Kya95] Kyas, O. "ATM Networks," London: International Thompson Publishing,1995.[ L ~ 1 9 0 ] Lia, X., and ~ I a s s e y , J., HA Proposai for a New Block Encryption Standard/'

    Proceedings, EUROCRYPTO '90, Published by Springer-Verlag, 1990.[ L ~ 1 9 1 ] Lia, X., and Massey, J., " ~ I a r k o v Cipher and Cryptanalysis," Proceedings,

    EUROCRYPTO '91, Published by Springer-Verlag, 1991.[LRA92] Latif, :\., Rowlance, E.J., and Adams, R.H., "IBM 8209 LAN Bridge," IEEE

    ~ e t w o r k Magazine, Vol. 6, pp. 28-37, ~ [ a y / June 1992.[ L C P ~ [ 8 5 ] Leiner, B . ~ L , Cole, R., Postel, J .. and ~ n l l s , D., '"The DARPA Internet

    Protocol Suite," IEEE Communication ~ I a g a z i n e , Vol 23, pp. 29-34, ~ v l a r c h1985.

    [ ~ I B 7 6 ] ~ I e t c a l f e , R. M., and Boggs, D.R., "Ethemet: Distributed Packet Switchingfor local Computer ~ e t w o r k s : ' Commun. of the AC!'.I, Vol. 19 pp. 395-404.July 1976.

    [ ~ I S S T 9 8 1 ~ I a u g h a n , D., Schertler, ~ I . , Schneider, ~ I . , Turner, J., ~ I n t e r n e t SecurityAssociation and Key Management Protocol." Request for comments (RFC2408), November 1998.

    [:'iIST93] ~ a t i o n a l Institute of Standard and Technology, "Secure Hash Standard,"Federal Information Processing Standards Publication 180-1 (FIPS PCB180-1), April 17, 1995.

    [ ~ I S T 9 8 ] ~ a t i o n a l Institute of Standard and Technology, "Digital Signature Stan-dard (DSS)," Federal Information Processing Standards Publication 186-1(FIPS Pl.:B 186-1), December 15, 1998.

    110

  • 7/28/2019 vpn ipsec research report

    117/118

    [NIST99] National Institute of Standard and Technology, "Data Encryption Standard(DES)," Federal Information Proeessing Standards Publication 46-3 (FIPSPUB 46-3), Oetober 25, 1999.

    [NKPC70] Newkirk, J., Kraley, ~ I . , Postel, J ., and Cracker, S.D, "Prototypical Implementation of the NCP," Network Working Group Request For Comments(RFC 55), June 1970.

    [Orm98] Orman, H., "Oaldey Key Determination Protocol," Request for comments(RFC 2412), ~ o v e m b e r 1998.

    [Plu82) Plummer, David C., ' ~ E t h e r n e t Address Resolution Protocol." NetworkWorking Group Request For Comments (RFC826), ~ o v e m b e r 1982.

    [PosSO} Postel, J .B., "User Datagram Protocol," Request for eomments (RFC 768),August 1980.

    [Pos81a) Postel, J.B., "Internet Protoeol;' Request for comments (RFC 791),September 1981.

    [Pos81b) Postel, J.S., --Internet Control ~ I e s s a g e ProtocoL" Request for comments(RFC (92), September 1981.

    [Pos8Ie] Postel, J.B., ;"Transmission Control Protocol," Request for comments (RFC(93), September 1981.

    [RP94) Reynolds, J. and Postel, J.B., "Assigned Numbers;' Request for comments(RFC 1700), October 1994.

    [Riv92a] Rivest, R., --The ~ I D 5 ~ I e s s a g e - D i g e s t Aigorithm," Request for comments(RFC 1321), April 1992.

    LRiv92b] Rivest, R.. "The ~ I D 4 ~ I e s s a g e - D i g e s t .-\.lgorithm," Request for comments(RFC 1320), April 1992.

    111

  • 7/28/2019 vpn ipsec research report

    118/118

    (Riv94] Rivest, R., "RCS Encryption Algorithm," Proceedings, Second InternationalWorkshop on Fast Software Encryption, Published by Springer-Verlag, December 1994.

    (RSA78] Rivest, R., Shamir, A., and Adleman, L., '-A ~ I e t h o d for Obtaining DigitalSignatures and Public Key Cryptosystems," Communications of the A C ~ I .February 1978.

    (Riv98] Rivest, R., "A Description of the RC2(r) Encryption Algorithm," Requestfor Comments (RFC 2268L ~ I a r c h 1998.

    (RSA97] RSA Data Security Inc., "Govemment Encryption Standard Takes a Fan:'RSA Data Press Release, June 17. 1997.

    (SA981 Kent, S., Atkinson, R., 'IP Encapsulatin Security Payload (ESPL!' Requestfor Comments (RFC 2406L September 1998.

    (Sch93) Schneier, B., "Description of a New Variable-Length Key, 64-bit Block Cipher (Blowfish)," Proceedings, Workshop on Fast Software Encryption. Pub-lished by Springer-Verlag, December 1993.

    (Sta99) Stallings, \Villiam, "Cryptography And Network Security: Principle andPractice", Prentice Hall Inc .. 2nd ed. 1999.

    (Ste94] Stevens, \V. Richards, ;;TCP/IP lliustrated, Vol. 1 The Protocols!" Addison