어떤 것을 사용할 것인가?
구현할 EAP의 유형 또는 802.1x 구현할지 여부는 조직에서 요구하는 보안 수준과 필요한 관리 오버헤드/기능에 따라 다릅니다. 여기서 제공하는 설명 및 비교 차트를 통해 여러 가지 EAP 유형을 보다 쉽게 이해할 수 있습니다.

EAP (Extensible Authentication Protocol) 인증 유형
WLAN 보안은 필수적이며 EAP 인증 유형은 WLAN 연결의 보안을 강화하는 유용한 방법을 제공하므로 공급업체마다 자사의 WLAN 액세스 포인트 제품에 필요한 EAP 인증 유형을 빠르게 개발하고 있습니다. 가장 널리 사용되는 EAP 인증 유형으로는 EAP-MD-5, EAP-TLS, EAP-PEAP, EAP-TTLS,EAP-Fast 및 Cisco LEAP가 있습니다.

• EAP-MD-5(Message Digest) Challenge는 기본적인 수준의 EAP 지원을 제공하는 EAP 인증 유형입니다. EAP-MD-5는 사용자 암호를 알아낼 수 있으므로 일반적으로 무선 LAN 구현에는 권장되지 않습니다. 이 인증 유형은 실제로는 무선 클라이언트와 네트워크에 대한 상호 인증 단계가 없으므로 단방향 인증만 제공합니다. 또한 동적인 세션 기반 WEP(Wired Equivalent Privacy) 키를 알아낼 수 있는 방법을 제공하지 않는다는 점에서 매우 중요한 인증 유형 중 하나입니다.
  
• EAP-TLS(Transport Layer Security)는 클라이언트 및 네트워크에 대한 인증서 기반 상호 인증 기능을 제공합니다. 이 방법은 클라이언트측 인증서와 서버측 인증서를 통해 인증을 수행하며 WLAN 클라이언트와 액세스 포인트 간 후속 통신에 대한 보안을 강화하기 위해 사용자 기본 WEP 키 및 세션 기반 WEP 키를 동적으로 생성합니다. EAP-TLS의 한 가지 단점은 클라이언트측과 서버측 모두에서 인증서를 관리해야 한다는 점입니다. 이는 규모가 큰 WLAN을 설치하는 경우 번거로운 작업이 될 수 있습니다.
  
• EAP-TTLS(Tunneled Transport Layer Security)는 Funk Software와 Certicom이 EAP-TLS를 보강하여 개발한 방법입니다. 이 보안 방법은 암호화된 채널(또는 "터널")을 통해 클라이언트와 네트워크에 대한 인증서 기반 상호 인증 및 동적인 사용자 또는 세션 기반 WEP 키를 생성할 수 있는 방법을 제공합니다. EAP-TLS와 달리 EAP-TTLS에는 서버측 인증서만 있으면 됩니다.
  
• EAP-FAST(Flexible Authentication via Secure Tunneling)는 Cisco에서 개발한 것으로, 인증서를 사용하는 대신 인증 서버에서 동적으로 관리할 수 있는 PAC(보호 액세스 자격 증명) 방식으로 상호 인증이 구현됩니다. PAC는 수동 또는 자동으로 클라이언트에게 제공할 수 있습니다(한 번에 배포 가능). 수동으로 제공하는 경우 디스크나 보안된 네트워크 배포 방법을 통해 클라이언트에게 전달되며 자동으로 제공하는 경우에는 대역 내에서 또는 무선으로 배포됩니다.
  
• LEAP(Lightweight Extensible Authentication Protocol)는 주로 Cisco Aironet WLAN에서 사용하는 EAP 인증 유형으로, 동적으로 생성된 WEP 키를 사용하여 전송 데이터를 암호화하며 상호 인증을 지원합니다. 지금까지 소유주인 Cisco가 Cisco 호환 확장 프로그램을 통해 여러 제조업체에 LEAP 사용을 허가해 왔습니댜.
  
