Google
 
이번글은 IPsec 에서 ESP (Encapsulating Security Payload) 과 더불어 Traffic 을 처리하는데 사용되는 AH (Authentication Header) 에 대해서 알아보도록 하겠습니다. 

AH (Authentication Header)는 무결성 (Data integrity) 기능과 원본 인증 기능 그리고 Anti replay 서비스를 제공하는데, RFC2402에 정의 되어 있습니다. ESP (Encapsulating Security Payload) 와 다른 점은 AH (Authentication Header)는 암호화를 하지 않는다는 점입니다.

그래서 AH 사용에 대한 의문이 제기되고 있고, 없애자는 의견도 있지만, IP 패킷에 대한 인증을 할 때에 ESP (Encapsulating Security Payload) 는 헤더를 제외하고 하지만, AH (Authentication Header) 는 헤더를 포함하여 인증을 한다는 장점이 있습니다. 

The AH Header


먼저 AH header 에 대해서 알아보기로 하겠습니다. AH Header는 아래와 같은 형태로 되어 있습니다.

AH Header


제일 윗부분에 있는 Next Payload는 다음에 올 패킷이 어떤 패킷인지를 나타내고, Payload length 는 전체 Payload의 크기를 나타냅니다. (Reserved 필드는 현재는 정의되어 있지 않습니다.)

그리고 그 다음에 오는 것이 SPI인데, ESP 와 마찬가지로 Security Parameter Index값으로 AH 패킷이 수신되었을 경우 해당 패킷을 처리하기 이하여 사용되는 Security Association을 찾기 위해 사용되는 값입니다.  

그리고 Sequence number 는 순서대로 증가하는 값인데, 이것 또한 ESP와 같은 의미로 쓰이는데, 주로 anti replay 기능을 위하여 제공되는 것입니다. 

마지막으로 Authentication data는 무결성 Check 기능 (ex : HMAC-SHA-96, HMAC-MD5-96)에 의한 결과 값을 저장하는 필드로 이 값을 가지고 실제 들어온 패킷을 버려야 하는지 받아들여야 하는지를 판단하게 됩니다.   

Authentication Data을 만들 때 봐야 하는 것이 mutable fieldimmutable field인데, 영어 단어 의미와 마찬가지로 mutable field라는 것은 변하기 쉽다는 의미로, TOS, Flags, Fragment Offset, TTL Header Checksum 값이 여기에 해당됩니다. 이 값들은 패킷이 전달될 시에 주로 변하는 값들이기 때문에 Authentication data을 만들 때 0으로 처리되어 계산되는 값들입니다. 이와 반대로 immutable field 인 Version, Internet Header Length, Total Length, Identification, Protocol, Source Address, Destination Address는 패킷이 다른곳으로 전달되어도 값이 변하지 않기 때문에 Authentication Data 계산 시 포함되게 됩니다.

AH modes
 
AH mode도 ESP mode와 마찬가지로 Transport modeTunnel mode 이렇게 두 가지로 나뉘는데, 이 두 가지 방식의 차이는 아래 그림을 보면 좀 더 쉽게 이해 될 것입니다.

AH transport mode


먼저  이 그림은 Transport mode 입니다. AH도 ESP와 마찬가지로 IP 헤더 뒤에 삽입되는 구조로 되어 있습니다. 패킷 형태는 위 그림과 같이 구성되고 Authentication Data에는 위에서 설명한 immutable field 을 이용하여 만들게 됩니다. AH에서 쓰이는 인증은 ESP 와 달리 패킷 전체에 대한 인증 기능을 가지고 있다는 것이 ESP 와 다른 점입니다. 

AH Tunnel Mode는 아래 그림과 같은 형태로 되어 있습니다. AH Transport Mode 와 마찬가지 형태를 띠고 있는데, 다른 점이 있다면 New IP Hdr 가 붙어 터널링이 된다는 점입니다. 이 경우에도 Transport Mode 와 마찬가지로 전체 패킷에 대한 인증 값이 AH 들어 가게 됩니다.  

AH tunnel mode


AH Processing

