요약

  • RFC 6860은 OSPF가 최단 경로 계산에 필요한 토폴로지 기술은 유지하면서, 그렇지 않으면 도달 가능한 목적지가 되어버릴 넘버드 트랜짓 프리픽스는 보류할 수 있게 합니다. OSPF에서 파생된 RIB와 FIB에 프리픽스가 없더라도 링크는 계속 동작할 수 있습니다.
  • “숨김(hidden)”은 의도적으로 좁은 의미로 쓰입니다. OSPFv2는 여전히 LSA에서 인터페이스 주소 정보를 노출할 수 있고, 부분 브로드캐스트 네트워크 배치에서는 구형 라우터가 호스트 경로를 설치할 수 있으며, 주소가 트랜짓 에지의 넘버링 이상의 역할을 하고 있었다면 관리, 포워딩 어드레스, 가상 링크 의존성이 실패할 수 있습니다.

경로는 사라졌지만 인접성은 사라지지 않았다

RFC 6860을 읽는 가장 유용한 방법은 겉보기에 모순적인 관찰에서 시작하는 것입니다. 라우터는 OSPF 이웃을 Full 상태로 보고합니다. 링크는 최단 경로 그래프의 일부로 남습니다. 반대편 목적지 사이의 트래픽은 계속 그 링크를 통과합니다. 그런데 원격show route에는 더 이상 트랜짓 링크에 할당된 IPv4 또는 IPv6 프리픽스가 없습니다.

이 관찰들 중 어느 것도 다른 것을 취소하지 않습니다. OSPF는 두 라우터가 연결되어 있다는 사실을 알아야 경로를 계산할 수 있습니다. 그렇다고 항상 링크의 넘버드 서브넷을 모든 라우터가 도달할 수 있는 목적지로 만들 필요는 없습니다. RFC 6860은 라우터만 연결하는 네트워크를 위해 이 구분을 표준 트랙 메커니즘으로 전환합니다.

넘버드 OSPFv2 포인트투포인트 링크의 경우 일반 Router-LSA는 논리적으로 다른 두 가지 기술을 담습니다. Type 1 링크는 이웃 라우터를 이름으로 지정하고 SPF가 사용하는 토폴로지 에지를 제공합니다. Type 3 스텁 링크는 할당된 서브넷을 광고하고 그 서브넷으로의 경로가 라우팅 테이블에 들어가게 합니다. 프리픽스 억제는 Type 3 기술을 생략하면서 Type 1은 유지합니다. 그래프는 에지를 유지하고, RIB는 목적지 프리픽스를 잃습니다.

이것이 한 문장으로 정리되는 제어 지점입니다. 인터페이스 셧다운도, 인접성 억제도, 메트릭 인플레이션도, 주소 제거도 아닙니다. 어떤 주소 정보가 라우팅된 목적지 상태가 되어야 하는지에 대한 결정입니다.

브로드캐스트 케이스에는 다른 신호가 필요하다

포인트투포인트 생략만으로는 모든 OSPF 네트워크 유형을 다루지 못합니다. 브로드캐스트 네트워크에서는 DR(Designated Router)이 접속된 라우터들을 기술하는 Network-LSA를 발생시킵니다. 이 LSA의 Link State ID와 마스크도 네트워크 프리픽스를 식별합니다. LSA 전체를 제거하면 SPF가 여전히 필요로 하는 토폴로지 정보가 함께 사라집니다.

따라서 RFC 6860은 특수 마스크255.255.255.255를 사용합니다. DR은 접속 라우터 목록과 함께 Network-LSA를 계속 발생시키지만, 업그레이드된 수신자는 호스트 마스크를 해당 네트워크 경로를 설치하지 말라는 지시로 인식합니다. 브로드캐스트 동작을 흉내 내는 NBMA 네트워크도 같은 방법을 사용합니다.

호환성 세부 사항이 중요합니다. RFC 6860을 지원하지 않는 라우터는 수정된 LSA를 일반/32로 취급해 DR 인터페이스 주소로의 호스트 경로를 설치할 수 있습니다. 업그레이드된 라우터는 그 프리픽스에 대해 어떤 경로도 설치하지 않습니다. RFC는 부분 배치의 이 비대칭을 수용하는데, 구형 수신자가 트랜짓 서브넷 전체가 아니라 주소 하나만 노출하기 때문입니다. 그러나 비대칭은 여전히 실재합니다.

따라서 “프리픽스가 에어리어 전체에서 숨겨졌다”고 말하는 운영자는 수신 소프트웨어 집합을 명시해야 합니다. 하나의 LSDB가 서로 다른 RIB 결과로 이어질 수 있습니다. 기능 지원 여부는 각주가 아니라 증거의 일부입니다.

OSPFv3는 분리를 더 깔끔하게 만든다

