IPsec (IP security)

1994년 IAB(Internet Architecture Board)에서 "Security in the Internet Architecture"라는 이름으로 제안되었고 RFC 1636에 설명되어있다.

 

 

IPsec의 이점은 다음과 같다.

 

• IPsec은 방화벽이나 라우터에서 구현이되어 있기때문에, 모든 traffic에 대한 보안이 적용된다. 따라서 end-user는 어떤 overhead도 발생하지 않는다.
• 방화벽에서 작동하는 IPsec은 만약 외부로부터 오는 모든 트래픽이 IP를 사용해야 하거나, 방화벽이 인터넷에서 조직으로 들어오는 유일한 수단인 경우 방화벽을 bypass 할 수 없다(즉. 모든 트래픽이 IP를 사용하고, in-bound에 방화벽이 설치되어있다면, 무조건 방화벽을 거쳐서 통과해야한다).
• IPsec이 Transport layer 아래에 존재하기때문에 Application에 대해 영향을 끼치지 않는다. 따라서, IPsec을 구현하려는 경우  software나 server system을 바꾸지 않아도 된다.
• IPsec을 사용할때, 사용자에 대한 특별한 관리가 필요없다(key를 지우거나, IPsec에 대해 교육하거나 기타 등등).
• 개별적인 보안을 제공할 수 있다.

 

IPsec은 3가지 역할을 한다.

 

1. Authentication
2. Confidentiality
3. Key management

 

IPsec에 대한 공식 문서는 RFC나 IETF에 많은 문서가 있다. IPsec은 IP layer에서 보안을 제공하며, IPv4, IPv6에 대해 모두 동작한다.

 

시작하기에 앞서 AH, ESP에 대한 내용이 자주 등장하는데, 이 링크에 간단하게 잘 설명되어 있다.

 

간단하게 말해서, AH는 인증, 무결성에 사용되며 ESP는 인증, 무결성, 기밀성(암호화)를 제공한다. ESP가 AH의 모든 내용을 포함하고 있으므로 현재는 잘 사용되지 않는다.

 

#Transport Mode , Tunnel Mode

 

 

Transport Mode와 Tunnel Mode Overview

 

AH와 ESP는 Transport와 Tunnel Mode 두가지를 지원한다. 위의 사진에서 보이는 것처럼 가장 큰 차이는 Transport는 기존의 IP Header를 사용한다는 점과, Tunnel은 새로운 IP Header를 붙인다는 점이 다르다.

 

 

 

Layer의 구분

 

Transport mode는 upper-layer에 대한 보안을 제공한다. 예를들어 TCP, UDP, ICMP packet의 같은 경우 IP layer위에서 동작하는 프로토콜에 대해서 보안을 제공한다.

 

보통 end-to-end 환경에서 많이 사용된다. ESP는 Transport모드에서  encrypt와 IP Payload(IP header를 제외한 나머지 부분)에 대한 authenticate를 선택적으로 제공한다(IP Header에 대해서는 아님). AH 는 Transport 모드에서 IP payload에 대한 authenticate와 IP header에 대한 authenticate를 제공한다.

 

Tunnel Mode는 전체 IP Packet에 대한 보호를 제공하고, 이를 위해서 IP Header를 새로 생성해서 append 한다. 즉 기존의 ip header를 포함한 payload를 새로운 ip header에 대한 payload로 취급한다. Tunnel Mode는 한쪽, 또는 양쪽에 있는 방화벽이나 라우터가 Security Gateway(IPsec을 지원하는)인 경우 사용한다.  따라서, host들이 IPsec에 대한 구현을 하지 않아도, IPsec을 사용할 수 있다. 왜냐하면, 라우터나 방화벽이 해주기 때! 문! 그래서 Host가 Pacekt을 생성하면, Tunnel Mode를 지원하는 Router에 의해 Tunneling 된다.

 

 

