요약

  • SEND는 암호학적으로 생성된 주소를 사용해 공개 키를 IPv6 인터페이스 식별자에 묶었습니다. 일치하는 서명은 해당 개인 키에 대한 통제를 보여줄 뿐, 개인의 신원이나 라우터의 권한을 보여주지 않습니다.
  • 호스트가 라우터의 인증서 경로를 검증하려면 여전히 로컬에서 구성된 신뢰 앵커가 필요했습니다. SEND는 그 부트스트랩을 없앤 것이 아니라 명시적으로 만들었습니다.

이웃 탐색(Neighbor Discovery)은 링크에서 IPv6가 수행하는 첫 대화 가운데 하나입니다. 호스트는 주변에 누가 있는지 묻고, IPv6 주소를 링크 계층 주소에 매핑하며, 어느 라우터가 링크 밖의 트래픽을 운반할 수 있는지 학습합니다. 이 메시지들이 인증 없이 수용된다면, 링크상의 공격자는 그 초기 결정을 전환하거나 방해하려 시도할 수 있습니다. 원래의이웃 탐색 사양은 IPsec 보호를 논의했지만,RFC 3971은 앞선 문서들이 이 지점에서 이를 사용하기 위한 상세 지침을 제공하지 않았다고 말합니다. 잠재적 피어가 많은 환경에서 그 모두에 대해 보안 결합(security association)을 수동으로 구성하는 것은 대부분의 환경에서 비현실적일 수 있었습니다. SEND, 즉 보안 이웃 탐색(Secure Neighbor Discovery)은 이 특정 부트스트랩 문제에 대한 IETF의 답이었습니다.

SEND의 해법은 두 개의 별개 증명으로 이해하면 더 쉽습니다. 일반 노드의 주소에 대해서는 SEND가 암호학적으로 생성된 주소(Cryptographically Generated Address)를 사용할 수 있었습니다.RFC 3972는 인터페이스 식별자를 공개 키와 보조 매개변수의 해시에서 도출합니다. 검증자는 해시를 다시 계산하고, 대응하는 개인 키로 만든 메시지 서명을 확인할 수 있습니다. 이 주소–키 결합에는 인증 기관이 필요하지 않습니다. 이 증명은 효과적으로 “서명자가 이 주소에 연관된 키를 통제한다”고 말합니다. 그러나 서명자가 실생활에서 누구인지, 누가 서브넷 프리픽스를 할당했는지, 라우터를 신뢰해야 하는지는 말하지 않습니다.

마지막 질문은 다른 경로를 따릅니다. 라우터 탐색(Router Discovery) 정보를 수용할지 판단하는 호스트는 호스트가 이미 신뢰하는 신뢰 앵커로 끝나는 라우터 인증서 체인을 필요로 합니다. SEND의 권한 위임 탐색(Authorization Delegation Discovery) 메시지는 피어로부터 경로를 얻는 데 도움을 줄 수 있습니다. 그러나 이 메시지들은 호스트의 신뢰 앵커를 만들거나 알려지지 않은 루트에 권위를 부여하지 않습니다. 루트는 그 교환 밖에서 이루어지는 구성 결정으로 남습니다. 따라서 SEND의 “제로 구성” 주소 메커니즘이 전체 시스템에 어떤 설정도 필요 없다는 뜻은 아니었습니다.

이 비대칭이 바로 역사적 포인트입니다. 이웃 교환의 한쪽은 로컬 키 보유를 증명하는 데 공개 키 인프라를 피할 수 있었습니다. 반면 라우터 쪽은 명시적 위임을 유지했습니다. 하나의 서명된 패킷이 “나는 이 주소에 서명할 수 있다”를 “나는 경로를 광고할 권한이 있다”로 축소할 수는 없었습니다.

이후의 표준들은 이 경계를 더 운영적으로 만들었습니다.RFC 6494는 자원 인증서에 기반한 SEND 인증서 프로파일을 정의했고,RFC 6495는 Subject Key Identifier 필드를 위한 SEND 이름 유형을 추가했습니다. 이후RFC 6980은 특정 이웃 탐색 및 SEND 메시지에 대해 IPv6 단편화를 금지하여, 단편화된 패킷이 모니터링이나 필터링을 회피할 수 있는 방식을 다루었습니다. 이러한 변경은 자격 증명과 패킷 처리 규칙을 정교화합니다. 그러나 SEND가 얼마나 배치되었는지, 특정 네트워크가 더 안전해졌는지는 보여주지 않습니다.

좁게 읽으면, RFC 3971은 신뢰를 폐지하지 않았습니다. 다른 결정에 다른 근거를 할당했습니다. 노드의 서명된 주장에는 암호학적 주소 결합을, 라우터 권한에는 구성된 인증 루트를. 이는 “주소가 소유자를 증명한다”보다 절제된 주장이며, 이 설계가 어떻게 작동하는지에 대한 더 유용한 설명입니다.