OSPFv3는 주소 지정을 주요 토폴로지 LSA 밖으로 옮겼습니다. Router-LSA와 Network-LSA는 네트워크 주소를 내장하지 않고 그래프를 기술합니다. Link-LSA는 링크-로컬 플러딩 범위에서 주소를 링크에 연결하고, Intra-Area-Prefix-LSA는 프리픽스를 라우터나 트랜짓 네트워크에 연결합니다.

이 아키텍처 덕분에 프리픽스 억제는 토폴로지 LSA를 그대로 두고 관련 Intra-Area-Prefix-LSA 생성에서 트랜짓 전용 프리픽스만 생략할 수 있습니다. RFC 5838의 주소 패밀리 지원은 새로운 숨김 메시지를 요구하지 않으며, 토폴로지와 프리픽스 광고 사이의 동일한 분리가 각 OSPFv3 인스턴스 안에서 그대로 적용됩니다.

그러나 더 깔끔한 설계가 모든 흔적을 지우지는 않습니다. Link-LSA는 여전히 프로토콜 객체입니다. Router ID는 남습니다. 로컬 인터페이스 상태, 설정, 텔레메트리, 패킷은 여전히 주소나 토폴로지 정보를 드러낼 수 있습니다. 방어 가능한 주장은 “OSPF가 링크를 잊었다”가 아니라 “이 수신자가 억제된 프리픽스를 라우팅된 도달 가능성으로 설치하지 않았다”입니다.

숨김은 비밀이 아니다

RFC 6860은 “숨김(hiding)”을 정의된 기술적 의미로 사용합니다. 그 보안 목표는 원격에서 도달 가능한 코어 트랜짓 네트워크 수를 줄이는 것입니다. 주소가 알려져 있더라도 경로가 없는 라우터는 그 OSPF 도메인을 통해서는 일반 트래픽을 그 주소로 전달할 수 없습니다.

이는 공격 표면을 줄일 수 있습니다. 그러나 그것은 암호화도, 인증도, 접근 제어도, 삭제도 아닙니다. OSPFv2에서 인터페이스 주소는 Router-LSA Link Data로 계속 보일 수 있고, DR의 주소는 Network-LSA Link State ID로 남습니다. 링크에 직접 접속된 라우터는 연결된 도달 가능성을 갖습니다. 다른 프로토콜, 정적 경로, 터널 또는 관리 네트워크가 OSPF가 제공하지 않는 경로를 제공할 수 있습니다.

따라서hidden이라는 단어에는 주어와 관찰 지점이 필요합니다. 어느 RIB에서 숨겨졌는가? 어느 OSPF 인스턴스에서 파생된 것인가? 어떤 소프트웨어 버전과 시점에서? 프리픽스가 FIB에도 없었는가? 대체 경로가 있었는가? 노출이 문제되는 장소에서 패킷을 테스트했는가?

이런 한정어 없이는 프로토콜 결과가 보안 슬로건이 됩니다. 가장 강한 증거는 절제된 것입니다: 식별된 프리픽스가 식별된 수신자의 OSPF 파생 라우팅 및 포워딩 상태에서 생략되었고, 식별된 인접성과 토폴로지 경로는 유지되었다.

주소가 다른 역할을 하고 있었을 수 있다

표준은 프리픽스 억제가 무엇을 깨뜨릴 수 있는지에 대해 특히 많은 주의를 기울입니다. 인터페이스 도달 가능성은 일반 고객 트래픽이 트랜짓 서브넷을 겨냥하지 않더라도 종종 문제 해결과 관리에 사용됩니다. 프리픽스가 원격 라우팅 테이블에서 사라지면 핑, traceroute 반환 경로, 직접 인터페이스 관리가 달라질 수 있습니다.

두 의존성은 프로토콜적으로 중대합니다. 첫째, AS-external 또는 NSSA LSA의 0이 아닌 Forwarding Address는 일치하는 라우팅 테이블 항목을 요구합니다. 억제된 인터페이스의 주소를 그 Forwarding Address로 광고해서는 안 됩니다. 그렇지 않으면 계산에 필요한 경로가 없어집니다. 폴백은 덜 직접적인 외부 라우팅을 낳을 수 있습니다.

둘째, OSPF 가상 링크는 인트라-에어리어 경로를 통한 라우팅 가능한 엔드포인트 주소에 의존합니다. 억제된 인터페이스 주소는 가상 링크 엔드포인트로 사용되어서는 안 됩니다. 억제 후에도 살아남는 토폴로지 에지는 주소 도달 가능성에 명시적으로 의존하는 제어 기능을 구해주지 못합니다.