IP를 위한 authentication과 confidentiality의 핵심은 SA(Security Association)이다. SA는 Sender와 receiver간의 Security Traffic이 전달되는 논리적인 일방향 연결이다. 즉, 양방향 간의 보안 통신이 필요하면 SA는 두개가 필요하다.

 

SA의 파라미터는 3개가 사용된다.

 

1. SPI (Security Parameters Index) : 32-bit의 unsigned integer로 되어있으며, 처리될 SA를 선택할 수 있도록 AH나 ESP Header안에 포함하여 전송된다.
2. IP Destination Address : SA로 전달될 Destination Address이다. end-user의 router이거나 방화벽이 다수이다.
3. Security Protocol Identifier : AH를 이용한것인지 ESP를 이용한 것인지 나타내는 field, 추가한 IP header에 존재함.

 

 

 

SPD (Security Policy Database)

 

• Remote IP Address : IP Address, network range, wildcard가 저장되며 network range와 wildcard는 같은 SA를 사용하는 network를 지원하기 위해 이용된다.
• Local IP Address : IP Address, network range, wildcard가 저장되며, 마찬가지로 같은 SA를 사용하는 network를 지원하기 위해 network range, wildcard가 사용된다.
• Next Layer Protocol : IP header다음에 올 protocol type이 온다.
• Name : IPsec이 동일안 운영체제에서 실행경우 사용하는 사용할 수 있는 식별자
• Local and Remote Ports : TCP, UDP Port로 port의 list나 wild card가 올 수있다.
• 처리 방식 : PROTECT ( SAD에 따라 처리), BYPASS(IPsec을 이용하지 않고 그냥 송신), DISCARD(폐기)

SPD 예제 

 

SAD (Security Association Database)

• SPI (Security Parameter Index) : 32bit로, 수신자측의 SA 대한 유일한 값이다. Packet을 송신시에는 AH, ESP Header에 값을 적용해서 보내고, 수신시에는 SPI에 매핑되는 SA를 SAD에서 찾아서 사용한다. 
• Sequence Number Counter : 32bit로, AH와 ESP Header의 Sequence number field에 사용된다.
• Sequence Counter Overflow : Sequence Number Counter가 overflow되었는지 나타내는 flag로 SA에서 추가적인 전송을 막기 위해 사용됨.
• Anti-Replay Window : Replay Attack 을 막는데 사용된다. 
• AH Infomation : Authentication algorithm, keys, key lifteim. AH와 관련된 parameters
• ESP Information : Encryption and authentication algorithm, keys, initialization values, key lifetims, ESP와 관련된 parameters
• Lifetime of this Security Association : Time interval 이나 byte count가 저장되고,  이 작업중 어떤 작업에 수행되어야 될지에 대한 정보가 저장됨.
• IPsec Protocol Mode : Tunnel, Transport, Wildcard
• Path MTU : Path에 대한 MTU

 

 

 

IPsec을 사용하면 Outbound와 Inbound에 대해서 처리를 하는데 Logic을 살펴보도록 하자.

#OUTBOUND PROCESS

 

 

Outbound Processing Model

1. outbound packet이 들어오면 SPD에 일치하는 rule이 있는지 찾아본다. 
2. match되는 rule이 없으면 폐기하고, 에러 메세지를 발생시킨다.
3. match되는 rule이 있을때, DISCARD에 해당하는거면 마찬가지로 폐기 시키고, BYPASS이면 그대로 전송한다
4. 만약 (3)번에서 PROTECT에 해당한다면, SAD를 만들기 위해 entry에 대한 여부를 검색하는데, entry에 해당하는 내용이 없으면 IKE를 이용해 키를 생성하고 SA를 생성한다(이때 SAD의 Identifier가 생성되는 것 같다 그리고 다음에 Identifier를 이용해 SA에서 SAD를 정보를 읽어와 다음 처리시에 사용하는 듯!).
5. match되는 entry가 있다면, encryption, authentication, tunnel, transport 등에 대한 IPsec의 모든 처리를 한다. 그 후에 외부로 forward된다.

 

 

