출처 - 아이월드 네트워킹 기술지원팀(coffeenix.net/doc/network/SMB_ICMP_UDP(huichang).pdf)

NetBIOS 네임 서버 프로토콜(NBNS 프로토콜)은 NBT(NetBIOS over TCP/IP)계열의 일부로 윈도우 시스템에서는 WINS(Windows Internet Name Service)로 구현되어 있습니다. 설계상으로는 NBNS는 네트워크에 연결된 다른 컴퓨터들 상호간의 이름이 충돌되지 않도록 도와 주는 역할을 하게 됩니다. 

또한, 이 프로토콜은 네트워크 인증을 받지 않도록 설계되어 있기 때문에 스푸핑(spoofing)에 노출되어 있습니다. 따라서 악의적인 사용자가 이름 충돌(Name Conflict)이나 이름 해제(Name Release) 메커니즘을 엉뚱하게 사용하게 되면 네트워크상에서 존재하는 다른 컴퓨터는 현재 등록된 이름이 다른 컴퓨터와 충돌을 야기하는 것처럼 보이는 결과를 가져올 수 있습니다. 이러한 시나리오에 따라 해당 컴퓨터는 현재 사용하고 있는 이름을 네트워크에 등록하지 못하거나 등록된 이름을 사용하지 못하게 됩니다. 두 가지 경우 모두 같은 해당 컴퓨터가 이름 충돌과 관계된 메시지에 대해서 응답하지 않는 결과를 초래합니다.

일반적인 보안 기법으로 UDP 137번 포트를 방화벽에서 막아 버리면 외부에서 공격하는 것은 불가능해집니다. 또한 이 문제에 대해 제공되는 패치는 시스템 관리자들이 네트워크 유지에 추가적인 유연성을 확보하는 방향으로 윈도우 시스템의 동작 방법을 변경하였습니다. 

패치는 관리자들이 컴퓨터의 이름 충돌과 관계된 데이터그램을 오로지 이름 등록을 시도하는 경우에만 받을 수 있도록 설정할 수 있도록 하였으며, 또한 모든 이름 해제 데이터그램을 받지 못하도록 설정할 수 있습니다. 그러나, 이것은 스푸핑을 완전히 제거하는 것은 아니며 단지 가능성을 낮추는 것 뿐입니다. 추가적인 보안 설정을 고려하고 계신 고객들은 137-139번 포트의 모든 세션을 확인하기 위하여 Windows 2000의 IPSec를 사용하는 것을 고려해 보시기 바랍니다

http://www.microsoft.com/korea/technet/security/bulletin/ms00-047.mspx

출처 : MS Technet

아래는 wireshark wiki에서 발췌한 NBNS에 대한 정의.

This service is often called WINS on Windows systems.

The NetBIOS Name Service is part of the NetBIOS-over-TCP protocol suite, see the NetBIOS page for further information.

NBNS serves much the same purpose as DNS does: translate human-readable names to IP addresses (e.g. www.wireshark.org to 65.208.228.223). (As NetBIOS can run on top of several different network protocols (e.g. IP, IPX, ...), other implementations of the NetBIOS services have their own mechanisms for translating NetBIOS names to addresses.) NBNS's services are more limited, in that NetBIOS names exist in a flat name space, rather than DNS's hierarchical one (multiple flat name spaces can exist, by using NetBIOS scopes, but those are rarely used), and NBNS can only supply IPv4 addresses; NBNS doesn't support IPv6.

With the advent of SMB-over-TCP, it is no longer necessary to have a machine's NetBIOS name in order for that machine to make connections to SMB servers or in order for SMB connections to be made to that machine, and with the advent of "dynamic DNS", a host can register its name and its IP address or addresses with a DNS server when it boots (note that its IP address might not be static - it might be granted by a DHCP server - so you can't necessarily statically register a machine's host name and IP address with a DNS server). 

Therefore, newer Windows systems, starting with Windows 2000, can use DNS for all the purposes for which NBNS was used. NBNS is still widely used especially on Windows networks, as there might still be older versions of Windows on those networks, or it might not yet have been converted to use only DNS.

WINS (Windows Internet Name Service) uses the same protocol, but unicast messages to a WINS-Server, multiple WINS servers can replicate the content with the WINS-Replication protocol.

아래는 유효한 NBNS 필터

http://hwaddress.com/

수신자 : nc -l -p [Listen Port] > [Receive File Name]

송신자 : [cat|type] [Send File Name] | nc -w [Timeout(sec)] [Receiver IP] [Receiver Port]