같은 목록에는 도메인 간 피어링, 자동화 대상, 접근 목록, 플로우 레코드, 인터페이스 식별자, 대역 외 관리 가정도 포함되어야 합니다. “트랜짓 전용”은 서브넷 마스크가 증명할 수 있는 속성이 아닙니다. 그것은 주소의 모든 중요한 용도에 대한 운영자의 주장입니다.

동작하는 코드에는 양쪽 영수증이 필요하다

현재 FRRouting과 Cisco 문서는 프리픽스 억제 제어를 노출합니다. 이는 그 메커니즘이 이름이 확인된 소프트웨어 계열에 존재한다는 것을 증명할 뿐, 운영 라우터가 그것을 활성화했는지, 범위가 올바른지, 결과가 안전한지는 증명하지 않습니다.

방어 가능한 변경 영수증은 설정 이전에 시작됩니다. 소프트웨어와 기능 집합, 대상 인터페이스, 제외된 루프백이나 패시브 링크, 변경 전 LSDB, OSPF RIB와 FIB, 현재 관리 경로, Forwarding Address 사용, 가상 링크, 그리고 넘버드 인터페이스에 묶인 피어링을 기록하십시오.

변경 후에는 의도된 분리의 양쪽을 모두 보존하십시오:

  1. 이웃 인접성과 토폴로지 에지가 계속 존재한다;
  2. Type 3 스텁 기술 또는 관련 프리픽스 연관이 없거나, 특수 Network-LSA 마스크가 존재한다;
  3. 각 업그레이드된 수신자는 OSPF RIB와 FIB에서 프리픽스를 생략한다;
  4. 레거시 수신자는 명시적으로 수용된 호환성 결과만 보여준다;
  5. 의도된 관리 경로가 억제된 프리픽스를 빌리지 않고 계속 동작한다;
  6. 외부 경로, 가상 링크, 패킷 경로가 기대된 동작을 유지한다; 그리고
  7. 롤백은 트리거가 충족되면 프리픽스 광고와 도달 가능성을 복원한다.

경로 수 감소가 전체 결과는 아닙니다. 낮은 RIB 카운트는 관측 가능성의 상실이나 간접적인 외부 라우팅과 공존할 수 있습니다. 수렴 개선은 기준선과 비교해 측정해야 하며, RFC 초록에서 물려받을 수 없습니다.

기록 속 Álvaro Retana의 제한된 위치

RFC 6860은 2013년에 Yi Yang, Álvaro Retana, Abhay Roy에 의해 발표되었으며 더 넓은 발명자·검토자 그룹을 인정합니다. Retana의 현재 IETF 프로필은 훨씬 더 넓은 라우팅 표준 경력을 기록하지만, 이 글은 그 경력을 OSPF나 Cisco 코드, 어떤 운영자 배포의 소유권으로 바꾸지 않습니다.

문서화된 공동 저작만으로 충분합니다. 그것은 그를 토폴로지와 주소 도달 가능성을 같은 사실로 취급하지 않는 메커니즘과 연결합니다. 이 구분은 오래 지속되는 인터넷 설계 규율에 부합합니다: 가장 작은 공유 인코딩에 합의하고, 활성화와 의존성 결정은 현지에 남기며, 동작하는 시스템이 약속된 상태를 산출하기 전까지는 완성으로 받아들이지 않는다.

이 메커니즘의 절제가 바로 그 중요성입니다. RFC 6860은 모든 네트워크에게 모든 트랜짓 프리픽스를 숨기라고 명령하지 않습니다. 호환 구현에게 그렇게 할 방법을 제공하고, 그 선택이 안전하지 않은 경우를 명명하며, 결과를 증명할 책임을 운영자에게 남깁니다.

프리픽스 억제 대장

최종 기록은 엔지니어와 소프트웨어가 바뀐 뒤에도 읽을 수 있어야 합니다. 억제된 모든 프리픽스에 대해 라우터와 릴리스, 기능 범위, 관찰 시점, 관련 LSA 식별자, 수신자 기능, 변경 전후 RIB와 FIB 지문, 인접성 상태, 관리 대안, 의존성 점검, 패킷 카나리아, 소유자와 롤백 조건을 보관하십시오.

이 대장은 다섯 개의 진술이 하나로 뭉개지는 것을 막습니다:

  • 링크가 존재한다;
  • OSPF가 그것을 토폴로지로 사용한다;
  • 인터페이스에 주소가 있다;
  • 원격 라우터는 프리픽스를 설치하지 않는다; 그리고
  • 의도된 서비스가 여전히 동작한다.

RFC 6860은 이 다섯 가지가 서로 다른 답을 가질 수 있게 허용합니다. 프리픽스는 RIB를 떠나면서 링크는 네트워크를 계속 실어 나를 수 있습니다. 좋은 운영은 정확히 무엇이 사라졌는지—그리고 무엇이 사라지지 않았는지—기록하는 것에서 시작됩니다.

출처