#INBOUND PROCESS

 

Inbound Processing Model

1. IP Header의 protocol field를 통해 IP packet인지 ESP 또는 AH packet인지 결정한다.
2. IP Packet이면 SPD와 바교해서 BYPASS이면 IP header를 decapsulation하여 상위 계층으로 전달하고, BYPASS이외에 해당하는 것들은 폐기 시킨다(Router나 Firewall에서 IPsec이 구현된다고 했는데, 왜 IP Header를 decapsulation하지..?).
3. IPsec packet의 경우 SAD에서 match 되는 것이 없는 경우 DISCARD시키고, 이외는 ESP, AH에 대한 처리를 한다. 그리고 IP Header를 Decapsulation한다.

 

 

 

#Encapsulating Security Payload

 

ESP는 confidentiality, data origin authentication(data integrity) 등등을 optional하게 지원하며, 다양한 종류의 encrpytion, authentication algorithm을 지원한다.

 

AH Header

ESP Packet Format

ESP Header는 다음과 같이 구성되어 있다.

• Security Parameters Index : SA의 identifier
• Sequence Number : re-play attack을 방어하기 위해 사용
• Payload Data : trasport mode 또는 tunnel mode에서 암호회된 패킷 
• Padding : 다용도로 사용될 수 있음(보통 pad length와 next header의 위치를 맞추기 위해 사용).
• Pad Length : Padding에 대한 byte 수
• Next Header : 다음에 올 Protocol type
• Integrity Check Value(Authentication Data) : 가변 길이의 field로 ESP Packet에서 Authentication Data field를 제외한 나머지를 compute한 결과가 들어가 있다.

combined mode를 사용하려면, algorithm은 암호화된 평문과, integrity check에대한 결과를 반환해야 하는데, 이 경우 ICV는 생략될 수 있다. intergiry가 필요한 상황에서ICV가 생략될 수 있는데 이때는 Payload data encoding이 ICV와 같은 의미를 가진다. 그리고 IV(Initailizaion Value)는 ESP Algorithm에서 사용되는 경우, optional하게 제공된다. 그리고, Traffic Flow Confidentiality는 tunnel mode사용시에 제공되며 Padding data 앞 Payload Data 뒤에 위치한다. 

 

Payload Data와 padding, Pad length, Next Header filed는 ESP에서 암호화 되며, 암호화 알고리즘에서 Initalizaion Vector와 같은 값이 필요할 경우 Payload Data의 처음에 위치하게 되며, 보통 암호화 되어 있지 않은 상태로 전달된다.

 

ICV field는 optional하며 integrity service가 선택된 경우에만 integrity algorithm 또는 combained mode에서 사용된다. ICV는 모든 암호화 과정을 거친 이후에 계산되며, 암호화 과정 이후에 계산을 하면 decrypt전에 무결성에 대한 검증을 할 수 있으므로 packet이 부적절한 경우 decrpyt과정에 대한 불필요한 과정을 줄이게 된다. 이 때문에 , DoS를 줄일수도있으며, 복호화와 무결성 체크를 동시에 진행할 수도 있다. 다만, ICV는 암호화 되지 않기때문에 적절한 처리가 필요하다.

 

Padding Field는 다음과 같은 목적이 있다.

1. 만약 암호화 알고리즘에서 padding이 필요한 경우(블록암호 등)에 사용될 수 있다.
2. Pad length와 next header를 더한 값이 32bit가 되어야 하고, ciphertext는 32bit의 배수여야 하기때문에 사용된다.
3. 실제 payload 길이를 숨기는데 사용될 수 있다.

Anti-Replay Service는 replay attack을 방어하기 위해 사용되며, 이때 Sequence Number field가 사용된다. Sequence Number는 sender에서 생성한다. 