IPSec (Internet Protocol Security protocol)

IPSec은 네트워크나 네트워크 통신의 패킷 처리 계층에서의 보안을 위해, 지금도 발전되고 있는 표준이다. 이전의 보안 기법들에서는 보안이 통신 모델의 응용 계층에 삽입되었었다. IPSec은 가상 사설망과 사설망에 다이얼업 접속을 통한 원격 사용자 접속의 구현에 특히 유용할 것이다. 

IPSec의 커다란 장점은 개별 사용자 컴퓨터의 변경 없이도 보안에 관한 준비가 처리될 수 있다는 것이다. 시스코는 IPSec를 표준으로 제안하는데 선두주자였으며, 자신들의 네트워크 라우터에 이 기능의 지원을 포함하였다. 

IPSec은, 본질적으로 데이터 송신자의 인증을 허용하는 인증 헤더 (AH)와, 송신자의 인증 및 데이터 암호화를 함께 지원하는 ESP (Encapsulating Security Payload) 등, 두 종류의 보안 서비스를 제공한다. 이러한 각 서비스에 관련된 명확한 정보는 IP 패킷 헤더의 뒤를 잇는, 헤더 속의 패킷에 삽입된다. ISAKMP/Oakley 프로토콜과 같은 별개의 키 프로토콜들이 선택될 수 있다. 

AH·ESP 프로토콜로 구성, 각각 패킷 인증·비밀 보호

네트워킹 산업이 어느정도의 관심 대상이 되느냐는 곧 보안과 사생활 보호의 관심사항과 직결된다. 따라서 담당기관인 IETF는 IP 보안 프로토콜인 IPSec을 끊임없이 발전시키기 위해 분주한 노력을 펼치고 있다. IPSec은 인터넷상에 있는 시스템과 네트워크간에 안전하고 사적인 대화를 가능하게 한다.

전용prorietary 시스템에도 이기종 시스템과 네트워크 사이에서 발생하는 문제를 해결하기 위한 노력이 꾸준히 보강되고는 있지만 그래도 한 업체 전용이라는 사실은 어쩔 수 없다.

IPSec을 채택하면 관련된 네트워크의 특수 사양에 관계없이 사적인 이해집단communiry of interest을 만들 수 있다. 여기서는 IPSec을 구성하는 기술을 각각 속속들이 살펴봄으로써 IPSec 기술에 대한 독자들의 이해를 돕고자 한다.

1. IPSec 프로토콜

IPSec은 인증 헤더(AH : Authentic-ation Header)와 캡슐 보안 페이로드(ESP : Encapsulating Security Pay-laod) 등 2개의 프로토콜로 구성돼 있다. AH 프로토콜은 무결성과 데이터 기원 인증 및 재생replay에 대항한 보호를 제공하는 봉함envelope을 만든다. 따라서 AH는 침입자의 공격에 대항한 다양한 방어책을 제공한다. 이 프로토콜은 모든 패킷을 인증하기 때문에 세션을 도용하는 프로그램은 비효율적으로 간주된다. 또한 이 프로토콜의 기본적인 재생 카운터는 가짜 혹은 파괴성 데이터가 포함되어 있을 수도 있는 재생 공격을 중지시킬 수 있다.

AH는 또한 가능한 한 다수의 IP 헤더에 대한 인증을 제공하는데, 심지어 IP 헤더가 AH 봉함 외부에 있을 때도 그렇다. AH 인증은 IP 헤터 패킷이 전송중일 때 그에 대한 조작을 불가능하게 만든다. 따라서 AH의 이러한 특성은 NAT (Network Address Translation) 종단간 환경에서의 사용을 부적절하게 만든다. IP 헤더를 조작하는 것이 NAT 기능에서는 필수적이기 때문이다.

ESP 프로토콜은 데이터의 비밀성privacy을 제공하는데, 암호화되어 있지만 인증되지 않은 데이터 스트림에 대한 공격을 막기 위해 AH의 모든 기능이 포함돼 있다. IPSec 사양은 AH 기능을 제외한 ESP를 허용하고 있지만, 하고 있는 일에 대해 정확히 이해하지 못한다면 이것을 사용하지 말 것을 권장한다. ESP는 또한 널null 암호화를 사용할 수 있다. 널 암호화란 IP 헤더 인증을 제외한 AH와 거의 흡사한데, IP 헤더에서의 주소가 변하기 때문에 NAT 전송을 허용할 수 있다.

