3. The Internet Protocol (IP) - 2

4. IP Forwarding

IP Forwarding은 토폴로지 가정에 따라 방식이 다르다. 예를들어 P2P 연결 등 목적지가 호스트에 직접 연결되어 있는 경우나 공유 네트워크에 있는 경우 IP 데이터그램은 MAC 주소만 가지고 직접 전송이 가능하다. 그러나 그렇지 않은 경우(Foreign Network를 하나 이상 거치는 경우), 호스트는 데이터그램을 자신에 연결된 라우터로 전송하고 해당 라우터가 데이터그램을 목적지까지 전달한다. 여기서 호스트란 자신이 생성하지 않은 데이터그램을 전달하지 않지만, 라우터는 전달하는 네트워크 노드라고 생각하면 된다.

일반적으로 IP 프로토콜은 동일한 기기의 다른 상위 계층 프로토콜(TCP, UDP)로부터 데이터그램을 받거나 네트워크 인터페이스로부터 데이터를 받을 수 있다. IP 계층은 라우팅 테이블 혹은 포워딩 테이블이라고 불리는 정보를 구성하여 메모리에 저장하며 데이터그램을 전송할 때마다 이를 검색한다. 네트워크 인터페이스로부터 데이터그램이 수신된다면 IP는 먼저 목적지 IP 주소가 자신의 IP 주소 중 하나인지(즉, 자신이 목적지인지) 혹은 IP 브로드캐스트나 멀티캐스트 주소와 같은 자신이 수신해야할 트래픽인지 확인한다. 만약 그렇다면, 데이터그램은 상위 프로토콜 모듈(프로토콜 필드, Next Header에 지정된)으로 데이터를 전달한다.

만약 데이터그램의 목적지가 IP 모듈에서 사용 중인 로컬 IP 주소 중 하나가 아니라면(Foreign Network) 다음 중 하나의 절차가 이루어진다.

1. IP layer가 라우터로 동작하도록 설정된 경우, 데이터그램은 전달된다. (송신 데이터그램)

2. 그렇지 않은 경우, 폐기된다.

---

1. Forwarding Table

IP Protocol Standard는 포워딩 테이블에 반드시 포함되어야 할 데이터를 명시하지는 않는다. 그렇지만 일반적으로 IP 포워딩 테이블로 동작하기 위한 주요 정보는 몇 가지 존재한다.

- Destination : 이 필드는 32비트(IPv6는 128비트)로 구성되며 masking 작업의 결과와 비교하는데 사용된다. 모든 목적지를 포괄하는 default route의 경우처럼 간단히 0일 수도 있고, host route처럼 전체 IP 주소 길이만큼 길 수도 있다.

- Mask : 이 필드도 32비트로 구성되며, 포워딩 테이블에서 조회 중인 데이터그램의 목적지 IP 주소에 비트 단위의 AND 연산 마스크로 적용된다. 마스킹된 결과는 포워딩 테이블 항목의 Destination set과 비교된다.

- Next hop : 이 필드는 데이터그램이 전송되어야 할 다음 IP 엔티티의 32비트 IPv4 주소 또는 128비트 IPv6 주소를 포함한다. Next hop entity는 일반적으로 forwarding 조회를 수행하는 시스템과 네트워크를 공유하며 동일한 네트워크 prefix를 공유한다. 

- Interface : 이 필드는 데이터그램을 다음 홉으로 전송하는데 사용해야할 네트워크 인터페이스를 IP layer에서 참조하는 식별자를 포함한다. (ex: 802.11 WLAN interface, 802.3 LAN interface, PPP interface) 만약 포워딩 시스템이 IP 데이터그램의 송신자이기도 하다면 이 필드는 송신 데이터그램에 사용할 Source IP 주소를 선택하는데 사용된다.

Ex : 

Network Route

- Destination : 192.168.1.0

- Mask : 255.255.255.0

=> 192.168.1.x 대역의 IP 주소 모두 포함

Host Route

- Destination : 192.168.1.1

- Mask : 255.255.255.255

=> 192.168.1.1에 정확히 매칭

IP Forwarding은 홉 단위로 수행된다. 따라서 데이터그램을 전송해야할 다음 홉 엔티티의 IP 주소만 가지고 있다. 