SA연결이 활성화 되면 Sender는 sequence number를 0으로 설정하고 SA에게 packet이 보내질때마다  Sequence number를 증가시킨다. 이때, 전송횟수는 32비트 최대값을 초과할 수 없으므로, 초과시에는 SA를 종료하고 새로 연결을 시도한다.

 

 

Anti-replay Mechanisum

기본 Window size(W )는 64로 가장 최근에 수신한 메세지를 N이라고 한다. 그리고, 가장 최근에 수신한 메세지가 128번이라고 하면 65번 Packet까지만 유효한 패킷으로 받아들이고, 이때 수신한 Packet에 대해선 별도로 mark처리를 해서 만약, replay-attack이 window size내에 시도된다고 하더라도 폐기될 수 있도록 처리한다. 아래는 처리 과정이다.

 

1. Window size이내에 새로운 패킷이 도달할 경우 MAC(Message Authentication Code)를 체크해서 통과한 경우 해당 Sequence에 marking 한다.
2. Window size 오른쪽에 즉, N+1에 패킷이 도달한 경우 MAC을 체크하고 인증된다면 Window Size 만큼 오른쪽으로 한칸씩 이동시킨후 marking 한다 (즉, N = N+1).
3. Window Size 왼쪽에 있는 경우(이전 seq인 경우)나 인증에 실패한 경우 폐기된다.

 

Transport Mode와 Tunnel Mode

ESP Transport Mode는 encrpyt와 authenticate(optional)에 사용된다. IPv4의 경우 ESP Header는 IP header와 Transport layer사이에 존재하게 되며, ESP trailer ( padding, pad length, next header field 등)는 packet의 맨마지막(또는, Auth를 지원하는경우 auth 앞)에 존재한다.

authentication을 사용하는 경우 ESP authentication data field는 ESP Trailer뒤에 추가된다. 모든 Transport packet과 ESP trailer는 암호화 되며, authentication data는 ESP Header와 모든 암호화를 포함한다. 간단하게 말하면 다음의 과정으로 설명할 수 있다.

1. 데이터 + ESP Trailer를 암호화하고 메세지를 만듦.
2. Router가 (1)에서 만든 packet을 전달 함(이때 Router는 IP header의 Src, Dest만 필요하므로 이후 암호화된 데이터에 대해 영향을 받지 않음).
3. IPsec을 지원하는 Router나 방화벽등에서 IPsec에 대한 처리를 한 다음 나머지 원본을 복호화하여 전송함.

 

ESP Tunnel Mode는 IP Packet을 포함한 전체를 암호화 한다. 이 모드에서는 ESP Header가 packet에 더해진 다음 패킷과 ESP Trailer가 암호화 된다. IP header를 암호화 하는 경우, Router에서 처리할 정보가 사라지므로 새로운 IP header를 append한다. 이렇게 하면 Host 각각에 대한 Key 관리에 대한 cost가 줄어들고 final destination에 대한 analysis를 할수가 없다.

1. Sender가 packet을 생성하고 이 packet앞에 ESP Header를 붙인다. 그다음 암호화된 ESP Trailer와 Authentication Data를 붙인다. 그리고 Destination IP를 firewall로 설정한 새로운 IP Header로 encapsulation한다.
2. 라우터에 의해 firewall로 전송된다.
3. 새로 만들어진 IP header(outer IP header)를 처리하고 검사후에 기존내용을 복구하고, 기존에 Destination으로 전송한다. 

 

Transport vs Tunnel

 

 

SA는 AH와 ESP Protocol을 모두 지원하지만 동시에 지원하진 못한다. 어떤 상황에서는 AH와 ESP를 동시에 사용해야할 때도 있는데, 이때는 같은 Traffic Flow에 대해 여러개의 SA가 사용되어야 한다. Security Association Bundle 은 IPsec 서비스 set을 제공하기 위해 트래픽을 처리해야 하는 sequnece SA를 의미한다.

 

 