ESP와 AH는 IANA(Internet Addr-ess Naming Authority)에 의해 프로토콜 50과 51로 각각 등록돼 있다. 사용자의 경계border 라우터에 기본적인 패킷 필터링 규칙이 구현돼 있다면 이들 프로토콜을 가용 목록에 추가할 필요가 있을 것이다. IP 헤더의 이러한 프로토콜 유형의 필드는 현재 IPSec 봉함의 필드이기도 하므로 원래의 전송 유형은 IPSec 헤더내에서 다음 프로토콜 필드로 이동된다.

IPSec 프로토콜은 전송 모드나 터널 모드에서 모두 사용될 수 있다. 전송 모드에서 IPSec은 네트웍(IP)와 전송(TCP 혹은 UDP) 봉함간의 평범한 IP 패킷으로 진입한다. 전송 모드는 종단 시스템용으로 개발되었는데, 그 사용은 완전히 집단에 속한 모든 시스템에서의 전개용으로 서술되어 있기 때문에 대부분의 경우 애플리케이션의 재 프로그래밍이 필요할 것이다.

IPSec의 터널 모드는 게이트웨이에 의해 사용되도록 개발된 것이다. 터널 모드에서 일상적인 IP 패킷은 IPSec 봉함내에 놓여지며 그 IPSec은 다시 또다른 IP 봉함으로 들어간다. 이 모드에서 사용자는 네트웍의 페러미터에서 IPSec 터널 장비를 신속하게 전개할 수 있다. 구성이 비슷한 네트웍간에 트래픽의 안전을 보장하는 것은 간단하며, 특수한 최종사용자 소프트웨어나 새 애플리케이션을 전개할 필요가 없다. 터널 모드를 지원하는 소프트웨어는 게이트웨이나 종단 시스템상에서 동작할 수 있다.

종단 시스템상에서 터널 소프트웨어가 가장 흔하게 사용될 때는 원격 및 이동 사용자를 지원할 때이다. 게이트웨이가 터널을 통해 대부분의 종단 사용자 데이터를 전송함에도 불구하고 동료 게이트웨이간의 통신을 안전하게 보호하려면 전송 모드를 사용할 수도 있다. 이러한 방식은 라우터, ATM 스위치, 방화벽 및 기타 핵심적인 하부구조 컴포넌트를 원격에서 안전하게 관리하는 훌륭한 방편이 될 수 있다.

IPSec 연결은 SA(Security Associa-tion)에 의해 규정된다. SA는 미리 방향이 지정된 것이 아니므로 연결시 2개의 SA가 필요하다. SA는 IPSec 연결의 다양한 패러미터를 정의하는데, 예를 들어 암호화와 인증 알고리즘과 같이 통신 시스템과 암호화용의 세션 키 및 스스로의 기능을 제어하는 다양한 패러미터간에 사용되는 것을 들 수 있다.

2. IPSec 알고리즘

앞서 언급했듯이 IPSec은 그 내부에서 인증 및 암호화 알고리즘을 사용하는 프로토콜로 구성된 것이다. 2개의 인증 및 7개의 알고리즘은 날짜를 규정하는데 사용되고 있다. AH와 ESP에 의해 사용되는 인증 알고리즘은 HMAC-MD5와 HMAC-SHA1이다. 이들은 세션 참여자가 한 개의 비밀 키(MD용은 128비트로 RFC 1321인 Message Digest 5 버전, SHA1용은 160비트로, FIPS 180-1인 Secure Hash Algo-rithm 1 버전)를 공유하는 키 기반의 인증 알고리즘이다. HMAC 절차는 RFC 204(메시지 인증 코드를 위한 키 해싱Keyed-Hashing)에 정의되어 있다.

HMAC는 비밀 키 인증 알고리즘이다. HMAC와 마찬가지로 비밀 키 분배의 영역에 따라 데이터 무결성과 데이터 기원 인증이 결정된다. 소스와 목적지만 HMAC 키만 알고 있다면 두 개의 패리티간에 전송된 패킷을 위해 데이터 기원 인증과 데이터 무결성을 제공한다. HMAC용의 키들은 ISAKMP /Oakley에 의해 생성된 키 재료keying material로부터 생성된다.

분명한 IV(initialization vector)가 수반된 DES(Data Encryption Standard)는 ESP에서 사용되는 기본적인 암호화 알고리즘이다. IPSec 호환을 위해 이 알고리즘을 구현해야 한다. 이외에도 Triple DES, CAST-128, RC5, IDEA, Blowfish 및 ARCFour(Bruce Scheier가 저술한 암호관련서적을 토대하여 RC4를 공개적으로 구현한 것) 등 DES의 대안으로 제시된 다양한 사양들이 있다.