다음 홉은 포워딩 시스템보다 목적지에 더 가까이 있다고 가정하며, 다음 홉 라우터는 포워딩 시스템과 직접 연결되어있어야한다.(동일한 네트워크 프리픽스 공유). 또한 루프가 형성되지 않아야한다.

라우팅 테이블의 정확성을 보장하고 업데이트를 하는 프로토콜은 라우팅 프로토콜이라고 부르며 다양한 프로토콜이 존재한다.(RIP, OSPF, BGP, IS-IS)

 

2. IP Forwarding Actions

호스트나 라우터의 IP 계층이 IP 데이터그램을 다음 홉 라우터나 호스트로 전송해야 할 때, 먼저 데이터그램에 포함된 목적지 IP 주소(D)를 확인한다. 이 D 값을 기반으로, 다음과 같은 Longest Prefix Match 절차가 Forwarding table에서 실행된다.

1. 테이블에서 다음 조건을 만족하는 모든 항목을 검색한다.

(D∧mj​)=dj

여기서 mj는 포워딩 항목 ej와 관련된 마스크 필드 값이고 dj는 ej와 연관된 목적지 필드 값이다. 즉, 마스크를 적용하여 dj와 일치하는지를 비교하는 것이다. 조건이 만족되면 ej는 일치로 결론이 난다. 일치가 발생하면 알고리즘은 해당 항목의 인덱스와 마스크 mj에서 1로 설정된 비트 수를 기록한다. 즉, 얼마나 많이 일치했는지를 기록하고 더 많은 1이 발생할수록 더 나은 일치로 간주된다.

2. 가장 많은 1 비트를 가진 마스크 mk를 가진 최적의 일치 항목 ek가 선택되며, 그 항목의 next-hop으로 이동하게 된다.

 

만약 Forwarding table에서 일치 항목이 발견되지 않으면, 데이터그램은 전달할 수 없는 상태가 된다. 이 전달 불가 데이터그램이 local(해당 호스트)에서 생성된 경우, 일반적으로 host unreachable 오류가 데이터그램을 생성한 애플리케이션에 반환된다. 라우터의 경우 ICMP 메세지를 데이터그램을 보낸 호스트로 반환한다.

특정 상황에서는 동일한 개수의 1 비트를 가진 여러 항목이 일치할 수 있다. 이러한 경우 최종적으로 시스템은 어떤 결정을 내릴지는 표준이 정의하지 않는다.(OS의 프로토콜 구현마다 다름.) 일반적으로는 단순히 첫 번째로 일치하는 항목으로 보내는 것이다.

 

3. Examples

먼저 Direct Delivery를 살펴보자.

이 경우는 모든 시스템이 동일한 Network prefix. 즉 같은 LAN에 존재할 때이다. 따라서 라우터의 개입이 없고 한 switch에 모든 노드가 연결되어있는 것을 볼 수 있다.

D의 주소를 10.0.0.9 라고 가정하면 첫 번째와 두 번째 Forwarding table 항목 모두와 10.0.0.9는 일치한다. 하지만, 두 번째 항목이 더 많이 일치하는 것을 볼 수 있다. 따라서 다음 홉은 10.0.0.100(S)가 된다. 해당 항목의 GW에는 전송 호스트의 자체 네트워크 인터페이스 주소가 포함되어 있으며 이는 Direct delivery 사용 가능을 나타낸다.

이 후 데이터그램은 하위 계층 프레임에 캡슐화되어 대상 호스트 D로 전달된다. 대상 호스트의 하위 계층 주소를 모르는 경우, 이 시점에서 ARP 프로토콜 작업이 호출된다. 주소를 확인한 후 데이터그램의 목적지 주소는 10.0.0.9가 되며 스위치는 Direct Delivery이므로 링크 계층 주소 D만을 기반으로 전송한다.

 

그 다음은 Indirect Delivery를 알아보자. Window 호스트는 ftp.uu.net으로 데이터를 전송해야하며 해당 호스트의 IPv4 주소는 192.48.96.9 이다.

 먼저 Windows 머신은 Forwarding table에 검색해보지만 local network에서 일치하는 prefix를 찾지 못한다. 따라서 defauilt route entry를 사용하며 기본 경로 항목은  다음 홉 GW가 10.0.0.1임을 나타낸다.(R1의 a-side) 이 때 R1으로 전송을 위해 R1의 Link layer 주소를 ARP를 통해 알아낸다. 네트워크가 S와 R1을 연결하면, S는 R1로 데이터그램을 보낸다. (실제 전달은 하위 계층 헤더의 처리에만 기반한다.)

