Yandex는 RPKI를 구현합니다.

안녕하세요, 제 이름은 Alexander Azimov입니다. Yandex에서는 다양한 모니터링 시스템과 전송 네트워크 아키텍처를 개발합니다. 하지만 오늘은 BGP 프로토콜에 대해 이야기하겠습니다.

일주일 전 Yandex는 트래픽 교환 지점뿐만 아니라 모든 피어링 파트너와의 인터페이스에서 ROV(경로 원본 유효성 검사)를 활성화했습니다. 이러한 조치가 취해진 이유와 통신 사업자와의 상호 작용에 어떤 영향을 미칠지 아래에서 읽어보세요.

BGP와 무엇이 문제인가?

BGP가 도메인 간 라우팅 프로토콜로 설계되었다는 사실을 알고 계실 것입니다. 그러나 그 과정에서 사용 사례의 수가 증가했습니다. 오늘날 BGP는 수많은 확장 덕분에 메시지 버스로 전환되어 운영자 VPN에서 현재 유행하는 SD-WAN에 이르기까지 작업을 포괄하고 다음과 같은 애플리케이션도 발견했습니다. 거리 벡터 BGP를 링크 위성 프로토콜과 유사한 것으로 바꾸는 SDN과 유사한 컨트롤러를 위한 전송입니다.

그림. 1. BGP 사피

BGP가 그토록 많은 용도를 얻었고 계속해서 사용하는 이유는 무엇입니까? 두 가지 주요 이유가 있습니다:

• BGP는 AS(자율 시스템) 간에 작동하는 유일한 프로토콜입니다.
• BGP는 TLV(유형-길이-값) 형식의 속성을 지원합니다. 예, 이 프로토콜은 단독이 아니지만 통신 사업자 간의 교차점에서 이를 대체할 것이 없기 때문에 추가 라우팅 프로토콜을 지원하는 것보다 다른 기능 요소를 연결하는 것이 항상 더 수익성이 높은 것으로 나타났습니다.

그 사람에게 무슨 문제가 있습니까? 즉, 프로토콜에는 수신된 정보의 정확성을 확인하는 기본 메커니즘이 없습니다. 즉, BGP는 선험적 신뢰 프로토콜입니다. 이제 Rostelecom, MTS 또는 Yandex 네트워크를 소유하고 있음을 세상에 알리고 싶다면 제발!

IRRDB 기반 필터 - 최악 중 최고

질문이 생깁니다. 이러한 상황에서도 인터넷이 여전히 작동하는 이유는 무엇입니까? 예, 대부분의 경우 작동하지만 동시에 주기적으로 폭발하여 전체 국가 세그먼트에 액세스할 수 없게 됩니다. BGP의 해커 활동도 증가하고 있지만 대부분의 이상 현상은 여전히 ​​버그로 인해 발생합니다. 올해의 사례는 작은 운영자 오류 벨로루시에서는 MegaFon 사용자가 인터넷의 상당 부분에 30분 동안 액세스할 수 없게 되었습니다. 다른 예시 - 미친 BGP 최적화 프로그램 세계 최대의 CDN 네트워크 중 하나를 무너뜨렸습니다.

쌀. 2. Cloudflare 트래픽 차단

그런데 왜 그러한 이상 현상이 매일이 아니라 3개월에 한 번씩 발생하는 걸까요? 통신업체는 라우팅 정보의 외부 데이터베이스를 사용하여 BGP 이웃으로부터 수신하는 내용을 확인하기 때문입니다. 그러한 데이터베이스가 많이 있으며 그 중 일부는 등록 기관(RIPE, APNIC, ARIN, AFRINIC)에서 관리하고 일부는 독립 플레이어(가장 유명한 것은 RADB)이며 대기업이 소유한 전체 등록 기관 세트도 있습니다(레벨 XNUMX). , NTT 등). 도메인 간 라우팅이 운영의 상대적 안정성을 유지하는 것은 이러한 데이터베이스 덕분입니다.

그러나 뉘앙스가 있습니다. ROUTE-OBJECTS, AS-SET 객체를 기준으로 라우팅 정보를 확인합니다. 그리고 첫 번째가 IRRDB의 일부에 대한 승인을 암시하는 경우 두 번째 클래스에 대해서는 클래스로서의 승인이 없습니다. 즉, 누구나 자신의 세트에 누구든지 추가할 수 있으며 이를 통해 업스트림 공급자의 필터를 우회할 수 있습니다. 더욱이, 서로 다른 IRR 베이스 사이의 AS-SET 명명의 고유성은 보장되지 않으며, 이는 아무것도 변경하지 않은 통신 사업자에게 갑작스러운 연결 끊김으로 놀라운 결과를 초래할 수 있습니다.

또 다른 과제는 AS-SET의 사용 패턴입니다. 여기에는 두 가지 요점이 있습니다.

• 운영자가 새 클라이언트를 받으면 이를 AS-SET에 추가하지만 제거하는 경우는 거의 없습니다.
• 필터 자체는 클라이언트와의 인터페이스에서만 구성됩니다.

결과적으로 BGP 필터의 최신 형식은 클라이언트와의 인터페이스에서 필터를 점차 저하시키고 피어링 파트너 및 IP 전송 공급자가 제공하는 것에 대한 선험적 신뢰로 구성됩니다.

