2016년 12월 31일 토요일

IPsec

IPsec

TCP/IP group
Application layer

BGP / DHCP / DNS / FTP / HTTP / IMAP / IRC / LDAP / MGCP / NNTP / NTP / POP / RIP / RPC / RTP / SIP / SMTP / SNMP / SSH / Telnet / TFTP / TLS/SSL / XMPP

Category
Transport layer

TCP / UDP / DCCP / SCTP / RSVP

Category
Network layer

IP (IPv4IPv6) / ICMP / ICMPv6 / NDP / IGMP / IPsec

Category
The link layer

ARP / OSPF / SPB / Tunneling (L2TP) / PPP / MAC (EthernetIEEE 802.11DSLISDN

Category

IPsec (Security Architecture for Internet Protocol, アイピーセック) is to use a code technique and is a protocol to provide manipulation detection and a concealment function by an IP packet unit. I can in this way prevent that I look in communication contents and am seen and am tampered in the middle of a channel even if I use transport layer and the application that do not support coding.

IPsec is required in the IPv6, and an exclusive expansion header is defined. On the other hand, it is available, but it is not essential and, in IPv4, uses IP header option.

Table of contents

Version

I devise the standard of IPsec in ipsec wg of IETF and show it as RFC. I do not give IPsec version number in IETF, but the following version is given unofficially, and the version as of 2016 is IPsec-v3:

  • It is the thing of the RFC182x form IPsec-v1
  • It is the thing of the RFC260x form IPsec-v2
  • It is the thing of the RFC430x form IPsec-v3

Protocol summary

Constitution

IPsec is to establish a unidirectional connection called the SA (Security Association) between two peers and establishes secure communications between peers (detailed later description). In addition, as for the SA, it is necessary to establish the up and two outbound SA when I perform two-way communication because there is unidirectionally it.

I can classify the peers in host and two kinds of the security gateway. The former is an apparatus equivalent to the endpoint of the IP communication such as the personal terminal and server. The latter is an apparatus taking broadcast of the IP communication such as the router.

Which type a peer is theoretically does not matter to IPsec. Therefore, I can protect the whole communication from a host to a host for one direct SA, and the use that is in a relay form to establish separate SA every two way station intervals, and to protect communication is possible. However, the communication mode which is recommended which type a peer is exists to mention it later.

Each peer of IPsec manages SPD (security policy database), two databases called SAD (security association database).

It is a database of the security policy to decide whether you do the transmission (apply IPsec) using IPsec whether the transmission (bypass IPsec) does whether SPD performs destruction (discard) of a packet depending on an IP address, a protocol (TCP/UDP/ICMP), the information such as the TPC port without using IPsec.

On the other hand, SAD is a database of the parameters to use when I establish each peer and SA.

Flow of the protocol

I go through 3 following steps so that peer S communicates in IPsec for peer R.

  • I establish SA from S to R.
  • S communicates a code in a packet using SA in R.
  • R receives data and performs necessary handling of decoding.

At the stage to establish the SA that is the first step, a key joint ownership protocol is carried out. At this time, using a shared key, I encrypt communication by the second step and decode it by the third step. In the following, I describe the outline of these three steps.

Establishment of the SA

It is decided whether peer S discards the packet that required that the protocol of the higher layer sends it to R by referring to SPD of oneself whether you protect it in IPsec because you just send it, and you send it.

When I decide to protect it in IPsec, and to send it, I confirm peer S whether the data which are necessary for establishment of the SA already exist in SAD. If data gather, I read those data from SAD.

On the other hand, I carry out IKE (Internet Key Exchange) which is a protocol to establish the information that is necessary for SA with peer R when SAD does not have all data necessary for establishment of the SA. As of 2016, the latest edition of IKE is IKEv2.

IKE is a protocol to establish information necessary for SA like statement above, but it is key joint ownership with peer R that become Maine in that as the name shows it.

In addition, as a protocol to establish information necessary for SA, can use Kerberized Internet Negotiation of Keys (English version) (KINK) and IPSECKEY DNS records in substitution for IKE [1]; [2] [3] [4].


Code communication

After SA was established, peer S and R use either protocol in following two and communicate (they can theoretically indicate both protocols):

In the case of establishment of the SA, the common key necessary for code handling of AE and ESP uses generation or the thing which I read.

The certification code is the common key to lacquering with gold and silver pattern code method which can carry out both coding and message certification. Therefore, both Stealth and manipulation detection of the packet are secured when I use ESP. On the other hand, only manipulation detection is secured when I use AH.

I perform the communication according to either two following movement modes:

  • A transport mode: I give code processing only in department of packet data.
  • Tunneling mode: It is addition with the IP header which gives code processing as "data" in the whole packet including a header entirely, and is new.

The transport mode is used by the communication between two hosts mainly, and the tunneling mode is used by a security gateway and a security gateway and a security gateway and the communication between hosts mainly.


Processing at the time of the reception

Peer R receives a packet and, according to a mention of SAD, decides whether you cancel a packet. And if a packet is a thing of IPsec; a packet return; hand a packet to the protocol of the high rank layer after claiming it (when is encrypted), and having inspected the message certification more. I hand a packet to the protocol of the direct high rank layer without giving handling of decoding when a packet is not IPsec and is a thing of the normal IP.

Code method to use

The description of the quality dried bonito was RFC 7321 2.3-2.4 sections, and a demand level was based on things more than SHOULD, unless otherwise specified.

AES-GMAC cut down SHOULD+, the output of AES-XCBC-MAC to 96 bits as MAC of AH, and (AES-XCBC-MAC-96) is SHOULD. NULL (there is no = MAC) is MAY, too.


AES-GCM is SHOULD+ as a certification code of ESP. For the certification code of the Encryption-then-Mac (EtM) type, as for the code part, NULL (I do not become = code) and AES-CBC are MUST, and, as for the MAC part, MUST, AES-GMAC of key head 128 bits cut down SHOULD+, the output of AES-XCBC-MAC to 96 bits thing (HMAC-SHA1-96) which cut down the output of HMAC-SHA1 to 96 bits, and (AES-XCBC-MAC-96) is SHOULD.

But the above-mentioned demand level is based on past process and recommends AES-GCM in AES-GMAC, ESP in AE when I see it from the viewpoint of safety and efficiency (RFC 7321 4.1 sections, 4.3 sections).

Detailed of each protocol

AH

AH (Authentication Header) provides a prevention of certification and manipulation function. Because the data itself is not encrypted, it is not available in telesecurity. AH of the RFC 1826 form does not have a prevention of retransmission function (Anti Replay Counter), but a counter of 64 bit is attached in RFC 4302 of 32 bit in RFC 2402, and a multiplex function not to receive is available optionally even if it is past and a packet sent to copies it and is retransmited.

Authentication (AH) header format
Offsets Octet16 0 1 2 3
Octet16 Bit10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Next Header Payload length It has been made a reservation
4 32 Security Parameters Index (SPI)
8 64 Order number
C 96 Integrity Check Value (ICV)

ESP

ESP (Encapsulated Security Payload) encrypts a payload part. The part except IP header, a course header, the hop by hop option header is encrypted exactly. ESP of the RFC 1827 form does not have a certification function, but there is a "certification trailer" function in ESP of the RFC 2406 / RFC 4303 form optionally and can use a prevention of manipulation function when I use AH together (but what is guaranteed cannot detect the manipulation of the IP header part only in data part). In addition, the prevention of retransmission function is added to the latter like AH, too.

Because the header head is different from subsequent RFC, AH/ESP of the RFC 1826 / RFC 1827 form is incompatible. 64 bit counters of the RFC 4302 / RFC 4303 form are called ESN (Extended Sequence Number), but what is added to a packet cannot be really distinguished from the packet of the RFC 2402 form visually only in lower 32 bit. But there is not the direct compatibility between IPsec of the RFC 2402 / RFC 2406 form and IPsec of the RFC 4302 / RFC 4303 form because all 64 bit is used in calculation of certification vector (ICV) either. It is necessary to state use of compatible counter of 32 bit clearly, and to appoint it to communicate with RFC 2402 / RFC 2406 form by the IPsec implementation of RFC 4302 / RFC 4303 specifications.


Encapsulating Security Payload (ESP) format
Offsets Octet16 0 1 2 3
Octet16 Bit10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Security Parameters Index (SPI)
4 32 Order number
8 64 Payload number
   
  Padding (0-255 octets)  
  Pad Length Next Header
Integrity Check Value (ICV)

IKE

The protocol that IKE (Internet Key Exchange protocol) performs exchange of the information necessary to build SA safely. IKEv2 (RFC 4306) is defined as IKEv1 (RFC 2409), and the latest edition as of 2016 is the latter.

In addition, key distribution protocols such as Photuris (RFC 2522), KINK (RFC 4430) are suggested as well as IKEv1/v2.

IKEv2


IKEv1

It is a meaning of Internet Key Exchange protocol version 1, and IKEv1 is a key distribution protocol communicated on UDP port number 500. There is the past called the ISAKMP/Oakley at the time of the development, and this is a meaning called the things which implemented Oakley key distribution procedure on ISAKMP (Internet Security Association and Key Management Protocol) protocol. In other words, IKEv1 is not necessarily the same thing with ISAKMP.

IKEv1 performs a key distribution in a two-step procedure called 2 for a phase for 1 for a phase. At first I perform the certification and the code exchange between IKE protocols in 1 for a phase (I call this the ISAKMP SA exchange) and change an application condition and the key information of IPsec in 2 for a phase (I call it the IPsec SA exchange). There are two procedures called Main Mode,Aggressive Mode for 1 for a phase. The former is a name of the Identity Protection Exchange procedure in ISAKMP specifications, and the latter is a name of the Aggressive Exchange procedure in ISAKMP specifications. (complication and the difficulty in understanding of the term definition are one of the reasons complicating understanding of IKE, too). The communication of 2 is encrypted using Shared Key established in 1 for a phase for a phase. The procedure of 2 was called Quick Mode for a phase, and ISAKMP did not have it, and this was defined newly in IKEv1. The procedure called New Group Mode is defined on the standard of IKEv1, too, but is hardly really used.

The Oakley key distribution procedure determined some sets of algorithm and the parameter of the key distribution procedure using the public key encryption, and the algorithm greatly divides it, and there are two kinds of Diffie-Hellman key joint ownership (DH-MODP) and oval curve code (EC2N). As for the key head, 155,188,163,283,409,571bit is defined in 768,1024,1536,2048,3072,4096,6144,8192bit, EC2N in DH-MODP.

I call a node communicating IKE IKE peer and call an initiator, the side that I received with レスポンダ on a side publishing IKE demand. A parameter of Oakley and the details of the IPsec SA show the combination that the initiator side is available (I call this a proposal) and step on a procedure to choose the thing which I judged if the レスポンダ side is the most appropriate, and to take the agreement. Depending on implementation and setting, I may call this "policy" what you consider it "appropriate" with, but attention is necessary not to confuse it because it is not a nuance necessarily same as IPsec Security Policy in the meaning of the narrow sense. I call these "lists of parameters to determine the behavior at the time of the key distribution" Peer Authorization Database (PAD) in RFC 4301 to avoid the confusion of the term.

Aggressive Mode reduces a part of the proposal procedure in 1 for a phase and I decide a part of the parameter and reduce the packet switching number of times in comparison with 打 ちとすることで Main Mode (3 coming and going 6 packet → 1.5 coming and going 3 packets) and improve communication efficiency. But there is the risk to have possibilities to invite a security hole by the wiretapping because it is sent whereas a changed ID packet is encrypted last in Main Mode without ID information being encrypted in Agressive Mode. I depend on the initiator, and after all it is determined which mode you use for 1 for a phase by the policy (PAD) in the network.

I authenticate the partner peer with a key distribution in IKEv1. I go through the process of presentation - agreement in 1 for a phase, and the certification algorithm is carried out, too, and there are a prior key joint ownership method (PSK:Pre Shared Key), a digital signature method (Digital Signatures), public key cryptosystem (Public Key Encryption) for a certification method.

As a general rule, the key to IPsec SA information generated in 2 for a phase is generated by Shared Key information generated in 1 for a phase. However, in the case of the direction for uses generating several IPsec SA in a mass, it may be unfavorable that all IPsec SA information depends on one secret information. In this case the use of bells and whistles called Perfect Forward Secrecy (PFS) is possible (if implemented by communication peer both sides) in IKEv1. PFS performs new Oakley key distribution at the time of exchange for 2 for an individual phase and I generate different Shared Key individually and apply it at the time of private key generation of the IPsec SA. PFS improves communication Stealth generally, but it is said that it should be decided depending on policy (or PAD) whether I should apply this to improve the disposal of peers load.

In addition, there is the implementation to get the Stealth which is equal to PFS by, as a result, making a generation key a different one for 2 for all phases by limiting the number of times of 2 for a phase associated with the exchange for 1 for one phase to limit it once and may call this with Master PFS. In this case "PFS of the narrow sense" mentioned above is called Session PFS and is distinguished.

IKEv1 has many modes and a parameter and an optional pair in this way, and more expansion specifications exist. There are a lot of things which were over without being listed as official RFC without being able to pass the draft of the thing suggested to as a standard plan in that. In addition, I may give the original name in implementation system because the term which is difficult in IKEv1 specifications, and is confusing is complicated (e.g., I call a selector in IPsec a filter by Microsoft Windows and call policy an action). Therefore, profound understanding of a protocol and the product implementation was necessary even for IKEv1 which should be "IETF standard" for 異機種間接続 and has been going to lay custom, it "was the most certain to use the same apparatus of the same maker when I crossed a network in IPsec".

IETF gives up rearranging of IKEv1 which has been in confusion and plans toeing the mark again of the standardization with IKEv2.

Characteristic of IPsec

Layer to encrypt

Because IPsec is a protocol to realize security in network layer, I can secure security as the whole communication when the high ranks layer such as the application does not support coding. A user can still less know which protocol coding is made in like TLS realizing security in application layer easily because I realize security in network layer (a key mark is displayed in TLS by web browser, and the indication that at a glance it understands may be done). They can use IPsec at the consumer terminals such as a PC or the smartphone, but the present conditions are often used as VPN between Gateway which a specialized engineer manages. Tunneling mode to add an IP address to double when I use IPsec in VPN is available, but the packet except the IP may be used together with protocols such as the L2TP to communicate.

I complexity of the setting when flexible

IPsec can use in combination a certification function of AH, the code function of ESP, and each AH/ESP can appoint various algorithm. This adaptability is an advantage of IPsec, but setable pairs become enormous, and communication is not established if all setting does not agree between two points to communicate. 多台数間のIPsec情報を手動で設定することは非常に手間がかかる上に、手動設定の場合は同じ鍵情報を長期間使い続けることになるため、セキュリティ強度の観点からも好ましくない。 IPsecが上述したVPNで利用されることが多いのはこのためである。 この手間を軽減するためネットワークで自動鍵交換を行うIKEv1,IKEv2,KINK,Photurisなどのプロトコルも提案されているが、各プロトコルには互換性が無い。 最も普及しているIKEv1でも動作モード、認証パラメータ、認証方式、鍵交換アルゴリズム、暗号アルゴリズム及び認証アルゴリズムなど設定項目の組み合わせは多岐に渡り、IPsecを使いこなすには総じて高度な専門知識が要求される。

IPsec が使えるシステム

  • Windows - Windows2000 / XP は IPv4, IPv6 で利用可能であるが、IPv6はESP暗号化に対応していない。Windows VistaはIPv4、IPv6で利用可能である。
  • macOS - KAME由来のIPsecが利用可能。OS標準のGUIで利用出来るのはL2TP / IPsecのみである。
  • BSD - FreeBSDNetBSDではKAMEで作られた実装が取り込まれており、OpenBSDでは独自に実装を行っている。
  • Linux - IPv4、IPv6で利用可能。IKEはKAME由来のipsec-toolsのracoonを利用する。他にFreeS/WANプロジェクトから派生したOpenswanstrongSwanがある。

歴史

In December 1993, the Software IP Encryption protocol swIPe (protocol) was researched at Columbia University and AT&T Bell Labs by John Ioannidis and others.

Based on the funding from the Clinton administration in hosting whitehouse.gov email (from June 1 of 1993 to January 20 of 1995) at Trusted Information Systems, Wei Xu started in July 1994 the research on IP Security, enhanced the IP protocols, developed the IPSec product on the BSDI platform, and quickly extended it on to Sun OS, HP UX, and other UNIX systems. Upon the success, Wei was facing another challenge by the slow performance of computing DES and Triple DES. The assembly software encryption was unable to support even a T1 speed under the Intel 80386 architecture. By exporting the Crypto cards from Germany, Wei further developed an automated device driver, known as plug-and-play today, in integrating with the hardware Crypto. After achieving the throughput much higher than a T1s, Wei Xu finally made the commercial product practically feasible, that was released as a part of the well-known Gauntlet firewall. In December 1994, it was deployed for the first time in production for securing some remote sites between east and west coastal states of the United States.

Another IP Encapsulating Security Payload (ESP)[5] was researched at the Naval Research Laboratory as part of a DARPA-sponsored research project, with openly published by IETF SIPP[6] Working Group drafted in December 1993 as a security extension for SIPP. This ESP was originally derived from the US Department of Defense SP3D protocol, rather than being derived from the ISO Network-Layer Security Protocol (NLSP). The SP3D protocol specification was published by NIST, but designed by the Secure Data Network System project of the US Department of Defense. The Security Authentication Header (AH) is derived partially from previous IETF standards work for authentication of the Simple Network Management Protocol (SNMP) version 2.

In 1995, The IPsec working group in the IETF was started to create an open freely available and vetted version of protocols that had been developed under NSA contract in the Secure Data Network System (SDNS) project. The SDNS project had defined a Security Protocol Layer 3 (SP3) that had been published by NIST and was also the basis of the ISO Network Layer Security Protocol (NLSP).[7] Key management for SP3 was provided by the Key Management Protocol (KMP) that provided a baseline of ideas for subsequent work in the IPsec committee.

IPsec is officially standardised by the Internet Engineering Task Force (IETF) in a series of Request for Comments documents addressing various components and extensions. It specifies the spelling of the protocol name to be IPsec.[8]

関連するRFC

標準化過程(Standards Track)

  • RFC 1829: The ESP DES-CBC Transform
  • RFC 2403: The Use of HMAC-MD5-96 within ESP and AH
  • RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH
  • RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV
  • RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec
  • RFC 2451: The ESP CBC-Mode Cipher Algorithms
  • RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH
  • RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
  • RFC 3602: The AES-CBC Cipher Algorithm and Its Use with IPsec
  • RFC 3686: Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
  • RFC 3947: Negotiation of NAT-Traversal in the IKE
  • RFC 3948: UDP Encapsulation of IPsec ESP Packets
  • RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
  • RFC 4301: Security Architecture for the Internet Protocol
  • RFC 4302: IP Authentication Header
  • RFC 4303: IP Encapsulating Security Payload
  • RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
  • RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
  • RFC 4308: Cryptographic Suites for IPsec
  • RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
  • RFC 4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
  • RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
  • RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2
  • RFC 4868: Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
  • RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
  • RFC 5282: Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
  • RFC 5386: Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
  • RFC 5529: Modes of Operation for Camellia for Use with IPsec
  • RFC 5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)
  • RFC 5723: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
  • RFC 5857: IKEv2 Extensions to Support Robust Header Compression over IPsec
  • RFC 5858: IPsec Extensions to Support Robust Header Compression over IPsec
  • RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)
  • RFC 7321: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
  • RFC 7383: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
  • RFC 7427: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
  • RFC 7634: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec

実験的(Experimental)

  • RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

情報(Informational)

  • RFC 2367: PF_KEY Interface
  • RFC 2412: The OAKLEY Key Determination Protocol
  • RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
  • RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements
  • RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
  • RFC 4809: Requirements for an IPsec Certificate Management Profile
  • RFC 5387: Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)
  • RFC 5856: Integration of Robust Header Compression over IPsec Security Associations
  • RFC 5930: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol
  • RFC 6027: IPsec Cluster Problem Statement
  • RFC 6071: IPsec and IKE Document Roadmap
  • RFC 6379: Suite B Cryptographic Suites for IPsec
  • RFC 6380: Suite B Profile for Internet Protocol Security (IPsec)
  • RFC 6467: Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)

Best Current Practice RFCs

  • RFC 5406: Guidelines for Specifying the Use of IPsec Version 2

廃止(Obsolete)/歴史的(Historic)

  • RFC 1825: Security Architecture for the Internet Protocol (obsoleted by RFC 2401)
  • RFC 1826: IP Authentication Header (obsoleted by RFC 2402)
  • RFC 1827: IP Encapsulating Security Payload (ESP) (obsoleted by RFC 2406)
  • RFC 1828: IP Authentication using Keyed MD5 (historic)
  • RFC 2401: Security Architecture for the Internet Protocol (IPsec overview) (obsoleted by RFC 4301)
  • RFC 2406: IP Encapsulating Security Payload (ESP) (obsoleted by RFC 4303 and RFC 4305)
  • RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP (obsoleted by RFC 4306)
  • RFC 2409: The Internet Key Exchange (obsoleted by RFC 4306)
  • RFC 4305: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (obsoleted by RFC 4835)
  • RFC 4306: Internet Key Exchange (IKEv2) Protocol (obsoleted by RFC 5996)
  • RFC 4718: IKEv2 Clarifications and Implementation Guidelines (obsoleted by RFC 7296)
  • RFC 4835: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (obsoleted by RFC 7321)
  • RFC 5996: Internet Key Exchange Protocol Version 2 (IKEv2) (obsoleted by RFC 7296)