• PEAP(Protected Extensible Authentication Protocol)는 레거시 암호 기반 프로토콜과 같은 인증 데이터를 802.11 무선 네트워크를 통해 안전하게 전송할 수 있는 방법을 제공합니다. PEAP는 PEAP 클라이언트와 인증 서버 간 터널링을 사용하여 이 기능을 수행합니다. PEAP는 유사한 기능을 수행하는 TTLS( Tunneled Transport Layer Security)와 같이 서버측 인증서만을 사용하여 보안 무선 LAN의 구현 및 관리를 간소화함으로써 무선 LAN 클라이언트를 인증합니다. PEAP는 Microsoft, Cisco 및 RSA Security에서 개발한 방법입니다.

• MD5는 단방향 인증만을 수행하며 무엇보다 WEP 키의 자동 배포 및 순환을 지원하지 않아 수동 WEP 키 유지보수의 관리 부담을 줄일 수 없으므로 잘 사용되지 않습니다.
• TLS의 경우 보안 기능은 뛰어나지만 각 무선 워크스테이션에 클라이언트 인증서를 설치해야 합니다. PKI 인프라를 관리하려면 WLAN 자체에 대한 관리 외에 추가 관리 전문 기술과 시간이 필요합니다.
• TTLS는 TLS를 터널링하여 클라이언트측 인증서에 대한 요구를 없앰으로써 인증서 문제를 해결합니다. 이 방법이 주로 사용됩니다. TTLS는 주로 Funk에서 관리하며 요청자 및 인증 서버 소프트웨어에 대한 대가를 별도로 지불해야 합니다.
• LEAP는 가장 먼저 개발된 것으로, 과거에는 Cisco에게 소유권이 있었으며(Cisco 무선 어댑터와 함께 사용해야 함) Cisco는 Cisco 호환 확장 프로그램을 통해 여러 제조업체에게 LEAP 사용을 허가해 왔습니다. LEAP를 인증에 사용하는 경우에는 강력한 암호 정책을 설정해야 합니다.
• 이제 강력한 암호 정책을 설정하거나 인증에 대한 인증서 구축을 원하지 않는 기업의 경우 EAP-FAST를 사용할 수 있습니다.
• 가장 최근에 개발된 PEAP 방법은 클라이언트측에 대한 인증서가 필요하지 않다는 점에서 EAP-TTLS 방법과 유사합니다. PEAP는 Cisco 및 Microsoft에서 지원하는 방법으로, Microsoft에 추가 비용을 지불하지 않고 사용이 가능합니다. LEAP에서 PEAP로 데이터를 전송하려는 경우 Cisco의 ACS 인증 서버가 두 방법을 모두 실행합니다.

데이터 개인 정보 보호
데이터 개인 정보 보호는 데이터를 전송하기 전에 암호화한 다음 수신 종단에서 암호를 해독(일반 데이터 복구)하는 자격 증명 키를 사용하여 구현됩니다. WEP(Wired Equivalent Privacy)는 상대적으로 보안 기능이 취약합니다. 따라서 무선 데이터의 보호 효과를 높이기 위해 WPA, WPA2 등과 같은 다른 방법이 개발되었습니다.

WPA*(Wi-Fi* Protected Access)
Wi-Fi Alliance는 802.11i 수정 사항을 충족하는 보다 강력한 무선 LAN 보안 솔루션을 개발하려는 노력의 일환으로 이 표준 기반 솔루션을 2003년 후반에 도입하였습니다. WPA에는 802.1x 인증 및 TKIP 암호화가 포함됩니다(WEP 암호화보다 강화된 보안 방식).

WPA2*(Wi-Fi* Protected Access 2)
Wi-Fi Alliance는 2004년 말 차세대 WPA 보안 솔루션을 발표했습니다. WPA와 같이 WPA2에도 802.1x 인증이 포함됩니다. 802.11i 개정에 따라 WPA2는 AES(Advanced Encryption Standard)를 사용하여 데이터 개인 정보를 보호합니다.