여기서는 이제 실제 AH가 어떻게 동작되는지를 알아보겠습니다. 기본적으로 AH 동작도 ESP와 비슷한데, 다만 암호화를 하지 않고 IP packet에 대한 인증을 수행한다는 것이 다른 점입니다.

- Outbound Processing

1. Security Association Lookup : 모든 IPSec 프로세싱에서 가장 먼저 이루어지는 단계로 트래픽이 흐르기 전에 SA (Security Association) 가 양단간에 설정되는데, 트래픽이 들어왔을 경우 이 SA 가 존재하는지를 찾는 과정입니다.   

2. Sequence number generation : 처음 SA가 개설되면 Sequence number는 0로 셋팅되고 패킷 전송 후 1씩 증가합니다. Sequence number는 Cycle이 되지 않도록 하는 것이 일반적이며, Overflow가 될 경우 기존에 쓰던 SA를 삭제하고 새로 SA 를 개설하는 절차를 밟게됩니다. 하지만 Cycle 감시를 Disable 시킬 수도 있으며, 이 경우에는 SA 가 새로 개설 되지 않고, 계속 1 씩 증가하는 Sequence number을 가지고 패킷이 전송됩니다. 이 과정은 설명과 같이 ESP 와 같은 방법으로 동작합니다.

3. Integrity Check Value Calculation : 패킷이 들어오면 그 패킷의 immutable field 을 이용하여 Authentication Data을 만듭니다. 그렇게 하여 실제 들어온 패킷의 Authentication Data와 계산된 값이 같은지를 검사하는 과정인데, 다를 경우에는 들어온 패킷을 버리는 동작을 취합니다. 

4. Fragmentation : 일반적인 IP fragmentation 과 같은 과정으로, AH 에서 Fragmentation 이 필요하다면 먼저 AH Processing을 하고 난 후 Fragmentation을 합니다. 수신하는 쪽에서는 패킷이 들어왔을 경우 모두 재조립을 한후 AH Processing을 해야 문제가 없게 됩니다.  
   
- Inbound Processing

1. Reassembly : 앞서 Fragmentation 과정에서 설명하였듯이 이 과정은 AH Processing이 일어나기 전에 수행 되어야 합니다. 그래야 계산된 Authentication 값과 수신된 값이 일치하게 됩니다.

2. Security Association Lookup : 패킷이 재조립되면, 이 패킷을 처리하기 위해 어떤 알고리즘이 필요하고 Key 값은 어떻게 되고, Sequence Number는 체크를 해야하는지 와 같은 것들을 알아야 하는데, 이러한 정보를 가지고 있는 것이 SA (Security Association) 입니다. 그래서 SA 을 Lookup 하는 과정을 거쳐 SA가 찾아지면 다음 단계로 넘어가지만, 그렇지 않을 경우에는 패킷은 버려지게 됩니다.  

3. Sequence Number Verification :  이 과정도 ESP와 같은 과정으로, 수신단은 송신단과 마찬가지로 SA가 설립이 되면 Sequence number을 0로 셋팅하고 들어오는 패킷의 Sequence number을 감시합니다. 이 때 중복된 Sequence Number을 가진 패킷이 들어오면 버리게 되는데 윈도우 사이즈를 이용하여 그 안에 들어 왔는지 아닌지를 체크 하여 결정합니다. Anti-replay 기능을 위하여 사용됩니다.

4. Integrity Check Value Verification : 실제 Authentication Data값을 비교하는 부분으로 SA lookup 과정에서 찾아진 정보를 이용하여 들어온 패킷의 Authentication Data 값과 계산된 값을 비교하게 됩니다. 이 값이 틀리면 이 패킷은 버려지게 됩니다.   

이상으로 IPsec AH 에 대하여 알아 봤습니다.


'Network Security' 카테고리의 다른 글

IPsec AH  (1) 2011.04.12
IPsec ESP  (2) 2011.03.08
Network Security  (0) 2011.01.13
IPsec Action Type  (0) 2011.01.11
ISAKMP Exchange Type  (0) 2010.12.29
ISAKMP payload  (0) 2010.12.17
Trackback 0 | Comment 1
permalink
2017.04.15 00:34 댓글에 댓글수정/삭제
비밀댓글입니다




행복한하루's Blog is powered by Daum & tistory