경계 경로 프로토콜 편집하기

'''경계 경로 프로토콜'''(Border Gateway Protocol, BGP)은 [[외부 라우팅 프로토콜]](Exterior Gateway Protocol, EGP)로 자율시스템(관리 도메인)과 [[자율시스템]] 사이에서 사용되는 [[라우팅 프로토콜]]이다.<ref name=“무미닝”>무미닝, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seungj1031&logNo=221012340470&proxyReferer=https:%2F%2Fwww.google.com%2F (네트워크) 라우팅 프로토콜 (RIP, OSPF, BGP)]〉, 《네이버 블로그》, 2017-05-23</ref>

==개요==
정해진 정책에 의하여 최적 [[라우팅]] 경로를 수립하며, 경로 벡터 방식의 라우팅 [[프로토콜]]로 다른 [[내부 라우팅 프로토콜]](Interior Gateway Protocol)보다 컨버전스가 느리지만, 대용량의 라우팅 정보를 교환할 수 있는 프로토콜이다. TCP [[포트]] 179번을 통하여 인접 라우터들과 이웃 관계를 성립하며, 이웃 [[라우터]] 간에는 유니캐스트, 라우팅 [[업데이트]]를 실시한다.<ref name=“무미닝”></ref> [[인터넷]]에서 [[자율시스템]] 중 라우팅 및 도달 가능성 정보를 교환하기 위해 설계된, 표준화된 외부 게이트웨이 프로토콜이다. 초기 연결 시 전체 경로 테이블을 교환하고, 이후에는 변동 내역이 있을 때만 변동 내역을 교환한다. [[패킷]] 형태에는 마커(Marker), 길이(Length), 타입(Type) 3가지가 있고, 19 [[바이트]] 크기의 [[헤더]]와 [[데이터]]로 구성되어 있으며 오픈(Open), 업데이트(Update), 노티피케이션(Notification), 킵얼라이브(Keepalive) 4개의 메시지 타입이 있다.<ref name=“짬밥”>짬밥, 〈[https://zzambab98.tistory.com/31 BGP (Broader Gateway Protocol 경계 경로 프로토콜)]〉, 《티스토리》, 2017-05-23</ref>

==특징==
내부 라우팅 프로토콜과 달리 와일드카드 마스크가 아닌 넷 마스크를 사용한다. 관리자가 임의적으로 범위를 조정할 수 없고, 실제 라우팅 테이블에 등록된 대역을 정확히 입력해야 한다. 장비 사이에 연결된 [[네트워크]] 대역은 광고할 필요가 없다. 다만 이웃 명령어를 사용하여 상대방 장비를 정확히 지정해야 한다.<ref>피망IT, 〈[https://peemangit.tistory.com/135 (Router) BGP (Border Gateway rotocol) 개념 및 설정 (1/2)]〉, 《티스토리》</ref> [[TCP]] 프로토콜을 사용하기 때문에 반드시 출발지 [[IP]] 주소와 목적지 IP 주소를 알고 있어야 한다. 목적지 IP 주소를 알지 못할 경우 정상적으로 이웃 관계가 형성되지 않는다. 이웃 관계가 정상적으로 이루어질 경우, 자신이 보유하고 있는 네트워크 정보를 이웃 라우터로 전송하며, 수신한 라우터는 해당 정보를 경계 경로 프로토콜 테이블에 기록한 후 경계 경로 프로토콜 알고리즘을 이용하여 최적의 경로를 선택하여 로컬 라우팅 정보 베이스(Local Routing Information Base, Loc-RIB)에 인스톨하게 된다. 또한 네트워크 정보를 로컬 라우팅 정보 베이스에 인스톨하기 전에 수신한 정보가 필터링에 적용되는지 또는 이웃 라우터로 정보를 전송할 때 필터링에 적용되는지 등 비교를 하게 된다.<ref name=“전성복”>전성복, 〈[http://163.239.1.207:8088/dl_image/IMG/04//000000019142/SERVICE/000000019142_01.PDF BGP 라우팅 프로토콜의 취약성 분석 및 개선 방안]〉, 《서강대학교 정보통신대학원》</ref>

==구성==
===메세지===
====오픈====
경계 경로 프로토콜의 오픈 메시지에는 경계 경로 프로토콜 버전 정보, 자율시스템 번호, 홀드 타이머(Hold Timer), 라우터 [[아이디]], 추가 기능 여부(Optional)에 대한 정보가 포함된다. 일반적으로 경계 경로 프로토콜 버전 4를 사용하고 있다. 홀드 타이머는 경계 경로 프로토콜 [[피어]](Peer) 간의 상태가 유효하지 않다는 것을 판단하기까지 기다리는 시간이다. 처음 피어 관계를 맺을 때, 두 경계 경로 프로토콜 라우터가 오픈 메시지를 교환할 때 홀드 타임을 결정한다. 서로의 라우터가 광고하는 홀드 타임 중 더 작은 시간을 사용하고, 시스코 라우터의 디폴트 홀드 타임은 180초이다. 라우터 아이디는 라우터에 설정된 IP 주소 혹은 루프 백 [[인터페이스]]에 대한 정보를 의미한다. 수동으로 지정해주려면 ‘bgp router-id’ 명령어를 사용하여 지정해주면 된다. 추가 기능 여부는 장비나 [[운영 체제]]별로 추가 기능이 다르기 때문에 어떤 추가 기능을 지원하는지 피어에게 알리기 위한 것으로, 연결되어 있는 두 경계 경로 프로토콜 피어가 모두 지원하는 기능이라면 그 기능을 사용할 수 있게 한다.

====업데이트====
경계 경로 프로토콜의 피어 관계를 확립한 후에 보내는 메시지로, 광고할 네트워크 정보를 상호 교환하기 위해 사용한다. 광고할 네트워크에 대한 정보뿐만 아니라, 경계 경로 프로토콜 속성 정보, 새로운 유효 네트워크 정보, 네트워크 다운 등의 이유로 라우팅 테이블에서 제거해야 하는 네트워크 정보 등 다양한 정보를 담고 있다. 새로운 네트워크는 네트워크 계층 도달 가능성 정보(Network Layer Reachable Information, NLRI) [[필드]]에 기록하고, 제거할 네트워크 정보는 철회 경로(Withdrawn Routes) 필드에 기록되고, 업데이트된다. 업데이트 메시지를 수신한 피어는 네트워크 계층 도달 가능성 정보 필드의 네트워크 정보를 경계 경로 프로토콜의 테이블에 등록하고, 철회 경로 필드에 기록된 네트워크는 삭제한다. 속성 정보는 네트워크 계층 도달 가능성 정보에 기록된 네트워크에 대한 속성이다.

====노티피케이션====
경계 경로 프로토콜이 동작 중 오류가 발생할 때 경계 경로 프로토콜 피어에 오류의 원인을 통보하는 메시지다. 경계 경로 프로토콜은 오류가 발생하면, 복구하려고 하기 보다는 발생할 수 있는 더 큰 피해를 방지하기 위해 피어의 경계 경로 프로토콜 [[프로세스]]를 중단한다. 이로 인해 피어 관계가 일방적으로 단절되는데, 피어 관계 단절 이유를 상대 피어에게 통보하여 시스템 관리자가 인지할 수 있도록 하는 것이 목적이다. 노티피케이션 메시지의 구조는 오류 코드(Error Code)와 세부정보를 나타내는 오류 서브코드(Error Subcod), 그리고 데이터로 구성된다.

====킵얼라이브====
킵얼라이브 메시지는 두 경계 경로 프로토콜 간에 주기적으로 주고받는 메시지로, 피어끼리 상호작용을 할 때 자신의 상태가 정상이라는 것을 알려주는 용도로 사용한다. 경계 경로 프로토콜은 네트워크의 변화가 있을 때, 변화된 정보만을 업데이트 하기 때문에, 네트워크의 변화가 없으면 경계 경로 프로토콜 피어는 서로의 상태에 대해 전혀 인지할 수 없다. 따라서 킵얼라이브 메시지를 통해 자신의 상태에 이상이 없다는 것을 주기적으로 통보해 주어야 한다. 단순히 자신의 상태가 정상이라는 사실을 알려주는 용도로만 사용되기 때문에, 아무 의미 없는 경계 경로 프로토콜 메시지의 헤더 정보만을 전달하는 방식으로, 링크 대역폭을 불필요하게 낭비하지 않도록 했다. 킵얼라이브 메시지의 디폴트 주기는 60초이고, 홀드 타임과 마찬가지로 설정을 통해 변경할 수 있다. 일반적으로 킵얼라이브 주기는 홀드 주기의 3분의 1에 해당하는 시간을 사용한다. 이때 주의할 점은 홀드 주기의 3분의 1 이하의 값으로는 얼마든지 설정이 가능하지만, 그 이상의 값들은 사용할 수 없다는 것이다.

====루트 리프레시====
루트 리프레시(Route Refresh) 메시지는 새로운 정책이 적용될 경우에도 서비스를 계속해서 유지하도록 마련된 메시지다. 경계 경로 프로토콜은 트리거 업데이트를 사용하기 때문에 피어 간의 라우팅 정보 교환은 피어 관계를 확립한 후 최초 라우팅 업데이트가 이뤄질 때 모든 라우팅 정보를 교환하도록 한다. 수신하는 라우팅 정보는 네트워크 필터링과 속성 변경 등의 정책 적용을 거친 후 라우팅 테이블에 등록되고, 최초 라우팅 업데이트가 이루어진 후에는 네트워크 변화가 발생된 라우팅 정보만을 수신해 정책 적용 후 라우팅 테이블에 등록한다. 따라서 경계 경로 프로토콜 라우터의 테이블에 존재하는 라우팅 정보는 모두 설정된 정책 적용을 마친 라우팅 정보라고 할 수 있다. 네트워크 필터링과 같은 라우팅 정책이 변경될 경우, 경계 경로 프로토콜 라우터는 피어가 전달한 모든 라우팅 정보에 기존 정책을 적용해 이미 로컬 테이블에 등록했기 때문에 변경된 라우팅 정책에 대한 적용이 이루어지지 않는다. 따라서 경계 경로 프로토콜의 라우팅 정책을 변경하려면 경계 경로 프로토콜 세션을 강제로 단절시킨 뒤, 다시 피어 관계를 맺게 함으로써 모든 라우팅 정보를 다시 수신하도록 해야 했다. 이는 정책이 변경될 때마다 서비스가 중단되어야 하는 불편함을 유발했다. 이러한 불편함을 제거하기 위해 경계 경로 프로토콜의 라우터가 피어에 모든 라우팅 정보를 요구하는 메시지를 보내 전체 라우팅 정보를 다시 수신하고, 새로운 정책 적용 시에도 서비스를 유지할 수 있도록 하는 것이 루트 리프레시 메시지다. 루트 리프레시 메시지는 운영 체제 버전에 다라 지원 여부가 결정되기 때문에, 경계 경로 프로토콜의 Capability 코드에 지원 여부를 표시해야 한다. 루트 리프레시 메시지는 선택적인 사항이므로, 경계 경로 프로토콜의 피어링에 영향을 주지는 않는다.<ref>스니카, 〈[https://m.blog.naver.com/PostView.nhn?blogId=musalyh&logNo=221505030804&proxyReferer=https:%2F%2Fwww.google.com%2F BGP section 1]〉, 《네이버 블로그》, 2019-04-04</ref>

===토폴로지===
경계 경로 프로토콜은 매우 유연하면서도 복잡한 라우팅 프로토콜이기 때문에, 경계 경로 프로토콜의 라우터는 인터넷 코어 라우터, 중간 [[인터넷 서비스 제공자]](Internet Service Provider, ISP) 라우터, 인터넷 서비스 제공자의 고객 댁내 장치(Customer Premises Equipment, CPE) 또는 소규모 개인 경계 경로 프로토콜 네트워크의 라우터 등 다양한 [[토폴로지]] 설정으로 배치될 수 있다. 서로 다른 토폴로지에 필요한 경계 경로 프로토콜 경로 수는 0개부터 300,000개 이상까지 다양하다. 인터넷 서비스 제공자의 고객은 인터넷 서비스 제공자로부터 받는 경로의 수와 상관없이 에지 라우터(CPE)에서 인터넷 서비스 제공자가 경계 경로 프로토콜을 실행해야 하는 경우가 종종 있다. 경계 경로 프로토콜의 기본적인 네트워크에는 단일 공급자와 단일 홈, 단일 공급자와 멀티 홈, 다중 공급자와 멀티 홈 세 가지가 있다. 단일 공급자와 단일 홈 네트워크는 네트워크가 단일 인터넷 서비스 제공자로부터 단일 경로를 받는 것이다. 인터넷 서비스 제공자의 고객이 해당 인터넷 서비스 제공자로부터 받는 경로의 수는 자율시스템의 특성에 따라 다르다. 인터넷 공급자로 하나의 인터넷 서비스 제공자만 사용하고, 해당 공급자(단일 공급자 및 단일 홈)에 대한 단일 연결이 있는 인터넷 서비스 제공자의 고객의 경우 자율시스템 외부로 대상이 지정된 모든 트래픽이 인터넷 서비스 제공자에게로 이동하므로 어떤 경로든 받을 필요가 없다. 이러한 고객은 여전히 내부 네트워크 일부 또는 전부를 인터넷 서비스 제공자가 보급할 수 있다. 경계 경로 프로토콜 네트워크의 강력한 후보는 아니지만, 네트워크를 인터넷 서비스 제공자에게 보급하는 데 사용할 수 있고, 대륙별 인터넷 레지스트리(Regional Internet Registry, RIR)의 공용 자율시스템으로는 적합하지 않다. 단일 공급자와 멀티 홈 네트워크는 네트워크가 단일 인터넷 서비스 제공자로부터 여러 경로를 받는 것으로, 단일 인터넷 서비스 제공자를 사용하지만, 인터넷 서비스 제공자에 대한 연결이 여러 개인 인터넷 서비스 제공자의 고객은 각 인터넷 서비스 제공자 게이트웨이에서 기본 경로만을 받는다. 인터넷 서비스 제공자의 연결이 끊어지면 연결된 고객 댁내 장치 라우터에서 내부 라우터로 전송되어 보급된 기본 경로는 철회되고, 인터넷 트래픽은 인터넷 서비스 제공자와 연결이 설정된 고객 댁내 장치 라우터로 이동한다. 고객의 내부 네트워크도 각 고객 댁내 장치 라우터 게이트웨이의 인터넷 서비스 제공자로 보급되므로, 고객에 대한 특정 연결이 끊어진 경우 인터넷 서비스 제공자는 대체 경로를 사용할 수 있다. 일반적으로 RFC 2270의 제안에 따라 단일 개인 자율시스템을 사용하여 경계 경로 프로토콜의 이점을 얻을 수 있고, 공용 자율시스템 번호를 유지할 수 있다. 다중 공급자와 멀티 홈 네트워크는 인터넷 서비스 제공자를 여러 개를 사용하는 인터넷 서비스 제공자의 고객이 각 인터넷 서비스 제공자에 대해 하나 이상의 개별 게이트웨이 라우터를 갖는다. 이 경우 고객의 자율시스템은 공용 자율시스템이며 전송 또는 비전송 자율시스템일 수 있다. 전송 자율시스템은 다른 인터넷 서비스 제공자를 통해 연결할 수 있는 네트워크로 대상이 지정된 하나의 인터넷 서비스 제공자에게서 트래픽을 받아 전달한다. 비전송 자율시스템은 해당 자율시스템으로 대상이 지정된 트래픽만 받고, 기타 다른 모든 트래픽은 차단된다. 전송 자율시스템의 경계 경로 라우터는 대개 각 인터넷 서비스 제공자의 전체 경계 경로 프로토콜 테이블 중 상당 부분을 받는다. 중복성이 탁월하며 일반적으로 각 인터넷 서비스 제공자에 대한 전용 라우터에 사용된다. 공용 자율시스템 번호가 필요하다.<ref>〈[http://help.sonicwall.com/help/sw/kor/7310/25/9/0/content/Appendix_B_BGP/BGP_Advanced_Routing.htm 부록 B: BGP 고급 라우팅]〉, 《sonicwall》</ref>

==동작==
===단계===
#'''유후'''(Idle): 경계 경로 프로토콜을 연결하기 위한 초기 상태다. 경계 경로 프로토콜을 처음 설정할 때, 이웃과 정상적으로 연결을 형성하고자 기다리기 위한 상태로, 이웃 관계에 있는 라우터로부터 일정 시간 동안 응답이 오지 않을 경우, 유후 상태로 동작하게 된다.
#'''연결'''(Connect): 경계 경로 프로토콜의 라우팅 프로토콜은 TCP 포트 번호 179번을 이용하여 이웃 관계를 형성한다. 연결 단계는 TCP 포트 번호를 사용하여 다른 라우터와의 연결하기 위해 기다리는 상태로, 정상적으로 세션이 이루어질 경우, 활성 상태를 거치지 않고 바로 Open sent 상태로 동작하게 된다. 만약 TCP 세션이 정상적으로 이루어지지 않을 경우, 연결 상태에서 활성 상태로 전환하게 되며, 이웃 관계를 다시 형성하기 위해 기다려야 한다.
#'''활성'''(Active): TCP 세션을 재형성하기 위한 상태이며, 활성 상태에서 정상적으로 TCP 세션이 이루어질 경우 “Open sent” 상태로 전환하지만, 만약 활성 상태에서 TCP 세션이 계속해서 이루어지지 않을 경우, 1단계인 유후 상태로 전환되고, 처음부터 다시 연결을 시도한다.
#'''Open Sent''': 이웃 라우터로부터 오픈 메시지를 수신하기 위해 기다리고 있는 상태를 의미하며, 정상적인 상태라면 킵얼라이브 메시지를 전송하게 된다. iBGP인지 eBGP인지 확인한 후, 잘못된 경계 경로 프로토콜 정보가 있을 경우 노티피케이션 메시지를 전송하고, 1단계인 유후 상태로 돌아가 다시 처음부터 연결을 시도하게 된다.
#'''Open Confirm''': 정상적으로 이웃 관계가 이루어졌는지 확인하기 위한 단계이며, 킵얼라이브 메시지를 수신할 경우, Established 상태가 된다. 만약 Open confirm에서 어떤 문제로 인하여 노티피케이션 메시지를 수신한다면 Open sent 단계에서 언급한 것처럼, 다시 1단계로 돌아가야 한다.
#'''Established''': Established 단계에 도달했다는 것은, 정상적으로 이웃 관계가 형성되었다는 것을 의미하며, 이때부터 자신이 보유하고 있는 경계 경로 프로토콜 정보를 인접한 라우터로 전송하게 된다.<ref name=“전성복”></ref>

===라우트 하이재킹===
라우트 하이재킹(Route Hijacking)이란 다른 라우터가 사용하고 있는 정보를 마치 자신이 소유하고 있는 것처럼 가짜 IP 주소를 생성하여 인접한 라우터로 전송하고, 패킷을 가로채 정상적으로 통신이 이루어지지 않도록 하는 방법이다. 경계 경로 프로토콜을 이용하여 이웃 라우터로 잘못 설정된 정보를 전송하게 되면, 수신한 라우터는 다른 이웃 라우터로 이 정보를 다시 전송하는데, 경계 경로 프로토콜은 거리 벡터 라우팅 프로토콜이기 때문에, 인접한 라우터가 전송해 준 정보를 그대로 믿게 되고, 해당 네트워크 정보가 실제로 존재하고 있는 것으로 인식하여 라우트 하이재킹이 이루어지게 된다.<ref name=“짬밥”></ref>

===트래픽===
경계 경로 프로토콜의 트래픽에는 지역 트래픽과 횡단 트래픽 두 종류가 있다. 지역 트래픽(Local Traffic)은 같은 자율시스템에서 발생하거나, 자율시스템으로 전송되어야 할 트래픽이고, 횡단 트래픽(Transmit Traffic)은 자율시스템 밖에서 생성되어, 다른 자율시스템으로 전달되어야 할 트래픽이다. 스텁 자율시스템은 하나의 자율시스템과 연결된 자율시스템으로, 길 끝이 막힌 도로와 비슷하다. 해당 자율시스템에서 출발하거나 그 지역으로 돌아오는 트래픽이 대부분이다. 다중 인터페이스 자율시스템은 두 개 이상의 자율시스템에 연결된 자율시스템으로, 큰 고속도로라고 볼 수 있다. 경계 경로 프로토콜에서 다중 인터페이스 자율시스템 관리자는 횡단 트래픽을 처리하는 조건을 명시하는 라우팅 정책을 정할 수 있다.

===축약===
경계 경로 프로토콜에서 경로를 축약하는 것을 간단하게 축약(Aggregation)이라고 한다. 네트워크 경로를 축약하여 외부로 광고할 경우 따로 옵션(summary only)을 설정해주지 않으면, 상세 경로도 축약된 경로와 같이 광고되며, 옵션을 설정할 경우 상세경로는 광고되지 않으며, 축약된 경로만 외부로 광고된다. 경계 경로 프로토콜 테이블에 존재하는 경로만 축약이 되고, 경계 경로 프로토콜 테이블에 존재하지 않는 경로는 광고되지 않는다. 축약 경로와 상세 경로를 동시에 광고하는 권장되지 않는 사항으로, 경계 경로 테이블의 크기를 줄이기 위해 축약된 경로를 사용하는 것을 권장한다. 옵션을 사용할 경우, 축약된 경로 중 하나라도 경계 경로 테이블에 존재하면 축약 경로는 사라지지 않는다. 따라서 라우팅 테이블을 축소시킬 수 있고, 경로 플래핑 발생 확률을 줄일 수 있어, 안정성을 높일 수 있다. 축약을 하지 않고, 상세 경로만을 광고할 경우 작업이나 경계 경로 프로토콜 페일오버 테스트 진행으로 인해 플래핑이 발생할 수 있다. 이는 곧 변화에 대한 업데이트가 발생한다는 것을 의미하고, 업데이트가 발생한다는 것은 장비의 자원을 소모하게 되고, 안정성을 해치는 결과를 야기한다. 다만 옵션을 사용할 때 다중 인터넷 서비스 제공자와 연결되는 구조인, 멀티 홈(Multi Homed)으로 경계 경로 프로토콜이 설정되어 있을 경우, 옵션을 사용해서는 안 된다는 점을 주의해야 한다.<ref>고미, 〈[https://m.blog.naver.com/PostView.nhn?blogId=roser111&logNo=221126295567&proxyReferer=https:%2F%2Fwww.google.com%2F BGP - Aggregation]〉, 《네이버 블로그》, 2017-10-27</ref>

===결정 과정===
====스피커====
경계 경로 프로토콜의 스피커는 경계 경로 프로토콜 인터네트워크를 만들기 위해 각 자율시스템에서 경계 경로 프로토콜을 실행할 라우터를 선택하고, 메시지 교환 시스템을 이용해 경로를 공유하도록 한다. 같은 자율시스템 내에 있는 라우터에만 접속할 경우, 내부 라우터 스피커, 다른 자율시스템에 있는 라우터에도 접속할 경우 외부 라우터 스피커를 사용한다. 또한 같은 자율시스템에 있는 주변 경계 경로 프로토콜의 스피커는 내부 피어 스피커, 다른 자율시스템에 있는 주변 경계 경로 프로토콜 스피커를 외부 피어 스피커로 부른다.

====라우팅 정보 베이스====
라우팅 정보 베이스(Routing Information Base, RIB)는 경계 경로 프로토콜 스피커가 제대로 동작하기 위해 라우팅 정보의 저장, 갱신, 선택, 광고에 사용하는 중앙 데이터 구조다. 라우팅 정보 베이스는 Adj-RIBs-In(Adjacency-Routing Information Base-Input), 로컬 라우팅 정보 베이스, Adj-RIBs-Out(Adjacency-Routing Information Base-Output) 세 부분으로 나뉜다.<ref>SectionR0, 〈[https://sectionr0.tistory.com/39 Network (18) BGP (경계 경로 프로토콜)]〉, 《티스토리》, 2020-01-25</ref> Adj-RIBs-In은 경계 경로 프로토콜 피어로부터 수신한 경계 경로 프로토콜 라우팅 정보다. 이는 피어의 라우팅 정보가 로컬 라우터의 라우팅 정책이 적용되기 전의 정보로, 경계 경로 프로토콜 피어가 전달한 정보 그대로 보관한다. Adj-RIBs-In은 각 경계 경로 프로토콜 피어별로 할당되고, Adj-RIBs-In에 위치하는 라우팅 정보는 로컬 라우터의 수신 라우팅 정책을 적용한 후 로컬 라우터의 경계 경로 프로토콜 테이블인 로컬 라우팅 정보 베이스로 보내진다. 로컬 라우팅 정보 베이스는 우리가 일반적으로 사용하는 용어인 경계 경로 프로토콜의 테이블을 의미한다. 이는 로컬 라우터의 라우팅 테이블에 등록될 수 있는 경계 경로 프로토콜의 최적 경로 정보를 의미한다. 모든 경계 경로 프로토콜 업데이트는 로컬 라우팅 정보 베이스를 기반으로 하여 경계 경로 프로토콜 피어로 전달된다. 로컬 라우팅 정보 베이스는 Adj-RIBs-In 정보에 수신 라우팅 정책을 적용한 후 등록된다. 또한 라우팅 정보를 전달할 때 로컬 라우팅 정보 베이스 정보를 송신 라우팅 정책에 적용한 후 경계 경로 프로토콜 피어로 전달된다. 경계 경로 프로토콜 라우터는 단 하나의 로컬 라우팅 정보 베이스만을 가지며, 모든 Adj-RIBs-In 정보 중 최적 경로 정보가 로컬 라우팅 정보 베이스에 보관된다. Adj-RIBs-Out은 경계 경로 프로토콜 라우터가 경계 경로 프로토콜 피어로 라우팅 정보를 전달할 때 라우팅 정책을 적용한 후 전달하는 기능을 제공한다. Adj-RIBs-Out은 경계 경로 프로토콜 피어로 전달할 라우팅 정보를 보관하는 곳인데, 로컬 라우팅 정보 베이스로부터 송신 라우팅 정책을 적용한 후 경계 경로 프로토콜로 전달할 라우팅 정보를 보관한다.<ref>스니카, 〈[https://m.blog.naver.com/PostView.nhn?blogId=musalyh&logNo=221505919709&proxyReferer=https:%2F%2Fwww.google.com%2F BGP section 2]〉, 《네이버 블로그》, 2019-04-05</ref>

==종류==
경계 경로 프로토콜에는 iBGP와 eBGP 두 가지가 있다.
====iBGP====
자율시스템 내에서 사용되는 경계 경로 프로토콜로, 하나의 자율시스템에서 받은 eBGP 정보를 다른 자율시스템에게 업데이트하기 위해서 자율시스템 안에서 사용하는 것이다. 물론 내부 게이트웨이 프로토콜을 사용하여 정보를 재분배할 수도 있지만, 수많은 eBGP 정보를 모두 내부 게이트웨이 프로토콜을 사용하여 재분배한다는 것은 부적합한 작업이므로, 자율시스템 내에서는 iBGP를 사용하여 정보의 재분배를 실시한다. 관리 거리(Administrative Distance)가 200일 경우, 자율시스템 안의 정보는 건들지 말라는 것이고,  iBGP는 루프를 방지하기 위해 타임투리브(Time To Live, TTL)을 1로 제한하여 경계 경로 프로토콜 정보를 광고한다. 경계 경로 프로토콜의 타임투리브은 255까지로, 멀리 떨어져 있어도 TCP 연결만 가능하다면 이웃관계가 성립할 수 있다. 자율시스템 안에 eBGP를 가지고 있는 경계 경로 프로토콜라우터들은 iBGP 풀 메쉬(Full Mesh)를 권장한다. 이때 인접한 라우터들의 개수 증가가 발생할 수 있는데 이는 라우터 재분배, 경계 경로 프로토콜 연합(Confederation)을 이용하면 해결할 수 있다.

====eBGP====
[[eBGP]]는 [[자율시스템]]과 자율시스템 사이에서 사용되는 경계 경로 프로토콜로, 자율시스템 밖에서 라우팅 업데이트를 실시하는 용도로 사용된다. 관리 거리는 20으로, 루프를 방지하기 위해 업데이트를 받은 정보 중 자신의 자율시스템이 포함되어 있다면, 받아들이지 않는다. eBGP 의 이웃 관계는 타임투리브이 1로 제한되어 있어, 직접 연결되어있어야만 가능하다. 만약 타임투리브이 1 이상이라면 ‘ebgp-multihop’ 명령어를 사용하여 해결해야 한다. 프레임 릴레이 환경에서 루프백 이웃 관계가 발생할 경우 역시, ‘ebgp-multihop’ 명령어가 필요하다.<ref>jh0110love, 〈[https://m.blog.naver.com/PostView.nhn?blogId=jh0110love&logNo=130081625451&proxyReferer=https:%2F%2Fwww.google.com%2F BGP]〉, 《네이버 블로그》, 2010-03-02</ref>

==문제==
===취약점===
경계 경로 프로토콜은 다음의 세 가지 원론적인 취약점을 가지고 있기 때문에 다양한 보안 위협 요소를 가질 수밖에 없다.
#경계 경로 프로토콜은 피어 사이의 경계 경로 프로토콜의 통신에 사용되는 메시지에 대하여 [[무결성]], 최신성(freshness), 피어 간의 상호 인증 등을 지원하는 충분히 강력한 내부 메커니즘을 가지고 있지 않다. 무결성은 전달되는 메시지가 변경되지 않았다는 것을 보장하는 것이고, 최신성은 수신 측이 재전송된 메시지가 아닌, 실제로 새로운 메시지를 받는 것임을 보장하는 것이다. 피어 간의 상호 인증은 메시지를 송신한 자율시스템이 해커가 아닌 정당한 자율시스템이라는 것을 보장한다.
#경계 경로 프로토콜에는 네트워크 계층 도달 가능성 정보를 알리는 자율시스템의 권한을 증명하는 어떠한 메커니즘도 정의되어 있지 않다. 이것은 path subversion으로 불리는 공격 방법과도 관련이 있다. 자율시스템이 자신의 네트워크에 속하지 않은 IP 주소 대역을 알려도 경계 경로 프로토콜 상에서는 아무런 문제가 되지 않는다. 만약 특정 자율시스템이 다른 자율시스템의 IP 대역에 대해서 좀 더 자세한 [[프리픽스]](prefix)로 알린다면, 다른 자율시스템으로 가야 할 트래픽을 중간에서 가로챌 수 있게 된다. 이러한 공격 방법을 Ip 하이재킹, 프리픽스 하이재킹, 경계 경로 프로토콜 하이재킹 등 다양한 이름으로 부른다.
#경계 경로 프로토콜에는 자율시스템에 의해 알려지는 경로의 속성이 확실하고 신뢰할 수 있는지 확인할 수 있는 어떠한 메커니즘도 정의되어 있지 않다. 중간에 있는 자율시스템이 라우팅 경로를 변경해도 그 사실을 알아낼 수 없기 때문에, 여러 가지 공격이 가능하다.

===보안 위협 요소===
위에서 언급한 세 가지 취약성 때문에 경계 경로 프로토콜에 대해 다양한 공격이 가능하다. 경계 경로 프로토콜을 통해 전달되는 라우팅 데이터가 평문으로 전달된다는 점을 이용하여, 라우팅 데이터를 중간에 가로채는 공격 기법을 무결성 위반이라고 한다. 메시지 재전송을 방지하는 메커니즘이 존재하지 않는다는 점을 활용해서 공격하는 기법은 메시지 재전송이라고 한다. 메시지 삽입 공격은 경계 경로 프로토콜이 새로운 메시지 삽입 공격을 막을 수 있는 메커니즘을 제공하지 않기 때문에 가능한 공격이다. 그러나 경계 경로 프로토콜은 TCP를 사용하기 때문에 이미 연결이 이루어진 경계 경로 프로토콜 세션에 새로운 메시지를 삽입하기 위해서는 정확한 시퀀스(sequence) 번호를 알아야 한다. 경계 경로 프로토콜은 메시지를 삭제하는 공격을 막을 수 있는 방안을 제공하지 않기 때문에 메시지 삭제 공격이 가능하고, 중간에 메시지를 변경하는 공격을 막을 수 있는 메커니즘을 제공하지 않아 메시지 변경 공격도 가능하다. 또한 메인인더미들(Main in the Middle) 공격을 방지할 수 있는 메커니즘을 제공하지 않고, 피어에 대한 인증을 하지 않기 때문에 이런 유형의 공격에 특히 취약하다. 상세 경로를 전달하는 경우, 경계 경로 프로토콜의 트래픽과 라우터 테이블의 크기가 극단적으로 증가할 수 있는데, 그렇게 되면 라우터의 처리 속도가 현저히 감소하고, 원활한 서비스 제공이 어렵게 된다. 따라서 서비스 거부가 발생할 수 있고, 사소한 설정 실수가 전체 인터넷 트래픽의 흐름에 심각한 영향을 줄 수 있기 때문에 네트워크 운영자의 설정 실수 또한 보안 위협 요소로 작용할 수 있다.

====실제 사례====
2003년에 모 대학교 네트워크 연구실에서 경계 경로 프로토콜은 연동할 때 잘못된 설정을 하는 바람에 한국 인터넷 망이 몇 시간 동안 통신 불가 상태에 빠지는 대란이 발생했었다. 또한 파키스탄 텔레콤은 정치 및 종교적인 이유로 파키스탄 국민들이 유튜브 사이트에 접속하는 것을 막고자 했고, 2008년 2월 24일 18시 47분 경에 유튜브의 IP 주소를 자신들의 자율시스템에 속해있는 것처럼 경계 경로 프로토콜 업데이트 메시지를 발표했다. 파키스탄  텔레콤의 상위 인터넷 서비스 제공자인 퍼시픽 센추리 프리미엄 디벨롭먼츠(Pacific Century Premium Developments, PCCW) 글로벌은 이 발표를 전 세계로 전파했으며, 그 결과 파키스탄뿐만 아니라 전 세계의 다른 국가에서도 유튜브 사이트에 접속할 수 없는 사태가 발생했다.

===보안 목표===
경계 경로 프로토콜의 보안 취약점을 해결하기 위해서는 다음과 같은 요구사항들이 만족되어야 한다. 먼저 자율시스템 번호 인증이 필요하다. 하나의 자율시스템 번호를 사용하는 주체가 실제로 자율시스템 할당 기관으로부터 동일한 자율시스템 번호를 할당받은 자율시스템인지 확인할 수 있어야 한다. 또한 경계 경로 프로토콜의 스피커를 인증해야 한다. 자율시스템 번호를 알리는 경계 경로 프로토콜의 스피커가 자율시스템 번호 할당 기관으로부터 자율시스템 번호를 할당받은 자율시스템에 의해 인증된 라우터인지 확인할 수 있어야 한다. 경계 경로 프로토콜의 메시지가 불법적으로 변경되지 않았는지 확인하기 위해 데이터의 무결성을 확인할 수 있어야 한다. 프리픽스 소유와 관련해서도 확인이 필요하다. 특정 프리픽스를 알리는 자율시스템이 해당 프리픽스를 실제로 소유하고 있는 자율시스템인지에 대한 확인이 이루어져야 한다는 것이다. 마지막으로 자율시스템의 경로를 확인할 수 있어야 한다. 경계 경로 프로토콜의 경로가 올바른 순서대로 정확하게 전달되어 왔는지 확인할 수 있어야 한다.

===대처 방안===
====MD5 인증====
이 방식은 국제 인터넷 표준화 기구(Internet Engineering Task Force, IETG) RFC 2385에 제안된 것으로, 경계 경로 프로토콜 세션의 확실성을 보호하기 위해 고안된 것이다. 모든 TCP 패킷은 [[MD5]](Message Digest 5) [[알고리즘]]을 이용하여 생성된 16 바이트의 다이제스트를 포함해야 한다. 이렇게 함으로써 리셋(Reset, RST) 패킷에 오염된 TCP 세그먼트가 들어오는 것을 방지할 수 있다. 그러나 이 방식은 각 TCP 세그먼트에 대해 MD5 다이제스트를 계산하고 검증하기 위해 중앙 처리 장치의 자원을 사용하게 된다. 따라서 MD5 인증 방식이 항상 적절한 것은 아니며, 몇몇 경계 경로 프로토콜의 취약성에 대해서는 적절한 대처방안이 될 수 있다.

====S-BGP====
S-BGP(Secure BGP)는 IP 주소 블록, 자율시스템 번호, 자율시스템 아이디, 경계 경로 프로토콜 라우터 아이디를 인증하기 위해 [[공개키]] 기반 구조(Public Key Infrastructure, PKI)와 [[인터넷 보안 프로토콜]](Internet Protocol Security, IPsec)과 같은 여러 메커니즘을 사용하는 방식이다. 공개키 기반 구조는 엄격한 계층 구조를 이루고 있고, 공개키 기반 구조는 기존의 자율시스템 번호와 IP 주소 공간 할당 기관들과 공존하며, 기존의 시스템에 영향을 미치지 않는다. 경계 경로 프로토콜의 라우팅 정보는 디지털 서명으로 암호화되어 전달되며 디지털 서명을 전달하기 위해 경계 경로 프로토콜 업데이트 메시지에는 새로운 속성이 추가된다. 경계 경로 프로토콜 메시지의 수신 측에서는 이 [[디지털 서명]]을 이용하여 주소 프리픽스와 경로 정보를 검증할 수 있다. 또한 데이터의 무결성을 보장하고 경계 경로 프로토콜 라우터들이 상호 간에 [[인증]]을 하기 위한 경계 경로 프로토콜 제어 트래픽을 교환하는 데 인터넷 보안 프로토콜을 사용한다. 이러한 방식들을 사용함으로써 프리픽스 소유의 검증과 자율시스템 경로의 무결성을 확실히 보장할 수 있다.<ref name=“포항공대”>서신석, 홍성철, 홍원기, 〈[http://dpnm.postech.ac.kr/papers/KICS/08/KICS03.pdf BGP 보안 위협 요소와 대처방안]〉, 《포항공과대학교 컴퓨터공학과》</ref> S-BGP 라우팅 프로토콜이 광범위하게 확산될 경우 라우팅 인프라 보안이 급속도로 발전될 수가 있지만 고려해야 할 문제점들도 있다. 먼저 위계적인 공개키 인프라를 필요로 하는 것과 모든 인터넷 서비스 제공업체로부터 신뢰할 수 있어야 한다는 조건을 만족해야 한다. 두 번째로는, 암호화 과정이 힘들다는 단점이 있고, 세 번째로, 각각의 경계 경로 업데이트가 개별적으로 S-BGP 라우터로부터 지정될 경우 [[오버헤드]]가 발생하게 되는데, 경계 경로 프로토콜 연결 초기 시간이 짧기 때문에, 리부팅 또는 새로운 세션을 맺는 동안 네트워크 경로를 받지 못하는 현상이 발생할 수 있다. 네 번째는, S-BGP 라우팅 프로토콜은 공개키 기반 구조로 저장되어야 하기 때문에, 큰 메모리를 요구할 수가 있다는 것이다. 일반적으로 피어당 10메가바이트일 경우 10개의 피어만 존재한다고 가정해도, 많은 메모리가 필요하고, 현재 사용되고 있는 경계 경로 프로토콜 라우터에 메모리를 모두 업그레이드 해야 한다. 또한 충돌 공격(Collision attack)에 대한 문제점을 해결할 수가 없다는 문제가 있다. 이 문제는 대부분의 라우팅 프로토콜에서 발생되는 문제로, 가장 큰 원인은 복수 개의 경로가 존재할 경우 한 경로에 문제가 발생하면 다른 경로를 통해 지속적으로 통신이 이루어져야 하기 때문이다.

====SO-BGP====
SO-BGP(Secure Origin BGP)는 S-BGP의 문제점을 개선하고자 [[시스코]] 시스템즈의 네트워크 연구자들로부터 제안된 프로토콜로<ref name=“전성복”></ref>, 전달되는 프리픽스를 검증하는 것을 목표로 한다. ‘BGP SECURITY’라는 새로운 경계 경로 프로토콜 메시지가 보안과 관련한 정보를 전달하는 데 사용된다. 자율시스템의 공개키를 인증하기 위해 WOT(Web-Of-Trust) 모델을 이용하며 IP 프리픽스의 소유주를 검증하기 위해 계층적인 구조를 이루고 있다. 각각의 자율시스템은 공개키 인증서를 가지며, 자율시스템 번호는 이 공개키와 함께 암호화된다.<ref name=“포항공대”></ref> So-BGP는 경계 경로 프로토콜의 문제점을 해결하기 위해 다음과 같이 4가지 형식을 바탕으로 개발되었다.
#목적지 네트워크 정보를 생성하여 이웃 라우터로 전송할 때 네트워크 정보가 실제로 존재하는 지 확인할 필요가 있다. 예를 들어 A라는 라우터가 B 라는 라우터로 특정 네트워크 정보를 전송할 때 B 라우터는 A 라우터로부터 수신한 네트워크 정보가 A 라우터에 존재하고 있는지 확인할 필요가 있다.
#이웃 라우터로부터 수신한 네트워크 정보를 전송할 때 실제 목적지 네트워크로 갈 수 있는 경로가 존재하는지 확인할 필요가 있다. 즉, A라는 라우터가 특정 IP 주소를 B 라우터로 전송했을 때, A 라우터는 해당 네트워크 정보로 전송할 수 있는 경로가 존재하는지 확인할 필요가 있다.
#이웃 라우터로부터 수신한 네트워크 정보를 다른 이웃 라우터로 전송해도 된다는 권한을 부여 받았는지 확인할 필요가 있다. A라는 라우터가 특정 IP 주소를 생성하여 B 라우터로 전송했을 때 B 라우터는 A 라우터로부터 수신한 정보를 C 라우터로 전송하기 전에 A 라우터로부터 해당 네트워크 정보를 다른 라우터로 전송해도 된다는 권한을 A 라우터로부터 부여 받았는지 확인할 필요가 있다.
#경계 경로 프로토콜의 자율시스템 번호를 이용하여 로컬 라우터에서 튜닝할 때 해당 자율시스템 번호가 로컬 라우터에 존재하는지 검증할 필요가 있다. 이는 B 라우터가 튜닝하기 위해 사용되는 자율시스템 번호가 B 라우터에서 사용되고 있는 자율시스템 번호인지 검증할 필요가 있다.<ref name=“전성복”></ref>
SO-BGP는 주어진 프리픽스 정보를 자율시스템이 확인할 수 있도록 하고, 수신한 네트워크 정보가 정상적인지 다른 경로를 통해 수신한 정보와 비교하여 자율시스템에 대해서 확인하도록 두 가지 인증방식을 적용했다. So-BGP를 실제로 적용하는데 있어서도 여러 가지 문제점이 따른다. IP 프리픽스는 자율시스템에 대해서 할당되는 것이 아니라, 회사나 학교와 같은 조직에 할당되기 때문에 So-BGP를 적용하는 것이 실제로 가능한지 명확하지 않다. 또한 IP 주소의 할당 대역은 수시로 바뀔 수 있는데, 이것을 엄격한 계층 구조 안에서 추적하는 것은 매우 어려운 일이다.

====PG BGP====
PG-BGP(Pretty Good BGP)는 의심 가는 경로의 전파와 사용에 자동적으로 지연을 두는 시스템이다. 이렇게 지연을 두면 네트워크 관리자와 자동화도니 시스템이 의심 가는 경로에 대해 조사하여 문제가 없는 경로인지 판단할 수 있는 시간을 얻을 수 있다. 또한 어떤 경우에는 의심 가는 경로가 일정 시간이 흐른 후 스스로 사라질 수도 있다. 최근의 경계 경로 프로토콜 업데이트 메시지 정보에 기록되어 있는 신뢰할 수 있는 라우팅 테이블을 참조하여 의심 가는 경로를 알아낼 수 있다. 일정 기간 동안에는 의심 가는 경로에 가장 낮은 우선순위를 두면, 대체 경로가 있는 경우에는 의심 가는 경로를 사용하는 대신 다른 경로를 이용하여 트래픽을 전달하게 된다. 일정 기간 후 의심 가는 경로가 문제가 없는 경로라고 판단된다면, 이 경로를 일반적인 우선순위로 바꾸어 정상적으로 동작하게 한다. PG-BGP의 가장 큰 문제점은 아무런 문제가 없는 경로의 경로도 지연시킬 수 있다는 것이다.

====PHAS====
PHAS(A Prefix Hijack Alert System)의 목표는 특정 프리픽스의 origin이 바뀌면 알리는 것이다. 첫 번째 단계로 라우터 뷰(Viwes)의 경계 경로 프로토콜 테이블을 실시간에 가깝게 모니터링하고 각각의 프리픽스에 도달하기 위한 origin들의 [[데이터베이스]]를 유지한다. 새로운 origin이 발생하면 그것을 알려서 데이터베이스에 저장한다. 만약 정해진 시간 동안 특정 origin이 사용되지 않으면 그 origin은 데이터베이스에서 제거된다. 이런 식으로 데이터베이스를 유지하고 라우터 뷰의 경계 경로 프로토콜 테이블을 모니터링 하다가 문제가 발생하면 [[이메일]]과 같은 방식을 이용하여 네트워크 관리자에게 알린다.<ref name=“포항공대”></ref>

{{각주}}

==참고자료==
*무미닝, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seungj1031&logNo=221012340470&proxyReferer=https:%2F%2Fwww.google.com%2F (네트워크) 라우팅 프로토콜 (RIP, OSPF, BGP)]〉, 《네이버 블로그》, 2017-05-23
*짬밥, 〈[https://zzambab98.tistory.com/31 BGP (Broader Gateway Protocol 경계 경로 프로토콜)]〉, 《티스토리》, 2017-05-23
*피망IT, 〈[https://peemangit.tistory.com/135 (Router) BGP (Border Gateway rotocol) 개념 및 설정 (1/2)]〉, 《티스토리》
*전성복, 〈[http://163.239.1.207:8088/dl_image/IMG/04//000000019142/SERVICE/000000019142_01.PDF BGP 라우팅 프로토콜의 취약성 분석 및 개선 방안]〉, 《서강대학교 정보통신대학원》
*스니카, 〈[https://m.blog.naver.com/PostView.nhn?blogId=musalyh&logNo=221505030804&proxyReferer=https:%2F%2Fwww.google.com%2F BGP section 1]〉, 《네이버 블로그》, 2019-04-04
*〈[http://help.sonicwall.com/help/sw/kor/7310/25/9/0/content/Appendix_B_BGP/BGP_Advanced_Routing.htm 부록 B: BGP 고급 라우팅]〉, 《sonicwall》
*SectionR0, 〈[https://sectionr0.tistory.com/39 Network (18) BGP (경계 경로 프로토콜)]〉, 《티스토리》, 2020-01-25
*고미, 〈[https://m.blog.naver.com/PostView.nhn?blogId=roser111&logNo=221126295567&proxyReferer=https:%2F%2Fwww.google.com%2F BGP - Aggregation]〉, 《네이버 블로그》, 2017-10-27
*스니카, 〈[https://m.blog.naver.com/PostView.nhn?blogId=musalyh&logNo=221505919709&proxyReferer=https:%2F%2Fwww.google.com%2F BGP section 2]〉, 《네이버 블로그》, 2019-04-05
*jh0110love, 〈[https://m.blog.naver.com/PostView.nhn?blogId=jh0110love&logNo=130081625451&proxyReferer=https:%2F%2Fwww.google.com%2F BGP]〉, 《네이버 블로그》, 2010-03-02
*서신석, 홍성철, 홍원기, 〈[http://dpnm.postech.ac.kr/papers/KICS/08/KICS03.pdf BGP 보안 위협 요소와 대처방안]〉, 《포항공과대학교 컴퓨터공학과》

==같이 보기==
* [[프로토콜]]
* [[외부 라우팅 프로토콜]]
* [[포트]]
* [[자율시스템]]
* [[네트워크]]
* [[TCP/IP]]
* [[TCP]]
* [[IP]]
* [[라우터]]
* [[패킷]]
* [[트래픽]]
* [[피어]]
* [[라우팅]]

{{인터넷|검토 필요}}