• Transport adjacency : tunneling을 사용하지 않고 2개이상의 보안 프로토콜을 IP packet에 적용하는 것을 의미하며, AH와 ESP가 한곳에서 실행되기 때문에 이점이 없음. 
• Iterated tunneling : Tunnel을 통해 (새로운 IP header 추가를 통해) 여러 계층의 보안 프로토콜을 적영할 수 있으므로 경로상에서 각각의 Router에 대해 처리될 수 있으므로 이점이 있음

 

#Authentication + Confidentiality

 

Encrpytion과 Authenticaion은 IP Packet에서 함께 사용될 수 있다.

 

ESP와 Authentication option을 함께 사용하는 경우 ESP data를 붙인 후 authentication data field를 붙인다. 즉, 암호화를 먼저 한 후, authentication에 대한 처리를 진행한다.

 

• Transport mode ESP : IP payload + ESP trailer를 encrypt하고, Authenication은 Encrpytion은 Ecryption된 데이터와 ESP Header에 대해 유효함(IP Header에는 유효하지 않음).
• Tunnel mode ESP : Authencaiton은 모든 IP header(outer IP Header)를 포함한 모든 패킷에 적용되며, 목적지에서 authentication에 대한 처리가 진행된다. 그리고 inner IP header는 encrpytion 되어있다.
  
  

두 경우 모두 암호화된 문장에 대해 authentication이 진행된다(이에 대한 이유는 위에서 간단하게 언급했다).

 

Transport Adjacency는 암호화 후 인증을 적용하는 또다른 방법으로 두개의 SA( AH - ESP)을  사용한다. AH를 ESP의 header부분에 두게 되면, AH에 의해 인증이 되고, 내부의 ESP에 의해 전체 packet이 암호화가 되므로 암호화 이후 인증을 적용할 수 있다.

 

암호화 이전에 인증을 사용하는 이유에는 몇가지가 있을 수 있는데, 첫번째로 authentication에 대한 내용을 암호화한다면, 다른 사람이 메세지를 가로채서 인증 정보를 조작하는것이 불가능하다. 두번째로, 나중에 사용할때 암호화되지 않은 메세지와 인증 정보를 저장하는 것이 더욱 적합하다. 예를들어 암호화 된 정보에 대해 인증을 제공한다면, 추후에 메세지에 대한 인증을 다시한번 해야할때, 인증 정보를 검증하기 위해선 암호화를 다시 해야하므로 부적절하다.

 

암호화 이전에 인증을 사용하는 방법으로는 위의 예시와는 반대로 AH를 Inner Header로 두고, ESP를 외부로 두는 경우 인증을 위해선 먼저  암호화를 풀고 AH에 의해 인증을 할 수 있고, AH가 인증 하는 패킷에 대한 내용은 plaintext이므로 구현할 수 있다.

 

다양한 IPsec의 조합 및 사용

 

 

# Internet Key Exchange

 

Key Management의 일부는 키 결정 및 분배에 관한 문제이다. Key management에는 2가지 type이 존재한다.

 

• Manual : 시스템 관리자가 각 시스템 마다 자신의 키와 다른 communicating system의 키를 ㅣ용해서 설정하는 것으로 규모가 작거나 정적인(변동이 거의 없는) 환경에 적합하다.
• Automated : automated system은 on-demand(고객의 needs가 있을 때 즉시 처리해주는 것을 뜻함) 형식으로 key를 만들어 주고, 대규모 시스템에서 키를 쉽게 사용할 수 있게 해준다.

Automated key management protocol은 또 두개(ISAKMP / Oakley)로 나뉜다.

1. Oakley Key Determination Protocol : Deffie-Hellman algorithm을 기반으로 하고 있으나, 추가적인 보안을 제공하며 특별한 format이 없다.
2. ISAKMP (Internet Security Association and Key Management Protocol) : Internet key management를 위한 framework를 제공하고 format이 있다.

 