CAST(RFC 2144)는 64비트 형식에서는 최소한 DES만큼, 128비트 형식에서는 Triple DES만큼 강력하다고 많은 사람들에 의해 주장되는 양식으로, DES보다 빠르다. RC5(RFC 2040)는 많은 사람들이 키 길이Ley length만큼 강격하다고 주장하는 키 길이가 가변적인 스트림으로서, 256비트까지 가능하다.

IDEA는 오리지널 PGP 프로그램에서 사용되는 것으로 그 속도가 빠른 것으로 알려져 있으며, Triple DES와 맞먹는 사이퍼cypher이다. 블로피시는 Scheier에 의해 개발된 가변적 길이의 사이퍼로서 공격자를 쉬지 못하게 만들기 위해 고안된 것이다.

DES 이외의 알고리즘을 선택하는 것이 구현자에 달렸다. 암호화 알고리즘을 선택하게 되면 여러 가지 이점이 있다. 잠재적인 공격자는 단순히 사이퍼를 공격하면 되는 것이 아니라 어떤 사이퍼를 깨뜨리고자 할 것인지도 결정해야 한다. 이는 사이퍼 키의 전환rotation로 함께 단순히 한물 간 데이터를 해독할 수 있다는 희망 이외에는 공격자들이 건질 것이 없게 만든다.

--

출처-출처불분명

DHCP에 대한 간단정리

DNS랑 같이 짤막지식에 올리려했지만..짧지도않고..길지도않아서 ㅋㅋㅋ

DHCP란 Dynamic Host Configuration Protocol의 약자로 동적으로 IP를 관리 및 할당해주는 것을 의미한다

그리고 그 DHCP를 사용하는 서버를 DHCP 서버라고 한다.

아래는 DHCP의 프로세스를 간단히 그림으로 나타낸 것이다. 함부로 퍼가지 말자. 제발. 그림판으로 무려 15분동안 그린것이다.

얘기가 빗나감. 여튼 프로세스를 설명하자면 이러하다.

먼저 사용자가 네트워크에 브로드 캐스트로 DHCP discover 패킷을 보낸다. 이는 자신이 아이피 할당이 필요하다는 것을 알리는 패킷이다.

dhcp 서버가 패킷을 받으면 여유로운 ip중 하나를 DHCP offer 패킷을 통해 (unicast)사용자에게 보낸다

그럼 사용자는 ip에 대한 사용을 요청하는 DHCP Requst 패킷을 네트워크에게 보낸다.

서버가 패킷을 받으면 DHCP ACK. 패킷을 보낸다. 이 패킷을 보냄으로써 IP를 사용해도 된다고 승인이 되는것이다.

이 과정 이후로는 사용자가 뭔 짓을 하든 여튼 해당 IP를 사용해서 통신이 가능해진다.

그렇게 구조적으로 파고들진 않고 DNS란게 무엇인지만 간단히 서술.

대략 보는것과 같이 이런 방식..

DNS란 도메인 네임 시스템의 약자이며 DNS를 제공하는 서버를 말 그대로 DNS 서버라고 함.

흠... 그 역할은 그림과 같지만 설명을 하자면 이러하다.

사용자가 통신을 원하는 페이지 뭐.. 네이버라고 하자. www.naver.com을 웹 사이트에게 입력한다

그러면 웹 브라우저는 www.naver.com의 아이피 주소를 DNS 서버에게 물어본다.

DNS 서버는 www.naver.com의 아이피 주소를 웹 브라우저에게 알려주고 웹 브라우저는 DNS 서버에게 받은 IP주소에게 통신 요청을 한다.

목적지 IP는 통신 요청에 응답하고 정상적으로 www.naver.com은 보여지게된다.

너무 간단함ㅋ_ㅋ 구조적으로 접근하긴...아니 솔직히 DNS를 구조적으로 접근할 필요가 없을 것 같다.

간단한 개념정리는 여기까지.

FTP Mode

User-PI - Server A                      User-PI - Server B

------------------                      ------------------

C->A : Connect                          C->B : Connect

C->A : PASV

A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2

                                                C->B : PORT A1,A2,A3,A4,a1,a2

                                                B->C : 200 Okay

C->A : STOR                             C->B : RETR

FTP Command

