Madison Digital Garden

Search

SearchSearch

5. RPKI, BGPSEC

Mar 18, 2024, 15 min read

서울대학교 컴퓨터공학과 권태경 교수님의 "Topics in Computer Networks" 강의를 필기한 내용입니다.

다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.

BGP (Revisit)

  • BGP 는 인터넷 환경에서 패킷을 destination 까지 보내기 위해 아주 중요
  • 따라서 각각의 BGP 라우터들은 어느 이웃에게 패킷을 전달해야 하는지 알아야 함
  • 이웃들과 BGP conn 을 맺기 위해 네 종류의 패킷이 사용된다
    • OPEN: 이웃과 BGP conn (BGP peering) 을 맺을 때 사용
    • KEEPALIVE: 이웃이 살아있는지 확인
    • UPDATE: Reachability 가 변경되거나 네트워크의 가용성이 변경되는 등의 상황을 알리기 위함
    • NOTIFICATION: 에러 핸들링

Problems for BGP

  • BGP 에는 router 의 신원을 확인하거나 update msg 의 정당성을 확인할 수 있는 방법이 마련되어 있지 않다.

1. Route hijack (IP prefix hijack)

.png]]

  • 여기서 AS4 가 진짜이고 AS5 가 attacker 라고 할 때
  • 쟤네 둘 다 Prefix P 를 가지고 있다고 전파할 경우 위 그림에서 보는 것처럼 AS1 은 AS4 로부터 온 AS_PATH: 2 4 메세지와 AS5 로부터 온 AS_PATH: 3 5 메세지를 받게 된다
  • 근데 BGP 에서는 Provider 보다는 Customer 가 보낸 메세지를 더 신뢰하기 때문에 AS5 가 보낸 메세지를 신뢰하게 되고,
    • AS 에서의 provider, customer 는 예를 들면 KT 와 SNU 를 생각하면 된다 - 각각이 AS 이지만 서비스 제공자와 소비자가 있는 것
    • 그림에서 위쪽에 있는 놈이 provider 이고 아래쪽은 customer 이다.
  • 따라서 AS4 로 가야 하는 P prefix 를 가진 메세지가 AS5 로 가게 된다

2. Route leak

525121856.png]]

  • Route hijack 은 AS 가 악의적으로 잘못된 IP prefix 를 전파하여 패킷을 가로챈 것이라면,
  • Route leak 의 경우에는 AS 가 실수로 잘못된 IP prefix 를 전파하여 트래픽이 우회되는 상황을 의미한다.
  • 위의 예시를 보자.
  • AS4 가 보낸 Prefix: P 메세지는 AS5 입장에서는 Provider 가 준 메세지이기 때문에 이것을 전파하면 안된다.
  • 하지만 AS5 의 관리자 실수로 인해 이것을 전파하게 되면 AS1 은 AS4 가 보낸 메세지와 AS5 가 보낸 메세지를 모두 받게 되는데
  • 이때도 역시나 provider 보다는 customer 의 메세지를 더 신뢰해서 AS1 는 해당 IP prefix 에 대해 AS5 를 거치는 route 로 보내게 된다.
  • 그러면 더 짧은 경로가 있는데도 더 긴 경로가 선택되는 것이기에 패킷 전달이 지연되는 것.

Statistics

  • 하지만 위와 같은 문제가 생각보다 자주 발생한다는 것이다.
  • 위의 통계만 봐도 그렇고,
  • 2018년에 발생한 이더리움 사건 도 이 BGP hijack 를 이용해 공격한 것.

Internet Number Resource Allocation

인터넷과 관련된 자원들 (IP 등) 은 위와 같은 구조로 계층적으로 관리된다. - IANA 가 최상위 조직이고, - 각 대륙별로 조직 (RIR - Regional Internet Registry) 이 하나씩 있다. - 가령 APNIC 이 아시아-태평양 지역을 관리한다. - 그리고 그 아래에는 NIR (National Internet Registry) 혹은 LIR (Local Internet Registry) 가 있고 - NIR, LIR 구성은 각 나라마다 자율적으로 수행한다. - 우리나라의 경우에는 KISA 가 NIR 에 해당한다. - 그 아래에는 ISP (Internet Service Provider) 가 있다. - 여기에는 KT, SKT, LG U+ 가 해당되겠지 - 마지막으로 그 아래에는 End User 가 있다. - 이 End User 는 개인 단위가 아니고 조직 단위다. (가령 서울대학교 등)