ISAKMP는 특별한 key exchange algorithm을 지정하지 않는다. 대신 사용할 수 있는 여러가지 key exchange algorithm에 대한 type으로 구성되어 있다. Oakley는 ISAKMP 초기 버전과 함께 사용되는 특정한 키 교환 알고리즘 이다. IKEv2(Version 2)에서 Oakley와 ISAKMP는 더이상 사용되지 않고, IKEv1의 Oakley 와 ISAKMP의 사용과는 상당히 다르나 기본적인 기능은 같다. 

 

#Key Determination Protocol

 

IKE는 Diffie-Hellman key exchange algorithm을 개선 시켜서 사용한다.

 

q 는 아주 큰 소수 이고, a는 q의 primitive root 이다.

primitive root는 q에 대한 modulo 연산을 했을때 q에 대해 모든 나머지가 나오는것을 말한다. 

 

a = 2 q = 11이라고 가정해보자.

a^2 mod 11 = 4

a^3 mod 11 = 8

a^4 mod 11 = 5

a^5 mod 11 = 10

a^6 mod 11 = 9

a^7 mod 11 = 7

a^8 mod 11 = 3

a^9 mod 11 = 6

a^10 mod 11 = 1

a^11 mod 11 = 2

 

이와같이 모든 나머지를 얻을 수 있으므로 a는 q의 primitive root라고 한다.

$$q$$

Big Prime Number

$$\alpha$$ 

primmitive root of q 

Deffie Hellman 알고리즘은 2가지 특징이 있다.

1. Secret-key는 필요시에 생성되며 장기간 보관할 필요가 없다.
2. 특별한 infrastructure가 필요하지 않다(module 연산과 단순 연산으로 비밀키를 공유할 수 있다).

Deffie-Hellman에서 완벽한 키교환에 대한 알고리즘을 제공하는 반면, 취약점이 있다.

• 통신하는 주체의 신원을 보장할 수 없다.
• 따라서, MITM 공격의 대상이 될 수 있으며, A 와 B가 통신을 하려할때 제 3자인 C가 중간에서 A에게는 B인척을, B에게는 A인척을 해서 A와 B의 Diffie-Hellman 키 교환시에 C를 통해서 합의가 이루어 지도록 한다면, 중간에서 C가 정한 임의의 값을 통해 만들어진 Secret-key로 통신을 주도할 수 있다.
• clogging attack에 취약하다(공격자가 많은 양의 key를 request하는 attack).

IKE에서는 이 Diffie-hellman의 장점을 가지는 반면, 위와 같은 취약점을 보완할 수 있도록 다시 디자인했다.

1. clogging attack을 방지 하기 위해 cookie라고 하는 mechanism을 고안했다.
2. 알고리즘을 식별할 수 있고, Diffie-Hellman exchange의 global parameter를 지정할 수 있도록 하였다/
3. replay-attack을 막기위해 nonce값을 사용한다.
4. Deffie=Hellman의  public-key교환을 가능하도록 한다.
5. MITM을 막기위한 인증을 제공한다.

위에서 언급한 것 처럼 clogging attack은 중간에서 public-key를 victim에게 전송하면 victim은 secret-key를 얻기위해 지수연산을 계속하게 되고 이런 request가 반복되면 의미없는 지수연산으로 인해 시스템 자원이 소모된다. cookie exchange는 각 pseudo random number를 처음 메세지에 전송시 상대방에게 보내고 상대방은 그에 대한 acknowledge로 응답한다.

 

1. Cookie는 특정인에 대해 유효해야 하며, 이렇게 하면 Attacker가 실제 IP와 UDP를 사용해서 유효한 Cookie를 획득하더라도, random으로 생성한 IP나 Port를 위에서 생성한 Cookie를 이용해 통신을 시도하려고 해도 정상적으로 동작하지 않는다.
2. Cookie를  발행자 이외에 누구도 유효한 쿠키를 생성할 수 없어야 한다. 즉, 발행자가 가지고 있는 local secret information을 통해 생성하고, 검증할 것을 의미하며. 쿠키를 통해 저 local secret information을 추론할 수 없어야 한다. local secret information이 공개되는 경우에는 더 취약해 지지만, 들어오는 쿠키에 대해 검증을 할 수 있다.
3. 생성 및 검증은 clogging attack을 막기 위해 충분히 빨라야 한다.

 