WPA Personal 및 WPA2 Personal
인증 서버가 없는 소규모 사무실이나 가정에서는 PSK(Pre-Shared Key)의 사용을 통해 액세스에 대한 인증이 결정됩니다. 사전 공유 키는 16진수 문자열이거나 암호문으로, 액세스 포인트와 모든 클라이언트 간에 일치해아 합니다. WPA 개인 또는 WPA2 개인 방법을 사용할 때는 802.1x 보안을 사용할 수 없습니다.

기타 보안 옵션

VPN
인증 및 개인 정보 보호(암호화)에 무선 LAN을 사용하는 대신 대부분의 기업에서 VPN을 구현하고 있습니다. 즉, 기업 방화벽 외부에 액세스 포인트를 설치하고 사용자가 원격 사용자인 것처럼 VPN 게이트웨이를 통해 통신하도록 하는 것입니다. VPN 솔루션 구현 방법의 단점은 비용이 많이 소요되고 초기 설치 과정이 복잡하며 지속적인 관리 부담을 고려해야 한다는 점입니다.

하나하나, 실전에서 쓰이는 내용 위주로 쓰여진것 같은데

받아서 읽어 봐야 알수 있을것 같다.

실용서여서 두고두고 봐야할책은 아닌것 같지만,

한번은 읽어서 해당 내용을 숙지하여야 시스템 release할때

도움을 많이 받을 것이다. (지금 제대로 하고 있나를 확인하는 계기도 되고)

만약 당신도 이 이벤트에 참가 하고 싶으면,

http://www.talk-with-hani.com/archives/706 를 눌러라.

그러면 안내해줄꺼다.

대개 메모리 접근 위반(Segmentation Violation)으로 생성되는 것이 대부분인데, 솔라리스의 애플리케이션에 포인터 처리가 미숙했거나, 솔라리스가 허용하는 데이타 패싱이 아니었거나 솔라리스에서 허용하는 프로토타입과 상이하게 다르거나 하는 경우에 흔히 생깁니다.

일단 core 화일이 생기게 되면, 해당 애플리케이션의 current directory에 생성됩니다. 대게 많은 애플리케이션들이 홈에서 시작이 되므로, 혹은 홈으로 현재 디렉토리를 옮기게 되므로 홈 디렉토리에 core가 왕왕 생기는 것을 볼 수가 있습니다. 또한, 솔라리스 내장되어 있는 각종 패키지들(gnome)과 같은 데스크 탑 솔루션등도 시작할때 홈에서 시작하므로 버그가 있는 경우 홈에서 core를 많이 볼 수가 있습니다.

core가 생기면 어떤 화일이 어디에서 문제가 생겨서 죽었는 지를 다음과 같이 해서 알 수 있습니다.

#file core
core: ELF 32-bit MSB core file SPARC Version 1, from 'thunderbird-bin'

#pstack core