USER <SP> <username> <CRLF>      // 유저아이디   

PASS <SP> <password> <CRLF>      // 유저비밀번호

ACCT <SP> <account-information> <CRLF>        // 별도의 계정정보 ( 확인 불가 )

CWD  <SP> <pathname> <CRLF>      // 디렉토리 변경

CDUP <CRLF>       // 상위 디렉토리 이동

SMNT <SP> <pathname> <CRLF>      

QUIT <CRLF>       // 종료

REIN <CRLF>       // 재 초기화

PORT <SP> <host-port> <CRLF>                    // PORT 전송

PASV <CRLF>       // PASSIVE 모드 활성화

TYPE <SP> <type-code> <CRLF>                    // 전송모드 설정

STRU <SP> <structure-code> <CRLF>               

MODE <SP> <mode-code> <CRLF>                   

RETR <SP> <pathname> <CRLF>      // 파일 받기

STOR <SP> <pathname> <CRLF>      

STOU <CRLF>

APPE <SP> <pathname> <CRLF>

ALLO <SP> <decimal-integer> [<SP> R <SP> <decimal-integer>] <CRLF>

REST <SP> <marker> <CRLF>

RNFR <SP> <pathname> <CRLF>      // 이름변환 목적파일

RNTO <SP> <pathname> <CRLF>      // 이름변환 결과파일

ABOR <CRLF>       // 이전작업 취소

DELE <SP> <pathname> <CRLF>      // 파일 삭제

RMD  <SP> <pathname> <CRLF>      // 디렉토리삭제

MKD  <SP> <pathname> <CRLF>      // 디렉토리생성

PWD  <CRLF>       // 현재디렉토리 출력

LIST [<SP> <pathname>] <CRLF>               // 디렉토리,파일 출력

NLST [<SP> <pathname>] <CRLF>

SITE <SP> <string> <CRLF>                  // SITE 지원 확장 명령어, CHMOD 등

SYST <CRLF>       // 서버시스템 종류 출력

STAT [<SP> <pathname>] <CRLF>

HELP [<SP> <string>] <CRLF>      // 명령어 나열

NOOP <CRLF>       // 빈 명령어

Response Code

Connection Establishment

   120

      220

   220

   421

Login

   USER

      230

      530

      500, 501, 421

      331, 332

   PASS

      230

      202

      530

      500, 501, 503, 421

      332

   ACCT

      230

      202

      530

      500, 501, 503, 421

   CWD

      250

      500, 501, 502, 421, 530, 550

   CDUP

      200

      500, 501, 502, 421, 530, 550

   SMNT

      202, 250

      500, 501, 502, 421, 530, 550

Logout

   REIN

      120

         220

      220

      421

      500, 502

   QUIT

      221

      500

Transfer parameters

   PORT

      200

      500, 501, 421, 530

   PASV

      227

      500, 501, 502, 421, 530

   MODE

      200

      500, 501, 504, 421, 530

   TYPE

      200

      500, 501, 504, 421, 530

   STRU

      200

      500, 501, 504, 421, 530

File action commands

   ALLO

      200

      202

      500, 501, 504, 421, 530

   REST

      500, 501, 502, 421, 530

      350

   STOR

      125, 150

         (110)

         226, 250

         425, 426, 451, 551, 552

      532, 450, 452, 553

      500, 501, 421, 530

   STOU

      125, 150

         (110)

         226, 250

         425, 426, 451, 551, 552

      532, 450, 452, 553

      500, 501, 421, 530

   RETR

      125, 150

         (110)

         226, 250

         425, 426, 451

      450, 550

      500, 501, 421, 530

   LIST

      125, 150

         226, 250

         425, 426, 451

      450

      500, 501, 502, 421, 530

   NLST

      125, 150

         226, 250

         425, 426, 451

      450

      500, 501, 502, 421, 530

   APPE

      125, 150

         (110)

         226, 250

         425, 426, 451, 551, 552

      532, 450, 550, 452, 553

      500, 501, 502, 421, 530

   RNFR

      450, 550

      500, 501, 502, 421, 530

      350

   RNTO

      250

      532, 553

      500, 501, 502, 503, 421, 530

   DELE

      250

      450, 550

      500, 501, 502, 421, 530

   RMD

      250

      500, 501, 502, 421, 530, 550

   MKD

      257

      500, 501, 502, 421, 530, 550

   PWD

      257

      500, 501, 502, 421, 550

   ABOR

      225, 226

      500, 501, 502, 421