Solutions for the problem

  • 위의 route hijack 문제를 보면 문제의 원인은 “나한테 없는 IP addr block 을 있다고 구라치는 것” 임을 알 수 있다.
  • 따라서 이를 해결하기 위한 수단 두개가 제시된다.
    1. IRR: 중앙 DB 에 정보를 기록해 거짓말 탐지
    2. RPKI: 기존의 PKI 를 차용해 거짓말 탐지

1. IRR (Internet Routing Registry)

IRR 관련 내용은 시험범위에서 제외되어 간략하게만 정리함 (녹음파일 11')

RR 의 기본적인 아이디어는 “각 AS 가 가진 routing 정보들을 DB 에 담아 누구든 조회 가능하게 하자” 이다. - 전 세계적으로 많은 IRR 들이 구성되어 있고, 이 IRR 들도 계층적으로 구성되어 있는데 최상단에는 5개의 RIR 이 운영하는 IRR 이 있다고 한다.

IRR Object

  • IRR Object 는 간단하게 생각하면 DB entry 이다.
    • RPSL (Routing Policy Specification Language) 라는 언어로 작성된다고 한다.
  • IRR 의 object 는 type 이 있는데, 흔하게 사용되는 type 은 이 정도가 있다고 한다.
TYPEFULL NAMEDESCRIPTION
MntnerMaintainerAS 관리자에 대한 credential (로그인 정보)
Aut-numAutonomous NumberASN
Inetnum / Inetnum6Inet NumberAS 가 소유하고 있는 IP addr block (IP prefix)
Route / Route6Route특정 IP addr block 에 대한 routing 정보
AS-SetAS SetASN 들의 그룹
ROUTE-SetRoute SetRoute 정보들의 그룹
  • 위 정보들은 서로 연관되어 참조된다고 한다.
    • DB relation 라고 생각하면 된다.

IRR 단점

  • 가장 큰 단점은 “강제성이 없음” 이다.
    • AS 관리자는 굳이 IRR 에 자신의 정보를 올리지 않아도 된다.
    • 따라서 IRR 의 많은 데이터 (거의 40%) 가 outdated 되어있어 신뢰성이 많이 떨어진다고 한다.

2. RPKI (Resource Public Key Infrastructure)

- IP prefix 와 같은 internet resource 들이 계층적으로 관리된다는 것이 기존의 PKI 와 유사하기 때문에 이 resource 들도 PKI 를 이용해 관리해보자는 아이디어이다.

  • 즉, RIR 이 PKI 에서 Root CA 가 되고, 중간에 NIR, LIR, ISP 가 Intermediate CA 가 되며 마지막 End user 가 End-entity CA 가 되는 셈.
    • 따라서 ASN 과 IP addr block 을 할당받는 모든 AS 들은 계층에 따라 인증서를 발급받게 된다.
  • 정리하자면 어떤 ASN 이 어떤 IP addr block 을 소유하고 있다는 것을 PKI 로 보증하자라는 아이디어이다.

Issuing Resource Certificate (RC)

  • 위에서 말한 것처럼 root CA 는 RIR 이 된다.
    • 기존의 PKI 에서처럼 이놈들은 그냥 묻지도 따지지도 않고 신뢰하게 되며
    • 따라서 스스로 서명한 인증서 (Self-signed certificate) 를 갖고 있다.
  • 그리고 intermediate CA 는 NIR (혹은 LIR), ISP 들이 된다.
    • RIR 이 NIR (혹은 LIR) 에 인증서를 생성해 주는 것으로 시작해
    • NIR 이 LIR 에게, 혹은 LIR 이 ISP 에게 인증서를 생성해주게 된다.
  • 마지막으로 ISP (혹은 경우에 따라서 End-user) 에서는 상위계층으로부터 받은 인증서를 이용해 End-entity (EE) 인증서를 생성하게 된다.
    • 따라서 얘네들은 인증서를 두개 (받은것, 받은것으로 만든것) 갖고 있게 된다.
Resource Certificate Structure

  • 뭐 많기는 한데 전부 PKI 관련 필드이고 resource cert 에서 중요한 것은 저 Extension 필드에 들어가는 값들이다.
    1. List of Resources: 인증서 주인이 가지고 있는 ASN 들과 IP addr block 들의 리스트
    2. AIA: CA cert (아마 바로 상위 계층?) 의 URI
    3. SIA: 연관된 많은 object 들 (예를 들면 바로 다음에 나올 ROA) 에 접근할 수 있는 URI

Route Origin Authorization (ROA)

  • 여기까지 오면 NIR, LIR, ISP 같은 기관들은 상위 기관으로부터 사용할 수 있는 ASN 들과 IP addr block 들, 그리고 이것들을 받았다는 인증서 (즉, resource certificate) 총 세개를 받게 될 것이다.
  • AS 는 이제 AS 로 기능하기 위해 NIR/LIR/ISP 들로부터 ASN 하나와 IP prefix 들을 할당받을 것이다.
    • 여기서 주의할 점은 AS 와 NIR/LIR/ISP 를 좀 구분지어서 생각해야 된다는 것이다.
    • NIR/LIR/ISP 는 리소스를 주는놈, AS 는 그 리소스를 받아서 사용하는 놈이다.
    • 물론 LIR 과 ISP 이 AS 로 기능할 때도 있지만, 이것은 스스로에게 리소스를 주는 경우라고 이해하면 된다.
  • 그럼 NIR/LIR/ISP 는 AS 에게 요청받은 것 (ASN 하나, IP prefix 하나이상) 을 주며 이 할당 정보를 서명한다.
  • 이때 이 “정보 + 서명” 을 ROA (Route Origin Authorization) 이라고 한다.
    • 즉, ROA 는 해당 AS 가 이 IP prefix 들에 포함되는 IP 들을 운영하고 있고, 이때의 ASN 과 IP prefix 들은 NIR/LIR/ISP 로부터 적법하게 할당받았다는 것에 대한 증명인 셈

  • 위 그림이 ROA 의 구조이다.
    • 뭐 특별할 것은 없죠?

Repository

  • 이때 NIR/LIR/ISP 와 같은 기관들이 인증서와 ROA 등의 signed object 들을 누구나 볼 수 있게 공개하는 저장소를 Repository 라고 한다.
  • 또한 이 signed object 들의 리스트는 Manifest 라고 한다.
    • 이 manifest 또한 서명된다.

Validator, Validated ROA Payload (VRP)

  • Repository 에 있는 ROA 를 가져와서 인증서 확인하고 하는 작업은 router 에게 부담을 주지 않기 위해 router 가 직접 하지는 않는다.
  • 대신, 이 작업을 수행하는 놈을 RPKI Validator (혹은 Cache) 라고 한다.
  • Validator 는 repository 에서 ROA 를 가져와가 인증서랑 비교하면서 이 ROA 가 적법한지 확인한다.
    1. ROA 에 적힌 리소스 (ASN, IP prefix) 를 할당한 기관의 resource certificate privkey 로 ROA 가 서명되었나?
    2. 그 resource certificate 은 유효한가?
    3. 그 resource certificate 의 cert chain 은 유효한가?
    4. 그 resource certificate 안에 적힌 리소스가 ROA 리소스의 superset 인가?
      • 해당 기관이 갖고 있는 리소스 중 일부를 AS 에 할당할 것이기 때문에 superset 의 관계가 된다.
      • 즉, 해당 기관이 리소스를 갖고 있냐는 cert chain 으로 검증하고 그 리소스 중 일부를 AS 에 할당한 것이 맞냐를 검증하는 것.

  • 그리고 이 검증작업이 끝나면 서명을 빼고 (ASN 하나, Prefix 하나) 로 reformat 해서 router 에게 전달해 준다.
    • 이렇게 reformat 된 문서를 Validated ROA Payload (VRP) 라고 한다.

Route Origin Validation (ROV)

  • 왜 이 검증 과정을 Route Origin Validation (ROV) 이라는 거창한 이름으로 부르는지는 모르겠는데
  • Router 는 이 VRP 를 받아 BGP announcement 를 검증하는데 사용한다.
    • Valid: BGP announcement 가 하나 이상의 VRP 에 의해 Cover 된다
      • 여기서 Cover 라는 것은 해당 ASN 에 대한 BGP announcement 메세지의 IP prefix 가 VRP 의 IP prefix 와 일치하거나 혹은 포함된다는 것을 의미한다.
    • Invalid: 다음과 같은 경우의 수가 있다고 한다.
      • Unauthorized AS: 신뢰할 수 없는 AS… 인데 router 는 VRP 밖에 못보니까 아마 Validation 과정에서 validate 실패한 AS 는 뭐 추가적으로 router 에게 알려주거나 하겠제
      • MaxLength violation: BGP announcement 에 명시된 IP prefix maxlength 가 VRP 의 maxlength 보다 더 큰 경우 (더 좁은 범위의 IP)
    • NotFound: BGP announcement 가 하나 이상의 VRP 에 의해 Cover 되지 않는 경우

RPKI Limitations

  • 아직 deployment 비율이 너무 낮다,,
  • 작성시점 (2024-05-25) 기준, 50% 정도 된다 (여기 에서 확인할 수 있다).

BGPSEC

BGPSEC 관련 내용은 시험범위에서 제외되어 나중에 정리할 예정 (녹음파일 48')

Graph View

Backlinks