데이터그램을 받은 R1 역시 자신의 Forwarding table을 확인한다.

똑같이 Local Network에 일치하는 주소가 없으므로 default 주소를 사용하고 70.231.159.254로 가는 걸로 결정된다. (R2-a side) 이 라우터가 글로벌 인터넷에 있으며 Windows 머신의 소스 주소가 사설 주소인 10.0.0.100이므로 NAT 기록을 한 뒤, 70.231.132.85 인터페이스를 통해 R2로 이동하게 된다. (사설 주소를 사용하지 않는 ISP나 대규모 기업은 이 과정을 생략한다.) 이를 반복하며 최종 D까지 도착하게 된다.

---

5. Mobile IP

지금까지는 IP 데이터그램이 인터넷과 IP를 사용하는 사설 네트워크에서 전달되는 일반적인 방식을 논의하였다. 이 모델은 호스트의 IP 주소가 인근 호스트 및 라우터와 프리픽스를 공유한단 것을 가정한다. 만약 호스트가 네트워크 연결 지점을 벗어나며 (다른 네트워크로 이동하며) 링크 계층에서 네트워크에 연결 상태를 유지하려고 한다면, IP 주소를 변경해야 한다.

Mobile IP는 호스트가 "홈" 네트워크를 가지지만 때때로 다른 네트워크를 방문한다는 아이디어를 기반으로 이루어진다. 호스트가 홈 네트워크에 있을 때는 이 장에서 논의한 알고리즘에 따라 일반적인 포워딩이 이루어진다. 그러나 홈 네트워크를 벗어난 경우에도 호스트는 홈에서 일반적으로 사용하는 IP 주소를 유지한다. 이 때, 네트워크와 통신하는 다른 시스템들이 호스트가 여전히 홈 네트워크에 연결되어있는 것처럼 보이도록 특수한 라우팅 및 포워딩 기법이 사용된다.

이 방식은 home agent라는 특수한 유형의 라우터에 의존한다. 

 

1. The Basic Model : Bidirectional Tunneling

 

이 그림은 MIPv6가 작동하기 위해 관여하는 구성 요소를 보여준다. 이동이 가능한 호스트는 Mobile Node라고 하며, MN과 통신하는 호스트는 Correspondent Node라고 한다. MN은 홈 네트워크에서 사용되는 네트워크 프리픽스에서 선택된 IP 주소를 받는다. 이 주소를 HoA라고 할 시, MB이 다른 네트워크 방문하여 받는 주소를 Care-of Address(CoA)라고 할 수 있다. 기존 모델에서 CN이 MB과 통신할 때 트래픽은 항상 Home Agent로 가게 된다. 이 때 MN은 HoA, CoA에 binding 되어있다고 한다. 

기본 모델은 MN이 네트워크의 새로운 지점에 연결되면 해당 MN이 네트워크의 새로운 지점에 연결되면, 해당 MN은 CoA를 받고 자신의 HA에 binding update 메시지를 보낸다. HA는 이에 binding acknowledgement를 보낸다. 이 과정이 정상적으로 진행되었을 시, MN과 CN 간의 트래픽은 bidirectional tunneling 이라고 불리는 양방향 형태의 IPv6 패킷 터널링을 사용하여 MB의 HA를 통해 라우팅된다. 이 메시지들은 IPsec으로 보호되며 HA가 가짜 MB으로부터 binding update가 되지 않게 보장한다.

---

2. Route Optimization (RO)

bidirectional tunneling은 MIPv6가 비교적 간단하게 작동하도록 하며, CN이 Mobile IP를 인식하지 못하는 경우에도 사용할 수 있다. 하지만 단점은 항상 있는데 CN과 MN이 사실 바로 옆에 존재하는데 HA까지 갔다가 MN에 접근해야한다는 문제가 발생하게되는 것이다. 기본 MIPv6에서 발생할 수 있는 이러한 비효율적인 라우팅을 개선하기 위해, RO라는 프로세스를 사용할 수 있다.