Informational commands

   SYST

      215

      500, 501, 502, 421

   STAT

      211, 212, 213

      450

      500, 501, 502, 421, 530

   HELP

      211, 214

      500, 501, 502, 421

Miscellaneous commands

   SITE

      200

      202

      500, 501, 530

   NOOP

      200

      500 421

  [출처 - http://whaleboy.tistory.com/80]

IANA가 정리해놓은 ICMP 코드 및 타입입니다.

와샥으로 볼때도 참고하시면 도움될듯합니다..

출처는 언급했지만 IANA입니다.

Internet Control Message Protocol (ICMP) Parameters

(last updated 2010-04-22)

Registries included below:

- ICMP Type Numbers

- Code Fields

- ICMP Extension Object Classes

Registry Name: ICMP Type Numbers

Reference: [RFC2939]

Registration Procedures: IESG Approval or Standards Action

Note: 

The Internet Control Message Protocol (ICMP) has many messages that

are identified by a "type" field.

Registry:

Type Name Reference

---- ------------------------- ---------

  0 Echo Reply  [RFC792]

  1 Unassigned     [JBP]

  2 Unassigned     [JBP]

  3 Destination Unreachable  [RFC792]

  4 Source Quench    [RFC792]

  5 Redirect  [RFC792]

  6 Alternate Host Address     [JBP]

  7 Unassigned     [JBP]

  8 Echo  [RFC792]

  9 Router Advertisement [RFC1256]

 10 Router Solicitation [RFC1256]

 11 Time Exceeded  [RFC792]

 12 Parameter Problem  [RFC792]

 13 Timestamp  [RFC792]

 14 Timestamp Reply  [RFC792]

 15 Information Request  [RFC792]

 16 Information Reply  [RFC792]

 17 Address Mask Request                     [RFC950]

 18 Address Mask Reply  [RFC950]

 19 Reserved (for Security)    [Solo]

 20-29 Reserved (for Robustness Experiment)     [ZSu]

 30 Traceroute [RFC1393]

 31 Datagram Conversion Error [RFC1475]

 32     Mobile Host Redirect              [David Johnson]

 33     IPv6 Where-Are-You                 [Bill Simpson]

 34     IPv6 I-Am-Here                     [Bill Simpson]

 35     Mobile Registration Request        [Bill Simpson]

 36     Mobile Registration Reply          [Bill Simpson]

 37     Domain Name Request                     [RFC1788]

 38     Domain Name Reply                       [RFC1788]

 39     SKIP                                    [Markson]

 40     Photuris                                [RFC2521]

 41     ICMP messages utilized by experimental  [RFC4065]

        mobility protocols such as Seamoby

 42-255 Reserved     [JBP]

Registry Name: Code Fields

Reference: [RFC2939]

Registration Procedures: IESG Approval or Standards Action

Note:

Many of these ICMP types have a "code" field.  Here we list the types

again with their assigned code fields.

Registry:

Type    Name                                              Reference

----    -------------------------                         ---------

  0     Echo Reply                                        [RFC792]

        Codes

            0  No Code

  1     Unassigned                                        [JBP]

  2     Unassigned                                        [JBP]

  3     Destination Unreachable                           [RFC792]

Codes

            0  Net Unreachable                            [RFC792]

            1  Host Unreachable                           [RFC792]

            2  Protocol Unreachable                       [RFC792]

            3  Port Unreachable                           [RFC792]

            4  Fragmentation Needed and Don't             [RFC792]

               Fragment was Set                           [RFC792]

            5  Source Route Failed                        [RFC792]

            6  Destination Network Unknown                [RFC1122]

            7  Destination Host Unknown                   [RFC1122]

            8  Source Host Isolated                       [RFC1122]

            9  Communication with Destination             [RFC1122]

               Network is Administratively Prohibited    

           10  Communication with Destination Host is     [RFC1122]

               Administratively Prohibited

           11  Destination Network Unreachable for Type   [RFC1122]

               of Service

           12  Destination Host Unreachable for Type of   [RFC1122]

               Service

           13  Communication Administratively Prohibited  [RFC1812]

           14  Host Precedence Violation                  [RFC1812]

           15  Precedence cutoff in effect                [RFC1812]

  4     Source Quench                                     [RFC792]

        Codes

            0  No Code

  5     Redirect                                          [RFC792]

        Codes

            0  Redirect Datagram for the Network (or subnet)

            1  Redirect Datagram for the Host

            2  Redirect Datagram for the Type of Service and Network

            3  Redirect Datagram for the Type of Service and Host

  6     Alternate Host Address                            [JBP]

        Codes

            0  Alternate Address for Host

  7     Unassigned                                        [JBP]

  8     Echo                                              [RFC792]

        Codes

            0  No Code

  9     Router Advertisement                              [RFC1256]

        Codes

            0  Normal router advertisement                [RFC3344]

           16  Does not route common traffic              [RFC3344]

 10     Router Selection                                  [RFC1256]

        Codes

            0  No Code

 11     Time Exceeded                                     [RFC792]

        Codes

            0  Time to Live exceeded in Transit

            1  Fragment Reassembly Time Exceeded

 12     Parameter Problem                                 [RFC792]

        Codes

            0  Pointer indicates the error

            1  Missing a Required Option                  [RFC1108]

            2  Bad Length

 13     Timestamp                                         [RFC792]

        Codes

            0  No Code

 14     Timestamp Reply                                   [RFC792]

        Codes

            0  No Code

 15     Information Request                               [RFC792]

        Codes

            0  No Code

 16     Information Reply                                 [RFC792]

        Codes

            0  No Code

 17     Address Mask Request                              [RFC950]

        Codes

            0  No Code

 18     Address Mask Reply                                [RFC950]

        Codes

            0  No Code

 19     Reserved (for Security)                           [Solo]

 20-29  Reserved (for Robustness Experiment)              [ZSu]

 30     Traceroute                                        [RFC1393]

 31     Datagram Conversion Error                         [RFC1475]

 32     Mobile Host Redirect                              [David Johnson]

 33     IPv6 Where-Are-You                                [Bill Simpson]

 34     IPv6 I-Am-Here                                    [Bill Simpson]

 35     Mobile Registration Request                       [Bill Simpson]

 36     Mobile Registration Reply                         [Bill Simpson]

 39     SKIP                                              [Markson]

 40     Photuris                                          [RFC2521]

Codes

            0 = Bad SPI

            1 = Authentication Failed

            2 = Decompression Failed

            3 = Decryption Failed

            4 = Need Authentication

            5 = Need Authorization

41-252  Unassigned

253     RFC3692-style Experiment 1 (*)                    [RFC4727]

254     RFC3692-style Experiment 2 (*)                    [RFC4727]

   (*)  It is only appropriate to use these values in explicitly-

      configured experiments; they MUST NOT be shipped as defaults in

      implementations.  See RFC 3692 for details.

Registry Name: ICMP Extension Object Classes and Class Sub-types 

Reference: [RFC4884]

Range        Registration Procedures         Notes

-----------  ------------------------------  ---------------------------------   

0-246        First Come First Served

247-255      Private Use 

Object

Class Value  Class Name                                    Reference

-----------  --------------------------------------------  ---------

  1          MPLS Label Stack Class                        [RFC4950]

             Sub-types                                     [RFC4950]

                C-Type (Value)     

                0          Reserved                        [RFC4950]

                1          Incoming MPLS Label Stack       [RFC4950]

                0x02-0xF6  Unassigned                      [RFC4950]

                0xF7-0xFF  Reserved for private use        [RFC4950]

             Allocation Policy: C-Type values for Class-num 1 are 

             assignable on a first-come-first-serve (FCFS) basis

             [RFC2434].

  2          Interface Information Object                  [RFC5837]

             Sub-types                                     [RFC5837]

                C-Type (Bit Number)    

                0-1      Interface Role field              [RFC5837]

                            Interface Roles

                            0  Incoming IP Interface       [RFC5837]

                            1  Sub-IP Component of Incoming IP Interface  [RFC5837]

                            2  Outgoing IP Interface       [RFC5837]

                            3  IP Next-hop                 [RFC5837]

                2        Unallocated - allocatable with Standards Action  [RFC5837]

                3        Unallocated - allocatable with Standards Action  [RFC5837]

                4        ifIndex included                  [RFC5837]

                5        IP Address Sub-object included    [RFC5837]

                6        Name Sub-object included          [RFC5837]

                7        MTU included                      [RFC5837]

REFERENCES

----------

[RFC792]   Postel, J., "Internet Control Message Protocol", STD 5,

           RFC 792, USC/Information Sciences Institute, September 1981. 

[RFC950]   Mogul, J., and J. Postel, "Internet Standard Subnetting

           Procedure", STD 5, RFC 950, Stanford, USC/Information

           Sciences Institute, August 1985.  

[RFC1108]  Kent, S., "U.S. Department of Defense Security Options for

           the Internet Protocol", RFC 1108, November 1991.

[RFC1122]  R. Braden, Ed., "Requirements for Internet Hosts -- 

           Communication Layers", RFC 1122, October 1989.

[RFC1256]  Deering, S., Editor, "ICMP Router Discovery Messages", 

           RFC 1256, Xerox PARC, September 1991.

[RFC1393]  Malkin, G., "Traceroute Using an IP Option", RFC 1393,

           Xylogics, Inc., January 1993. 

[RFC1475]  Ullmann, R., "TP/IX: The Next Internet", RFC 1475, Process

           Software Corporation, June 1993. 

[RFC1788]  W. Simpson, "ICMP Domain Name Messages", RFC 1788, April 1995.

[RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,

           Cisco Systems, June 1995.

[RFC2434]  T. Narten and H. Alvestrand, "Guidelines for Writing 

            an IANA Considerations Section in RFCs", RFC 2434, October 1998.

[RFC2521]  P. Karn and W. Simpson, "ICMP Security Failures Messages",

           RFC 2521, March 1999.

[RFC2939]  R. Droms, "Procedures and IANA Guidelines for Definition of 

           New DHCP Options and Message Types", RFC 2939, September 2000. 

[RFC3344]  C. Perkins, Ed., "IP Mobility Support for IPv4", RFC 3344, 

           August 2002. 

[RFC4065]  J. Kempf, "Instructions for Seamoby and Experimental 

           Mobility Protocol IANA", RFC 4065, July 2005.

[RFC4727]  B. Fenner, "Experimental values In IPv4, IPv6, ICMPv4, ICMPv6,

           UDP and TCP Headers", RFC 4727, November 2006.

[RFC4884]  R. Bonica, D. Gan, P. Nikander, D. Tappan and C. Pignataro,

           "Extended ICMP to Support Multi-part Messages", RFC 4884, 

           April 2007.

[RFC4950]  R. Bonica, D. Gan, D. Tappan and C. Pignataro, "ICMP Extensions for 

           MultiProtocol Label Switching", RFC 4950, August 2007.

[RFC5837]  A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., JR. Rivers, N. Shen, 

           "Extending ICMP for Interface and Next-hop Identification", RFC 5837,

           April 2010.

PEOPLE

------

[JBP] Jon Postel, <postel&isi.edu>, September 1995.

[David Johnson]

[Markson] Tom Markson, <markson&osmosys.incog.com>, September 1995.

[Simpson]  Bill Simpson, <Bill.Simpson&um.cc.umich.edu>, October 1995.

[Solo]

[ZSu] Zaw-Sing Su <ZSu&TSCA.ISTC.SRI.COM>

[]

오랜만에 글써보네요

오늘은 헷갈릴 수 있는 것..을..작성해드릴게요

무선 공부하면서 아마 헷갈릴 수도 있을거에요 ㅇㅇ

802.1x 인증???

802.11i 암호화??????

AES도 암호화가있는데??

WEP 암호화??읭??인증방식???WPA 프로토콜??뭐야 뭐가맞는거지???

나만헷갈렸나요??

여튼 구분지어드리겠슴당

802.1x 인증!!!! EAP를 통해서 아이디 비번 요청하는 방식 다르죠??

그러니까 뭐 어느 무선인터넷 접근할땐 '인증서가 필요합니다' 라고하고 또 어떤건 '비밀번호가 필요합니다' 이카잖아요?

이게 바로 EAP 방식이 다른거에요

즉, 인증 방식이라고 할 수 있겠죠??

바로 이거죠 ㅋ

또! 802.11i 암호화?????

802.11i에는 WPA2와 WPA가 숨어있!!죠!!

이거슨 TKIP 방식과 CCMP 방식의 암호화 알고리즘을 지원합니다

WPA는 TKIP..WPA2 퍼스널도 TKIP..엔터프라이즈는 CCMP..

802.11i는 이런 알고리즘을 지원하는 무선 구간 보안 표준이라고 할 수 있슴당

아!! 이 암호화알고리즘과 AES 암호화를 혼동하시면 안됩니다.

AES는 데이터 암호화알고리즘이지 무선보안 암호화 알고리즘은 아니거든요

흠..그리고 WEP,,,WPA,,,WPA2,,,뭐 이런거 ㅋ

이건 보안 프로토콜입니다 용어는 알아두세요 혼동할 수 있거든요 ㅠㅠ

짧게 여기서 끊을게 ㅋ요 ㅋ