core 'core' of 3968: /opt/sfw/lib/thunderbird/thunderbird-bin
----------------- lwp# 1 / thread# 1 --------------------
ff3416e0 _lwp_kill (b, ffbfe4b0, 0, b, fc00, 1) + 8
0051086c ???????? (b, 0, 510748, 510400, a, c4)
ff340618 __sighndlr (b, 0, ffbfe620, 510784, 0, 1) + c
ff335710 call_user_handler (b, ffbffeff, 0, 0, fe2b2000, ffbfe620) + 3b8
010b4794 ???????? (6e6e800, ff0a49bc, 24002400, 28002800, 28002800, 6e6e800)
010b5b44 ???????? (6cf5090, 63636c8, ff000000, 0, 80000000, ff0a39e4)
ff0a6fc0 __1cYnsOutputStreamReadyEventMEventHandler6FpnHPLEvent__pv_ (6c6fa74,
6c6faa8, 6c6fa70, 6cf5090, 10b5ab8, 18d79a0) + 34
ff0c03a0 PL_HandleEvent (6c6fa74, 1985454, ff0a6f8c, 1985454, 1985450, 6c6fa74) + 14
ff0c02b8 PL_ProcessPendingEvents (12, 1, d, 0, 0, 1985450) + 7c
ff0c23cc __1cQnsEventQdDueueImplUProcessPendingEvents6M_I_ (196dd08, 80004000,
ff000000, 0, 0, 1aef090) + 20
0072b840 ???????? (1af2f38, 1, 196dd08, 1, 1, ff0c23ac)
fea55ac8 g_main_dispatch (196e898, feabec00, 0, 0, fffffffd, ffffffef) + 19c
fea56ffc g_main_context_dispatch (196e898, c8, 0, 1, feabec00, 196e898) + 9c
fea574c8 g_main_context_iterate (1, 1, 1, 196e898, 196e8a0, 9) + 454
fea57c44 g_main_loop_run (1b99fe0, feabec00, ff339c58, 199a2f8, feaaa800, feaaa800) + 348
fee2a424 gtk_main (0, 0, 1b99fe0, 1aa4500, feff1eb0, 4ce0) + d0
0072bba4 ???????? (1aa6ac8, 196dd08, 18332d4, 72bbc0, c1f30000, 0)
....

위의 core는 thunderbird-bin이 생성한 것임을 알 수가 있습니다.
위의 core는 불행하게도 두가지 문제가 있는데, 하나는 debugging symbol을 가지고 있지 않는 함수가 있다는 것이고, 하나는 C++에 의한 맹글링으로 인해 함수 이름을 알아보기 어렵다는 점이 있습니다.

일단, C++ mangling 문제는 다음과 같이 함으로써 해결할 수 있습니다.

$pstack core | /opt/SUNWspro/bin/c++filt | less
core 'core' of 3968: /opt/sfw/lib/thunderbird/thunderbird-bin
----------------- lwp# 1 / thread# 1 --------------------
ff3416e0 _lwp_kill (b, ffbfe4b0, 0, b, fc00, 1) + 8
0051086c ???????? (b, 0, 510748, 510400, a, c4)
ff340618 __sighndlr (b, 0, ffbfe620, 510784, 0, 1) + c
ff335710 call_user_handler (b, ffbffeff, 0, 0, fe2b2000, ffbfe620) + 3b8
010b4794 ???????? (6e6e800, ff0a49bc, 24002400, 28002800, 28002800, 6e6e800)
010b5b44 ???????? (6cf5090, 63636c8, ff000000, 0, 80000000, ff0a39e4)
ff0a6fc0 void*nsOutputStreamReadyEvent::EventHandler(PLEvent*) (6c6fa74, 6c6faa8, 6c6fa70, 6cf5090, 10b5ab8, 18d79a0) + 34
ff0c03a0 PL_HandleEvent (6c6fa74, 1985454, ff0a6f8c, 1985454, 1985450, 6c6fa74) + 14
ff0c02b8 PL_ProcessPendingEvents (12, 1, d, 0, 0, 1985450) + 7c
ff0c23cc unsigned nsEventQueueImpl::ProcessPendingEvents() (196dd08, 80004000,
ff000000, 0, 0, 1aef090) + 20
0072b840 ???????? (1af2f38, 1, 196dd08, 1, 1, ff0c23ac)
fea55ac8 g_main_dispatch (196e898, feabec00, 0, 0, fffffffd, ffffffef) + 19c
fea56ffc g_main_context_dispatch (196e898, c8, 0, 1, feabec00, 196e898) + 9c
fea574c8 g_main_context_iterate (1, 1, 1, 196e898, 196e8a0, 9) + 454
fea57c44 g_main_loop_run (1b99fe0, feabec00, ff339c58, 199a2f8, feaaa800, feaaa800) + 348
fee2a424 gtk_main (0, 0, 1b99fe0, 1aa4500, feff1eb0, 4ce0) + d0
0072bba4 ???????? (1aa6ac8, 196dd08, 18332d4, 72bbc0, c1f30000, 0)
....