RO가 사용될 경우, Coresspondent registration 과정이 포함되게된다. 여기서 MN은 자신의 현재 CoA를 CN에 알려 HA를 거칠 필요 없이 라우팅이 이루어질 수 있도록 한다. RO는 registration binding을 설정하고 유지하는 과정과 binding 완료 이후 데이터그램을 교환하는 과정으로 작동한다. MN이 CN과 바인딩을 설정하려면, 보안 상 먼저 CN에게 자신이 올바른 MN임을 증명하게 된다. 이 작업은 Return Routability Procedure(RRP)로 이루어진다.

RRP 메시지들은 MN, HA 간의 메시지처럼 IPsec으로 보호되지는 않는다.  RRP는 IPv6 Mobility 확장 헤더의 이동성 메시지를 이용하며 CN에게 특정 MN이 HoA와 CoA 양 쪽 다 소통 가능한 상태라는 것을 인증한다. 

그림을 보면 MN은 먼저 HoTI 메시지와 CoTI 메시지를 CN에 보낸다. HoTI 메시지는 CN으로 전달되는 도중 HA를 통해 포워딩된다. CN은 두 메시지를 순서 관계없이 수신한 후, 각각 HoT, CoT 메시지로 응답한다. (HoT는 HA를 통해 간다.) 이 메시지들에는 토큰이 포함되어있으며, MN은 이를 사용해 암호 키를 생성한다. 생성된 키는 CN으로 전송되는 binding update를 생성하는데 사용된다.

이 과정이 완료되면 MN과 CN간의 데이터가 직접 흐를 수 있게 된다. 이때 상위 프로토콜은 HoA로 여전히 통신하기 때문에 MN의 HoA를 헤더 옵션에 추가시켜 전송하게 된다. 따라서 애플리케이션은 연결을 설정하거나 다른 작업을 수행할 때, CoA 대신 MN의 HoA를 사용한다고 믿게 된다.

 

---

6. Host Processing of IP Datagrams

호스트는 데이터그램을 전송할 때 Source IP Address, Destination IP  Address에 무엇을 넣을지 고려해야한다.

예를 들어 웹 브라우저와 같은 애플리케이션들은 여러 주소를 가질 수 있는 특정 호스트나 서버에 연결을 시도할 수 있다. 또한 이러한 요청을 보내는 클라이언트 자기 자신도 여러 개의 인터페이스를 가질 수 있다. 따라서 데이터그램을 보낼 때 어떤 주소를 사용해야 할지에 대한 문제가 생긴다.

 

1. Host Models

Unicast datagram이 수신 호스트의 IP 주소 중 하나와 일치하는지 확인하고 처리할지 여부를 결정하는 것은 수신 시스템의 Host Model에 따라 달라진다. Host model의 종류로는 Stroing Host model, Weak Host model이 있다.

Strong Host model의 경우 데이터그램이 로컬 프로토콜 스택에 전달되기 위해서 데이터그램에 표시된 Destination IP Address 필드에 포함된 IP 주소가 데이터그램이 도착한 인터페이스에 구성된 주소 중 하나와 일치해야한다. 즉, 데이터그램은 도착한 네트워크 인터페이스와 목적지 IP 주소가 일치할 때만 처리된다. 또한 데이터그램을 특정 인터페이스에서 보낼 때, 해당 인터페이스에 구성된 주소 중 하나가 데이터그램의 소스 IP 주소와 일치해야만 전송한다.

Weak Host model의 경우 어느 네트워크 인터페이스로 도착했는지 여부 관계 없이 목적지 주소가 로컬 주소 중 하나와 일치하면 수신 프로토콜 스택에서 처리된다.

그림을 보면 A, B는 글로벌 인터넷을 통해 연결되며 동시에 LAN으로 연결되어있기도 하다. 만약 호스트 A가 Stroing Host model을 사용한다면, 인터넷에서 203.0.113.1을 목적지로 하는 패킷이나 로컬 네트워크에서 192.0.2.1을 목적지로 하는 패킷을 수신했을 때, 본인을 목적지로 한 전송이라고 하더라도 이를 드롭한다. 호스트 B는 Weak Host model이라고 가정하면, B는 로컬 네트워크를 통해 192.0.2.1로 패킷을 전송하기로 선택할 수 있다.(비용이 더 저렴하고 빠르기 때문.) 이렇게만 보면 당연히 Weak Host model이 효율적이어보인다. 그렇다면 Strong Host model은 왜 쓰는걸까?