AS-SET 기반의 접두사 필터를 대체하는 것은 무엇입니까? 가장 흥미로운 점은 단기적으로는 아무것도 없다는 것입니다. 그러나 IRRDB 기반 필터의 작업을 보완하는 추가 메커니즘이 등장하고 있으며, 우선 이것이 바로 RPKI입니다.

RPKI

단순화된 방식으로 RPKI 아키텍처는 레코드를 암호화하여 확인할 수 있는 분산 데이터베이스로 생각할 수 있습니다. ROA(Route Object Authorization)의 경우 서명자가 주소 공간의 소유자이고 레코드 자체가 트리플(prefix, asn, max_length)입니다. 기본적으로 이 항목은 다음을 가정합니다. $prefix 주소 공간의 소유자는 AS 번호 $asn에 길이가 $max_length보다 크지 않은 접두사를 광고하도록 권한을 부여했습니다. 그리고 RPKI 캐시를 사용하는 라우터는 쌍의 준수 여부를 확인할 수 있습니다. 접두사 - 가는 길에 첫 번째 스피커.

그림 3. RPKI 아키텍처

ROA 개체는 꽤 오랫동안 표준화되었지만 최근까지 실제로는 IETF 저널의 종이에만 남아 있었습니다. 제 생각에는 그 이유가 무섭게 들립니다. 나쁜 마케팅입니다. 표준화가 완료된 후 ROA가 BGP 하이재킹으로부터 보호한다는 인센티브가 있었지만 이는 사실이 아닙니다. 공격자는 경로 시작 부분에 올바른 AC 번호를 삽입하여 ROA 기반 필터를 쉽게 우회할 수 있습니다. 그리고 이러한 사실을 깨닫자마자 다음 논리적 단계는 ROA 사용을 중단하는 것이었습니다. 그리고 실제로 기술이 작동하지 않으면 왜 필요한가요?

이제 마음을 바꿔야 할 때가 된 이유는 무엇입니까? 왜냐하면 이것은 진실의 전부가 아니기 때문입니다. ROA는 BGP의 해커 활동으로부터 보호하지 않지만 우발적인 트래픽 하이재킹으로부터 보호합니다., 예를 들어 점점 더 일반화되고 있는 BGP의 정적 누출로 인해 발생합니다. 또한 IRR 기반 필터와 달리 ROV는 클라이언트와의 인터페이스뿐만 아니라 피어 및 업스트림 공급자와의 인터페이스에서도 사용할 수 있습니다. 즉, RPKI의 도입과 함께 BGP에서는 선험적 신뢰가 점차 사라지고 있습니다.

이제 ROA 기반 경로 확인이 주요 플레이어에 의해 점진적으로 구현되고 있습니다. 유럽 최대 IX는 이미 잘못된 경로를 삭제하고 있으며 Tier-1 운영자 중에서 피어링 파트너와의 인터페이스에서 필터를 활성화한 AT&T를 강조할 가치가 있습니다. 최대 규모의 콘텐츠 제공업체도 이 프로젝트에 접근하고 있습니다. 그리고 수십 개의 중간 규모 운송 사업자가 이미 아무에게도 알리지 않고 조용히 이를 구현했습니다. 이 모든 운영자가 RPKI를 구현하는 이유는 무엇입니까? 대답은 간단합니다. 다른 사람의 실수로부터 나가는 트래픽을 보호하는 것입니다. 이것이 바로 Yandex가 러시아 연방에서 네트워크 가장자리에 ROV를 포함시킨 최초의 회사 중 하나인 이유입니다.

그 다음은 어떻게됩니까?

이제 트래픽 교환 포인트 및 프라이빗 피어링이 있는 인터페이스에서 라우팅 정보를 확인할 수 있습니다. 가까운 시일 내에 업스트림 트래픽 제공자를 통한 검증도 활성화될 예정입니다.

이것이 당신에게 어떤 변화를 가져오나요? 네트워크와 Yandex 간의 트래픽 라우팅 보안을 강화하려면 다음을 권장합니다.

• 주소 공간에 서명하세요 RIPE 포털에서 - 간단합니다. 평균 5~10분 정도 걸립니다. 이는 누군가가 무의식적으로 귀하의 주소 공간을 훔치는 경우 연결을 보호할 것입니다(그리고 이는 조만간 일어날 것입니다).
• 오픈 소스 RPKI 캐시 중 하나를 설치합니다(잘 익은 유효성 검사기, 루틴네이터) 네트워크 경계에서 경로 확인을 활성화합니다. 이 작업은 시간이 더 걸리지만 기술적인 문제는 발생하지 않습니다.

Yandex는 또한 새로운 RPKI 개체를 기반으로 한 필터링 시스템 개발을 지원합니다. 스파 (자율 시스템 공급자 인증). ASPA 및 ROA 개체를 기반으로 하는 필터는 "누설" AS-SET을 대체할 수 있을 뿐만 아니라 BGP를 사용하는 MiTM 공격 문제도 해결합니다.

한 달 후 Next Hop 컨퍼런스에서 ASPA에 대해 자세히 말씀드리겠습니다. Netflix, Facebook, Dropbox, Juniper, Mellanox 및 Yandex의 동료들도 이곳에서 연설할 예정입니다. 네트워크 스택과 향후 발전에 관심이 있으신 분들은 오세요 등록이 열려 있습니다.

출처 : habr.com