関連項目

外部リンク

脚注

  1. ^ Harkins, D.; Carrel, D. (November 1998). The Internet Key Exchange (IKE). IETF. RFC 2409. https://tools.ietf.org/html/rfc2409. 
  2. ^ Kaufman, C., ed. IKE Version 2. IETF. RFC 4306. https://tools.ietf.org/html/rfc4306. 
  3. ^ Sakane, S.; Kamada, K.; Thomas, M.; Vilhuber, J. (November 1998). Kerberized Internet Negotiation of Keys (KINK). IETF. RFC 4430. https://tools.ietf.org/html/rfc4430. 
  4. ^ Richardson, M. (February 2005). A Method for Storing IPsec Keying Material in DNS. IETF. RFC 4025. https://tools.ietf.org/html/rfc4025. 
  5. ^ "SIPP Encapsulating Security Payload". IETF SIPP Working Group (1993年). Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  6. ^ "Draft SIPP Specification". IETF. p. 21 (1993年). Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  7. ^ http://www.toad.com/gnu/netcrypt.html
  8. ^ "RFC4301: Security Architecture for the Internet Protocol". Network Working Group of the IETF. p. 4 (2005年12月). Template:Cite webの呼び出しエラー:引数 accessdate は必須です。 "The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec [...] are deprecated."

This article is taken from the Japanese Wikipedia IPsec

This article is distributed by cc-by-sa or GFDL license in accordance with the provisions of Wikipedia.

Wikipedia and Tranpedia does not guarantee the accuracy of this document. See our disclaimer for more information.

In addition, Tranpedia is simply not responsible for any show is only by translating the writings of foreign licenses that are compatible with CC-BY-SA license information.

0 개의 댓글:

댓글 쓰기