권장하는 것은 IP Src, Dest UDP Src, Dest Port과 secret value를 이용해 md5를 사용하는것이다. 또한, 768, 1024, 1536 bit의exponentiation moduler와, Elliptic curve group 2^155, 2^185도 지원한다.

 

Group of IKE

 

그리고 Replay-attack을 막기위해 none가 pesudorandom number로 생성되며, 암호화 된다. 

1. Digital signature : User의 ID나 nonce와 같은 값들을 암호화 해서 Hash한 후 각 Private-key로 암호화 한다.
2. Public-key encrpytion : ID와 Nonce 값을 Sender의 private-key로 암호화 한다
3. Symmetric-key encryption : 기존에 생성된(어디선가 생성된) key를 이용해서 암호화 할 수 있다.

IKEv2 Exchange

 

Initial exchange에서는 첫번째로 cryptographic algorithm과 security parameters 및 nonce와 같은 정보를 교환한다. 결과로, IKE SA가 set up된다. 이 SA는 상대방 간의 보안 채널에 대한 매개 변수를 정의하며, 이로 인해 메세지는 authentication와 encryption 처리 된다. 

두번째로, 인증 및 통신을 보호하는데 사용될 IPsec SA를 설정한다

 

CREATE_CILD_SA exchange는 트래픽 보호를 위한 추가 SA를 설정할 수 있다.

 

Information exchange는 정보를 교환하는데 사용된다. IKEv2의 error 메세지나 notification 등

 

 

#IKE Header

 

 IKE Header는 하나 이상의 payload로 구성되어 있으며 UDP 프로토콜을 이용해서 전달된다.

 

IKE Format

 

• Initator SPI : SA에 대한 Unique한 값
• Responder SPI : responder가 선택한 SA의 값
• Next Payload : 다음에 올 payload의 값
• Major Version : IKE의 Major version
• Minor Version : Minor version
• Exchange Type : exchange 할 type을 가리킨다.
• Flags : IKE exchange에 대한 옵션으로  8bit 중 3bit가 현재 정의 되어 있으며, initiator bit는 packet이 SA intiiator로 부터 발송되었는지를 뜻하고, version bit 현재 사용중인 버전보다 더 높은 버전을 사용할 수 있는지, 그리고 response bit는 동일 Message ID에 대한 응답인지를 나타냄.
• Message ID : Message ID는 Retransmission및 응답에 대한 제어를 위해 사용
• Length : Header와 Payload를 포함한 전체 길이 

ISAKMP에 대한 패킷 

 

IKE Payload

 

 

• Key Exchange payload : 키 교교환에 사용되는 Oakley, Diffe-Hellman RSA 등등
• Identification payload : 식별자로 IP 주소가 들어가 있는 경우가 많음
• Certificate payload : 아래와 같은 public-key 인증 정보를 포함하는 filed
  • PKCS #7 wrapped X.509 certificate
  • PGP certificate
  • DNS signed key
  • X.509 certificate - signature
  • x.509 certificate - key exchange
  • Kerberos tokens
  • CRL
  • ARL
  • SPKI certificate

 

 

#Cryptographic suite

IPsec Version 3와 IKEv3는 다양한 암호알고리즘을 지원한다.

 

RFC 4308에는 VPN을 위한 2개의 암호화를 이야기하고 있으며 그게 VPN-A와 VPN-B이다.

VPN-A의 경우 이전 IKEv1에서 사용하는 보안과 일치하며 VPN-B가 보다 강력한 보안을 제공하며 IPsec Version 3및 IKEv2를 제공하는 VPN에 권장된다.

 

VPN-A vs VPN-B