그 이유는 보안 문제이다. 만약 인터넷에 있는 사용자가 203.0.113.2를 목표로 하는 패킷을 주입한다고 해보자. 이 패킷은 203.0.113.1과 같은 스푸핑된 소스 IP 주소를 포함할 수도 있다. 만약 인터넷이 이러한 패킷을 B로 라우팅 하도록 허락한다면, B의 애플리케이션은 이 패킷이 A가 로컬 트래픽을 보낸 것이라고 오인할 수 있다. (203.0.113.1로 소스 IP를 써서 글로벌 인터넷으로 전송.) 

 

2. Address Selection

호스트가 IP 데이터그램을 보낼 때, 송신 데이터그램의 Source IP Address 필드에 어떤 주소를 넣을지 결정해야한다. 또한 특정 대상 호스트의 주소가 여러 개일 경우 어떤 목적지 주소를 사용할지도 결정해야한다. 이 때 Source Address Selection과 Destination Address Selection 이라는 절차가 사용된다. 

IPv4만 사용하는 호스트는 일반적으로 복잡한 문제가 발생하지 않으나, IPv6 기본 주소를 선택하는 것은 까다로운 문제이다. 따라서 다음의 규칙을 따라 기본 주소를 선택하게 가이드하고 있다.

1. 소스/목적지 주소 쌍은 동일한 범위의 주소를 사용하기

2. 작은 범위를 더 큰 범위보다 선호

3. 사용 가능한 다른 주소가 있을 경우, 임시 주소 사용을 피하기

4. 가장 긴 공통 공통 프리픽스 주소 쌍 선호

5. 사용 가능한 경우 글로벌 주소를 임시 주소보다 선호

기본 주소 선택은 각 호스트에 존재하는 Policy Table에 의해 제어된다. 주소 A에 대해 조회하면 A에 대한 우선 순위 값 P(A)와 라벨 L(A)가 생성된다. 우선 순위 값은 높을 수록 더 선호된다는 것이며 라벨은 유사한 주소 유형을 그룹화하는데 이용된다. 예를 들어 L(S)=L(D)일 경우 해당 주소 쌍을 동일한 범위라고 판단, 선호하게 된다.

---

7. Attacks Involving IP

Link layer에도 공격이 있듯이 Network layer의 대중적인 프로토콜인 IP에도 다양한 공격이 있어왔다. 이러한 공격은 주로 옵션의 작동 방식을 악용하거나 특수 코드의 버그를 이용한 것이었다.

단순한 공격에는 잘못된 헤더 필드를 통해 라우터를 충돌시키거나 성능을 저하시키려는 시도가 포함된다. 따라서 인터넷의 라우터는 일반적으로 IP 옵션을 무시하거나 제거하며, 기본 패킷 처리의 버그는 이미 수정되었다.

인증 또는 암호화가 없거나 비활성화된 경우 IP spoofing 공격이 가능해진다. 초기 공격 중 일부는 소스 IP 주소를 위조하는 것이었다. 초창기에는 Access control mechanism이 소스 IP 주소에만 의존했기 때문에, 많은 시스템이 이러한 방식의 공격에 취약했다. 오늘날에는 ingress filtering을 사용하여 방어가 가능하다. ingress filtering이란 ISP가 고객 트래픽의 소스 주소를 확인하여 데이터그램이 할당된 IP prefix에서 온 것인지를 확인하는 방식이다. IPv6와 Mobile IP는 IPv4에 비해 비교적 새로운 기술이기 때문에 모든 취약점이 아직 발견되지 않았을 가능성이 높다. 새롭고 유연한 유형의 옵션 헤더는 더 많은 공격 옵션을 제공할 수도 있다.(RH0) 이러한 공격은 라우팅 헤더의 내용을 고려하여 패킷 필터링 방화벽을 구성함으로써 방지할 수 있다. 그러나 과도한 패킷 필터링 방화벽은 IPv6의 확장 헤더 및 옵션들이 무의미하게 만든다는 점도 있다.