c++filt는 썬 스튜디오를 설치하면 따라오는 유틸리티입니다.
기본적으로 /usr/ccs/bin/nm도 디맹글링을 지원합니다만 사용 환경이 다릅니다.

위에서 발생한 core는 thunderbird-bin이 링크하는 동적 라이브러리에서 출력 스트림 이벤트 핸들러에서 발생한 문제임을 알수가 있습니다. 어느 라이브러리에서 발생했는지 알기 위해서는 커널 디버거인 mdb를 사용해야 합니다.

> mdb core
Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
> $C
ffbfe3f0 libc.so.1`_lwp_kill+8(b, ffbfe4b0, 0, b, fc00, 1)

ffbfe450 0x51086c(b, 0, 510748, 510400, a, c4)
ffbfe4c0 libc.so.1`__sighndlr+0xc(b, 0, ffbfe620, 510784, 0, 1)
ffbfe520 libc.so.1`call_user_handler+0x3b8(b, ffbffeff, 0, 0, fe2b2000, ffbfe620)
ffbfe8d8 0x10b4794(6e6e800, ff0a49bc, 24002400, 28002800, 28002800, 6e6e800)
ffbfe940 0x10b5b44(6cf5090, 63636c8, ff000000, 0, 80000000, ff0a39e4)
ffbfe9a8
libxpcom_core.so`__1cYnsOutputStreamReadyEventMEventHandler6FpnHPLEvent__pv_+0x34(6c6fa74, 6c6faa8, 6c6fa70, 6cf5090, 10b5ab8, 18d79a0)
ffbfea08 libxpcom_core.so`PL_HandleEvent+0x14(6c6fa74, 1985454, ff0a6f8c,
1985454, 1985450, 6c6fa74)
ffbfea68 libxpcom_core.so`PL_ProcessPendingEvents+0x7c(12, 1, d, 0, 0, 1985450)
ffbfeac8 libxpcom_core.so`__1cQnsEventQdDueueImplUProcessPendingEvents6M_I_+0x20(196dd08, 80004000, ff000000, 0, 0, 1aef090)
ffbfeb30 0x72b840(1af2f38, 1, 196dd08, 1, 1, ff0c23ac)
ffbfeb90 libglib-2.0.so.0.400.1`g_main_dispatch+0x19c(196e898, feabec00, 0, 0,
fffffffd, ffffffef)
ffbfebf8 libglib-2.0.so.0.400.1`g_main_context_dispatch+0x9c(196e898, c8, 0, 1,
feabec00, 196e898)
....

위에서 $C 명령어는 core가 유도된 스레드의 스택을 보여줍니다.
장애의 소스가 되는 관심있는 함수와 모듈을 알수 있습니다.
libxpcom_core.so를 확인하게 되면 앞서 보았던, void*nsOutputStreamReadyEvent::EventHandler(PLEvent*)
임을 알 수 있기 때문입니다. 따라서, 개발자들은 이 함수의 소스를 확인해야 합니다.

지금부터는 이 함수의 어느 부분이 문제인지 확인하기 위해서는 소스 디버거나 dtrace를 사용해야만 하겠죠.

그러나, 경험적으로 core의 몇가지 정보를 더 얻을 수 있다면, 문제가 무엇인지 직감하는데 도움이
되는 경우도 있습니다.

예를 들면, 해당 core가 어떤 크리덴셜(퍼미션)을 가지고 실행했는가 ?
해당 코어는 어떤 환경에서 실행되었는가등을 알면 매우 큰 도움이 되는 경우가 있습니다.
다음과 같은 유틸리티를 통해서 알수가 있습니다.

#pargs -e core
#pldd core
#pcred core

1. Layer 2 Tunneling (L2T)

- VPN에서 가장 보편적인 형태로 네트워크 프로토콜(IP, IPX)를

PPP에 캡슐화한 다음 그 패킷을 다시 터널링 프로토콜로 갭슐화 하는 방법

2. Layer 3 Tunneling (L3T)

- 네트워크 프로토콜을 직접 터널링 프로토콜로 캡슐화하는 방법

방법

1. 클라이언트가 터널을 설정하는 방법

- 클라이언트 자신이 터널 생성하여 상대 장비와 사용자 ID와 패스워드를 전달하여 사용자 인증을 수행

2. 네트워크 서버가 터널을 설정하는 방법

- 네트워크 서버는 망제공자가 제공하는 인증 서버에 사용자 ID를 전송하여

사용자를 인증하고 원하는 네트워크 서버의 위치를 알아 내고 해당 터널 서버(터널 종단점)까지의 터널을 설정

클라이언트와 해당 네트워크 서버와 다시 사용자 인증을 수행한다.

이점은 클라이언트가 터널링 소프트웨어를 설치하지 않아도 된다는 장점이 있다.

그러나, mobility의 모든 문제를 해결할 수는 없다.

예를 들면,만약 bandwidth를 많이 차지하는 application이 high-speed WLAN network에서 low-bandwidth GPRS network으로 이동을 하면, TCP connections은 GPRS network의 높은 latency로 존재할수는 없을것이다. 이것을 풀려면, 만약 application이 다양한 Qos를 지원하도록 디자인 되면 가능하다.

만약 TCP/IP stack의 모든 layer가 collaborate하면 사실 mobility는 단지 이룰수 있을것 이다.

mobile ip만이 mobility를 해결할수는 없다... ????

2005년 ( Inside Mobile IP 발췌 - Narendra Venkataraman )

단순히 network쪽만 변경하여 Mobility를 제공하길 바라고 있다.

그래서 Proxy Mobile IP란 스펙이 탄생하게 된다.

기능은 단순하게 보면, Mobile IP는 단말기에서 Mobility 기능을 수행하지만, Proxy Mobile IP는 Network상에서 Router간혹은 Access Router간의 Mobility를 지원하게 된다.

그래서, Mobile IP는 Global Mobility를 지원하지만, Proxy Mobile IP는 Local Mobility를 지원한다. Proxy Mobile IP를 지원하는 구간에서만 Mobility를 지원하는 것이다.

왜 이런 안을 내 놓았을까... ? 물론 서두에 말했듯이 서비스를 제공하는 사업자들이 Mobile IP를 가지고 사업적으로 아직은 수익을 낼 수 있다고 생각을 하지 않고 있어, 기술 spec은 이미 다 정해 놓고 아직 실제로 상용망에서 운용하지는 못하고 있다.

그렇게 되니까, Mobile IP가 너무 무거운 기술이 아니냐는 지적도 나오고 있다. (실제로 단말기에 Mobile IP Spec을 넣기에는 CPU Power가 아직까지는 힘들고, Air구간에서는 Packet을 최소한 작게 해야 하는데, Tunnel이라는 큰 Packet이 문제이다.)

Proxy Mobile IP (PMIP) 은 정반합에 의거하여 중간정도의 Spec이라고 보면 좋을것 같으나 해결해야 될 숙제들은 많은것으로 보인다.

Proxy Mobile IP는 현재 풀어야 될 문제들은

- Handover(HO) latency가 아직은 길게 나타난다. ( 얼마나 긴지는 아직 정확한 데이터는 모름)

- Proxy Mobile IP Domain내에서는 Mobility를 할수 있다.

- Route Optimization이 필요하다.

- IPv4 Support

- NeMo support

===

후기 : 지금 Cisco와 Nokia가 해당 PMIP을 정식 표준을 만들기 위한 지원을 많이 하고 있고, 3GPP, 3GPP2와 WiMAX의 operators들도 전폭적인 지지를 하고 있다. 아마 PMIP이 operator, 서비스 사업자, network 장비 업체에게 많이 이득을 만들고 있는것 같다.