🕸️ CGNAT & IP Attribution — Carrier-Grade NAT, Logging, dan Dampaknya terhadap Forensik Jaringan

Hubungan ke Vault

Note ini membahas Layer 3 (Network) dari network-security. CGNAT adalah mekanisme ISP-level NAT yang mengaburkan identitas pengguna individu — tantangan utama dalam attribution forensik. Relevan dengan ids-ips-waf-nsm-comparison karena logging CGN adalah data source penting untuk NSM (Network Security Monitoring). Untuk contoh incident attribution di Layer 2, lihat arp-spoofing-incident-addendum.

Daftar Isi

1. Pendahuluan: Apa itu CGNAT?
2. Perbandingan: CGNAT vs Traditional NAT vs IPv6
3. Mekanisme Logging CGN
4. Logging Compliance & Regulasi
5. Attribution Challenges
6. Mapping CGNAT Logs
7. Tools & Data Sources
8. Case Studies
9. Privacy Dual-Use
10. Alternatif & Evolusi Teknologi
11. Bottom Line

1. Pendahuluan: Apa itu CGNAT?

Carrier-Grade NAT (CGNAT), juga dikenal sebagai NAT444 atau Large Scale NAT (LSN), adalah mekanisme network address translation yang diimplementasikan oleh ISP (Internet Service Provider) di level infrastruktur mereka. Tujuannya: memungkinkan ribuan pelanggan berbagi satu alamat IPv4 publik.

1.1 Mengapa CGNAT Ada?

IPv4 Address Exhaustion — Fakta:
 
- Pool IPv4: ~4,3 miliar alamat
- Populasi dunia: ~8+ miliar
- Perangkat terhubung: ~30+ miliar (IoT, smartphone, laptop, server)
- IANA menghabiskan pool terakhir: 3 Februari 2011
- APNIC (Asia-Pasifik): habis April 2011
- RIPE (Eropa): habis November 2019
- LACNIC (Amerika Latin): habis 2020
- AFRINIC: masih punya sisa kecil (~2025-2026 diperkirakan habis)
 
→ Solusi ISP: CGNAT + IPv6 deployment paralel

1.2 Arsitektur Dasar CGNAT (NAT444)

Traditional NAT (NAT44):
Pelanggan → [CPE Router NAT] → Internet (1:1 IP publik:pelanggan)
 
CGNAT (NAT444):
Pelanggan → [CPE Router NAT] → [CGN Gateway ISP] → Internet
                                          ↑
                                   100.64.0.0/10 (RFC 6598)
                                      Shared IP Pool
 
Perbedaan utama:
- Tidak ada IP publik unik per pelanggan
- ISP menggunakan Shared Address Space 100.64.0.0/10 (RFC 6598)
- Logging terjadi di CGN Gateway — BUKAN di CPE router user

1.3 RFC yang Relevan

RFC	Judul	Relevansi ke CGNAT
RFC 1631	The IP Network Address Translator (NAT)	Origin NAT — dasar dari semua NAT
RFC 3022	Traditional IP Network Address Translator	NAT44 — NAT tradisional, pendahulu CGNAT
RFC 2663	IP Network Address Translator Terminology	Terminologi: masquerade, binding, session
RFC 4787	NAT Behavioral Requirements for UDP	Wajib dibaca untuk understanding NAT traversal
RFC 5382	NAT Behavioral Requirements for TCP	Sama, untuk TCP — termasuk security implications
RFC 5508	NAT Behavioral Requirements for ICMP	ICMP melalui NAT — penting untuk troubleshooting
RFC 6598	IANA-Reserved IPv4 Prefix for Shared Address Space	Definisi 100.64.0.0/10 — ruang alamat CGNAT
RFC 6888	Common Requirements for Carrier-Grade NATs	Spesifikasi inti CGNAT — logging, port allocation, thresholds
RFC 7422	Deterministic Address Mapping to Reduce Logging	Alternatif: mapping deterministik kurangi kebutuhan log
RFC 7596	Lightweight 4over6: DS-Lite	Transisi IPv6 with CGNAT element
RFC 7597	Mapping of Address and Port (MAP-E)	Alternatif CGNAT: encapsulation-based
RFC 7599	Mapping of Address and Port using Translation (MAP-T)	Alternatif CGNAT: translation-based

Kritis untuk Forensik

RFC 6888 Section 14 secara eksplisit menyatakan bahwa CGNAT harus menyediakan mekanisme logging untuk mendukung law enforcement. Ini bukan fitur opsional — ini adalah requirement dari standar IETF.

2. Perbandingan: CGNAT vs Traditional NAT vs IPv6

2.1 Tabel Perbandingan

Aspek	Traditional NAT (NAT44)	CGNAT (NAT444)	Native IPv6
Lokasi	CPE Router (rumah/kantor)	CGN Gateway (infrastruktur ISP)	End-to-end, no NAT
IP Publik per Pelanggan	1:1 — satu IP penuh	N:1 — ribuan user share satu IP	1:1 atau lebih — setiap device punya alamat unik
Address Space	Private (RFC 1918) → Public	Private → 100.64.0.0/10 → Public	2000::/3 Global Unicast
Pool Size per Gateway	Single public IP	/32 hingga /24 (~1-256 IP)	Tak terbatas praktis
Port Limit per Customer	~65.535 total (teoretis)	Dibatasi per subscriber (RFC 6888: 2.000-8.000 port minimum)	Tidak ada limit
Logging Requirement	Opsional (jarang)	Wajib (RFC 6888) untuk law enforcement	Tidak diperlukan
Application Impact	Minimal (NAT traversal sudah umum)	Signifikan — P2P, VoIP, gaming, VPN bermasalah	Ideal — no NAT issues
Traceability	Langsung: IP publik = satu pelanggan	Kompleks: butuh log ISP + timestamp sinkron	Langsung: IP unik per device
Deployment	Universal (setiap router)	ISP Tier 1-3, mobile operators	~35-45% global adoption (2025)
Latency Overhead	~0,1-0,5ms (negligible)	~1-5ms (extra hop)	0ms (no translation)

2.2 Visual: Perbedaan Arsitektur

TRADITIONAL NAT (NAT44):
                         CPE Router
User A ──── 192.168.1.0/24 ────→ [NAT] ──── 203.0.113.1 ────→ Internet
                                                              (Unique IP)
User B ──── 192.168.2.0/24 ────→ [NAT] ──── 203.0.113.2 ────→ Internet
                                                              (Unique IP)
Logging: CPE mau-log atau tidak. ISP tidak punya visibility.
Attribution: IP publik → satu rumah langsung.
 
 
CGNAT (NAT444):
                        CPE Router              CGN Gateway
User A ──── 192.168.1.0/24 ────→ [NAT] ──── 100.64.1.100 ────→ [CGN] ────→ Internet
                        CPE Router              │              203.0.113.10
User B ──── 192.168.2.0/24 ────→ [NAT] ──── 100.64.1.200 ────→ [CGN] ────→ Internet
                                                │
                                               CGNAT Logging:
                                                - Timestamp
                                                - Private IP:Port
                                                - Public IP:Port
                                                - Subscriber ID
                                                - NAT Session ID
 
Logging: WAJIB di CGN Gateway.
Attribution: IP publik saja TIDAK CUKUP. Butuh log CGN + 5-tuple.
 
 
NATIVE IPv6:
                                 No NAT
User A device ──── 2001:db8:1::a1 ────→ Internet
User B device ──── 2001:db8:2::b2 ────→ Internet
 
Logging: Tidak diperlukan untuk attribution.
Attribution: IP langsung = device spesifik.

2.3 Kenapa ISP Memilih CGNAT daripada IPv6 Saja?

Hambatan Adopsi IPv6:
 
1. Legacy Infrastructure:
   - Banyak CPE router lawas tidak support IPv6 dengan baik
   - ISP OSS/BSS system (billing, provisioning) belum siap IPv6
   - Content provider masih IPv4-only (long tail)
 
2. Cost & Complexity:
   - Migrasi IPv6 = investasi besar (hardware, training, testing)
   - Dual-stack = double routing table, double management overhead
   - CGNAT = "tambal ban" yang lebih murah dan cepat
 
3. Content Availability:
   - ± 35-40% dari Alexa Top 1000 masih IPv4-reachable only
   - CDN dan cloud provider sudah IPv6-ready → tapi long tail belum
 
→ Realita: CGNAT adalah solusi transisi yang menjadi permanen.
→ Banyak ISP Asia-Pasifik, Afrika, dan Amerika Latin 100% CGNAT.

3. Mekanisme Logging CGN

3.1 Arsitektur Logging CGNAT

[CPE Router]
    │  ┌─── Syslog / RADIUS ───┐
    ▼  ▼                        │
[CGN Gateway] ──── IPFIX/NetFlow ────→ [Central Log Collector]
    │                                     │ ELK / Splunk / custom
    │  ┌─── Accounting Data ───┐          │
    ▼  ▼                       ▼          ▼
[RADIUS Server]            [Syslog-ng/rsyslog]
    │                          │
    ▼                          ▼
[Billing DB]             [CGNAT Log DB]
                             │
                             ▼
                    [Query Interface — API/CLI]
                         ↑ Untuk: Law Enforcement,
                           Incident Responder, Abuse Desk

3.2 Teknik Port Block Allocation (RFC 6888 Section 8)

CGNAT tidak mengalokasikan port secara acak. Ada beberapa strategi:

A. Random Port Allocation (default most CGNAT):
   - Setiap session baru diberi port acak dari pool
   - Logging: SETIAP session harus di-log
   - Kelebihan: sulit ditebak, fair sharing
   - Kekurangan: log volume BESAR (milyaran row/hari untuk ISP besar)
 
B. Port Block Allocation (Deterministic — RFC 7422):
   - Setiap pelanggan mendapat blok port tetap: misal 1024-2047
   - Mapping: subscriber_id → port_range → public_ip
   - Logging: cukup log alokasi blok (bukan per session)
   - Penghematan log: 99,9% lebih kecil dari random allocation
   - Kelemahan: predictable — attacker bisa spoof port range
 
C. Hybrid:
   - Blok port dialokasikan, tapi port dalam blok dipakai acak
   - Logging: alokasi blok + sampling session
   - Trade-off antara traceability dan privacy
 
Contoh Port Block per Subscriber:
┌─────────────────────────────────────────────────────┐
│  CGN Public IP: 203.0.113.10  (pool size: 1 IP)     │
│                                                      │
│  Subscriber A → port block: 1024-3071  (2048 port)   │
│  Subscriber B → port block: 3072-5119  (2048 port)   │
│  Subscriber C → port block: 5120-7167  (2048 port)   │
│  Subscriber D → port block: 7168-9215  (2048 port)   │
│  ...                                                  │
│  Total: ~32 subscriber per IP (@ 2048 port/sub)       │
└─────────────────────────────────────────────────────┘

3.3 Log Entry CGNAT — Field Minimal (RFC 6888 Section 14)

RFC 6888 mensyaratkan log minimal berisi:

Field	Contoh	Deskripsi
Timestamp	2025-07-02T14:30:00.123Z	Waktu session NAT dibuat (wajib UTC+NTP sync)
Protocol	TCP=6, UDP=17, ICMP=1	L4 protocol (IP protocol number)
Inside (Private) IP	100.64.1.100	IP asli pelanggan di CGN space (RFC 6598)
Inside Port	34512	Source port asli dari pelanggan
Outside (Public) IP	203.0.113.10	IP publik yang dishare
Outside Port	1024	Port publik yang dialokasikan
Remote IP	198.51.100.20	IP tujuan eksternal (destination)
Remote Port	443	Port tujuan eksternal
Subscriber Identifier	user@isp.com / PPPoE session ID	Identitas pelanggan dari RADIUS/AAA

3.4 Cara Kerja 5-Tuple Binding di CGNAT

5-Tuple = {Source IP, Source Port, Dest IP, Dest Port, Protocol}
 
CGNAT Translation Process:
 
1. User (100.64.1.100:34512) → Request ke server (198.51.100.20:443)
2. CGNAT Gateway terima:
   - Inside: {100.64.1.100, 34512, 198.51.100.20, 443, TCP}
3. CGNAT buat binding:
   - Outside: {203.0.113.10, 1024, 198.51.100.20, 443, TCP}
   - Simpan di session table (5-tuple mapping)
4. Buat log entry:
   - Timestamp: T1
   - Inside: 100.64.1.100:34512
   - Outside: 203.0.113.10:1024
   - Remote: 198.51.100.20:443
   - Subscriber: USER-A
5. Forward paket ke internet dengan source {203.0.113.10:1024}
6. Response balik ke 203.0.113.10:1024 → CGNAT lookup session table
   → Forward ke 100.64.1.100:34512
7. Saat session berakhir (FIN / timeout) → optional END log
 
PENTING:
- 5-tuple harus UNIK dalam satu waktu di CGNAT
- Konflik port dicegah: jika port sudah dipakai, pilih port lain
- Total concurrent session per CGNAT gateway: jutaan
- Session timeout: TCP=~5 menit (idle), UDP=~2 menit (RFC 4787)

3.5 Sumber Logging Lain

Selain CGNAT Gateway sendiri, ada sumber data tambahan:

Sumber Data	Protokol/Format	Data yang Dihasilkan	Digunakan Untuk
RADIUS Accounting	RADIUS (RFC 2866)	PPPoE session start/stop, IP assignment, username, framing IP, session ID, NAS-IP-Address, Acct-Input/Output-Octets	Korelasi subscriber identity dengan CGN inside IP
DHCP Lease Log	Syslog	MAC → IP binding, lease time, hostname, Option 82 (circuit ID, remote ID)	Menentukan perangkat spesifik dalam satu rumah
PPPoE Session Log	Syslog	Username, session ID, access concentrator, physical port	Korreksi subscriber yang pindah CPE atau reconnect
Syslog dari CGN Device	Syslog / RFC 5424	NAT session create/delete, resource exhaustion, threshold crossing	Monitoring CGN health, forensik tambahan
IPFIX / NetFlow v9/v10	IPFIX (RFC 7011) / NetFlow	Flow record lengkap: 5-tuple, bytes, packets, start/end time, TCP flags	Threat hunting detail, traffic analysis
CGNAT Connection Table Dump	CLI/API per vendor	Current session snapshot (bukan historis)	Live forensik — cek siapa yang pakai port tertentu sekarang

4. Logging Compliance & Regulasi

4.1 Perbandingan Regulasi Global

Regulasi	Yurisdiksi	Persyaratan Logging CGNAT	Retention	Sanksi
GDPR + NGI (E-Privacy Directive / eIDAS)	Uni Eropa	Data retention directive: ISP wajib simpan log koneksi (termasuk CGNAT) minimal 6-12 bulan. Harus bisa korelasi IP → subscriber atas permintaan otoritas.	6-12 bulan	Denda hingga €20 juta atau 4% revenue global
FCC CPNI (47 CFR §64.2001-2011)	Amerika Serikat	Customer Proprietary Network Information protection. ISP boleh log untuk law enforcement. CALEA (Communications Assistance for Law Enforcement Act) — wajib provide intercept capability.	Variatif per state	FCC fine, revoke license
UU ITE + Permenkominfo No. 12/2016	Indonesia	Pasal 15 UU ITE: penyelenggara jasa telekomunikasi wajib menyimpan data komunikasi (termasuk IP assignment log) minimal 1 tahun. Permenkominfo 12/2016: logging wajib untuk antisipasi kejahatan siber.	Minimal 1 tahun	Pidana penjara, denda, pencabutan izin
Anti-Cybercrime Law	Global (ITU model)	Logging subscriber activity, IP assignment, timestamp for 6 months minimum	Variabel per negara	Administrative/criminal
Data Retention Directive	beberapa negara EU (sisa)	Setelah Schrems II dan kasus Tele2 Sverige, beberapa negara tetap pertahankan data retention untuk law enforcement	6-24 bulan	Constitutional challenge (beberapa dibatalkan)

TENSION: CGNAT Logging vs GDPR
 
GDPR Prinsip yang Terdampak:
├── Art. 5(1)(c) — Data Minimisation
│   └── Apakah logging SETIAP session NAT diperlukan?
│       ⟶ RFC 6888 bilang iya. GDPR bilang "cukup yang perlu."
│       ⟶ Solusi: Port Block Allocation (RFC 7422) — log hanya alokasi blok
│
├── Art. 5(1)(e) — Storage Limitation
│   └── Berapa lama log CGNAT disimpan?
│       ⟶ Umum 90 hari — 1 tahun (kompromi forensik vs privacy)
│       ⟶ Permenkominfo: 1 tahun minimal
│       ⟶ GDPR: harus ada justification — "legitimate interest" atau "legal obligation"
│
├── Art. 17 — Right to Erasure
│   └── Pelanggan minta hapus data CGNAT log-nya?
│       ⟶ Ditolak dengan dasar "legal obligation to retain"
│       ⟶ Tapi harus ada retention policy yang jelas dan transparan
│
└── Art. 5(2) — Accountability
    └── ISP harus bisa buktikan bahwa logging mereka:
        ⟶ Proporsional
        ⟶ Terbatas pada yang diperlukan
        ⟶ Diamankan dengan akses kontrol ketat

4.3 Regulasi Indonesia — Detail

Regulasi	Pasal	Isi Relevan
UU 19/2016 (Perubahan UU ITE)	Pasal 15	Penyelenggara sistem elektronik wajib rekam dan simpan data transaksi minimal 5 tahun — BUKAN untuk CGNAT spesifik
UU 36/1999 Telekomunikasi	Pasal 31	Operator wajib jaga kerahasiaan informasi pelanggan (tapi pengecualian untuk penegakan hukum)
Permenkominfo 12/2016	Pasal 7, 8, 9	Wajib log aktivitas pengguna termasuk IP assignment, timestamp, dan user identifier. Retention minimal 1 tahun
Permenkominfo 10/2017	—	Tata cara pemeriksaan sistem elektronik — termasuk permintaan data ke operator
UU ITE 2024 (revisi terbaru)	Pasal 40	Akses terhadap informasi elektronik untuk penegakan hukum — termasuk data komunikasi
PP 71/2019	—	Penyelenggaraan Sistem dan Transaksi Elektronik — perlindungan data pribadi

Catatan Praktisi

Di Indonesia, hampir semua ISP besar (Telkom, Indihome, First Media, MyRepublic, Biznet) menggunakan CGNAT untuk pelanggan rumah tangga. Attribution tanpa log CGNAT dari ISP hampir tidak mungkin di jaringan ini.

5. Attribution Challenges

5.1 Masalah Inti: Satu IP, Banyak User

Masalah Utama:
- Satu IP publik (203.0.113.10) bisa melayani 32-64 pelanggan
- Dalam 1 jam, ada ribuan concurrent session dari IP yang sama
- Port rotation membuat mapping stateless dari IP saja tidak berguna
- Waktu adalah dimensi kritis — "pukul berapa" sama pentingnya dengan "dari IP mana"
 
Ilustrasi:
203.0.113.10:1024  ─── Subscriber A ─── browsing, email, social media
203.0.113.10:3072  ─── Subscriber B ─── streaming Netflix
203.0.113.10:5120  ─── Subscriber C ─── torrenting
203.0.113.10:7168  ─── Subscriber D ─── mengakses situs ilegal
 
→ Dari IP publik saja: EMPAT user berbeda, SATU IP.
→ Bedanya: source port dan timestamp.
→ Tanpa log CGN: TIDAK BISA dibedakan.

5.2 Time-Based Correlation — Kompleksitas

Faktor yang Membuat Korelasi Waktu Sulit:
 
1. Clock Skew:
   - CGN Gateway, server target, dan log collector punya jam berbeda
   - Beda beberapa detik bisa menyebabkan salah attribution
   - Solusi: NTP sync dengan stratum yang sama
 
2. NAT Session Timeout:
   - Session TCP idle 5 menit → log END bisa telat
   - UDP session lebih pendek → mapping bisa hilang
   - Jika attacker cepat: session sudah selesai sebelum log tercatat
 
3. Concurrent Sessions:
   - Satu user bisa buka 50+ koneksi simultan
   - Membedakan mana koneksi "jahat" dari yang normal butuh pattern analysis
 
4. Port Randomization:
   - Random port allocation: tidak ada konsistensi port per user
   - Setiap session baru = port baru
   - Tidak bisa korelasi via port saja tanpa log
 
Contoh Kasus:
┌─────────────────────────────────────────────────────────────┐
│ Waktu: 14:30:00.000 - 14:30:00.500                          │
│ Public: 203.0.113.10:2048 → 198.51.100.1:443 (HTTPS bank)  │
│ Public: 203.0.113.10:2049 → 198.51.100.2:80 (HTTP forum)   │
│ Public: 203.0.113.10:2050 → 198.51.100.3:22 (SSH)          │
│                                                              │
│ Dua skenario:                                                │
│ A) Tiga koneksi = SATU user browsing web                     │
│ B) Tiga koneksi = TIGA user berbeda (CGNAT share)            │
│                                                              │
│ ⟶ Hanya CGNAT LOG yang bisa membedakan A vs B.              │
└─────────────────────────────────────────────────────────────┘

5.3 ISP Cooperation Latency

Proses Attribution via ISP — Timeline Realistis:
 
T+0    — Incident detected (log dari server korban/third-party)
T+30m  — Analis forensik ekstrak 5-tuple: 203.0.113.10:34567 → target:80
T+1h   — Permintaan resmi ke ISP (email/telepon/portal abuse)
T+4h   — ISP terima request, buka ticket internal
T+8h   — Tim NOC ISP cari log CGNAT (bisa lebih lama jika:
         - Ada beberapa CGN gateway
         - Log distributed di berbagai server
         - Rotasi log harian/mingguan
         )
T+12h  — Log ditemukan: subscriber ID = user@domain
T+18h  — RADIUS accounting: subscriber → nama pelanggan → alamat
T+24h  — Informasi diberikan ke peminta (jika sesuai regulasi)
T+48h+ — Jika waktu kejadian seminggu lalu: log mungkin sudah di-rotate
         Jika tidak ada: atribusi gagal total.
 
→ Latency tipikal: 6-24 jam untuk ISP yang siap (EU, US, JP).
→ Latency Indonesia: variatif — ada yang 2-3 hari.
→ Selama itu: attacker sudah move, IP bisa reuse.

5.4 CGNAT Case: Skenario Attribution Gagal

SCENARIO: Serangan DDoS dari Jaringan CGNAT
 
Korban menerima DDoS dari IP publik 203.0.113.50.
 
Analisis:
1. 203.0.113.50:34512 → SYN flood ke korban port 80
2. 203.0.113.50:34513 → SYN flood
3. 203.0.113.50:34514 → SYN flood
4. ... (ribuan port dari IP yang sama)
 
Masalah:
- 203.0.113.50 adalah IP CGNAT — milik 50+ pelanggan
- Semua port = dari pelanggan yang SAMA atau BEDA?
- Jika botnet: masing-masing port bisa dari device berbeda
- Jika single attacker: satu komputer, tapi port random
 
Solusi:
- CGNAT log: cek inside IP dari masing-masing port
- Jika semua port → 100.64.5.10 (satu inside IP) → satu komputer
- Jika port134512→100.64.5.10, port34513→100.64.5.11 → duakomputerberbeda
- Tapi: 100.64.5.10 dan 100.64.5.11 masih bisa dari rumah berbeda
- Butuh RADIUS log: subscriber identity masing-masing inside IP
 
→ Attribution gagal jika:
- Log sudah di-rotasi (>90 hari)
- RADIUS accounting tidak matching
- Subscriber menggunakan VPN/Tor di atas CGNAT

6. Mapping CGNAT Logs

6.1 Anatomi Log CGNAT — Format Vendor Berbeda

Format CGNAT Log — Cisco ASR 1000 Series (Syslog):
<134>2025-07-02T14:30:00.123Z CGN-GW-01: %CGNAT-6-SESSION: NAT
  inside=100.64.1.100:34512
  outside=203.0.113.10:1024
  remote=198.51.100.20:443
  protocol=TCP(6)
  subscriber=USER-A@telkom.net.id
  session-id=0x8A3F2C1B
  flags=NEW
 
Format CGNAT Log — Juniper MX Series (Syslog):
<14>Jul 2 14:30:00 CGN-GW-02 cgnat[1234]:
  CGNAT_SESSION_CREATE:
  subscriber="user-a@isp.net",
  inside_addr=100.64.1.100,
  inside_port=34512,
  outside_addr=203.0.113.10,
  outside_port=1024,
  remote_addr=198.51.100.20,
  remote_port=443,
  proto=6,
  nat_rule=CGN-POOL-01
 
Format CGNAT Log — Nokia/Alcatel-Lucent 7750 SR (Syslog):
<133>2025-07-02T14:30:00.123Z SR-01 LSN[5678]:
  LargeScaleNAT: Session Event
  Sub = "pppoe:user-a@telkom"
  Inside = 100.64.1.100:34512
  Outside = 203.0.113.10:1024
  Remote = 198.51.100.20:443
  Protocol = TCP
  Direction = Forward
  Policy = LSN_POLICY_1
 
Format IPFIX Record (Template-based, binary):
+---------+-----------+----------+-----------+----------+---------+----------+
| SRC_IP  | SRC_PORT  | DST_IP   | DST_PORT  | PROTOCOL | BYTES   | PACKETS  |
+---------+-----------+----------+-----------+----------+---------+----------+
| 100.64. | 34512     | 198.51.  | 443       | 6 (TCP)  | 1042    | 12       |
| 1.100   |           | 100.20   |           |          |         |          |
+---------+-----------+----------+-----------+----------+---------+----------+
| 203.0.  | 1024      | 198.51.  | 443       | 6 (TCP)  | 1042    | 12       |
| 113.10  |           | 100.20   |           |          |         |          |
+---------+-----------+----------+-----------+----------+---------+----------+

6.2 Proses Mapping — Dari IP Publik ke Individu

Chain of Attribution:
 
Langkah 1: Korban/Server mencatat IP publik
    ⟶ 203.0.113.10:1024 → 198.51.100.20:443  (Timestamp T1)
 
Langkah 2: Cari di CGNAT Log
    Query: WHERE outside_ip='203.0.113.10'
           AND outside_port='1024'
           AND timestamp ≈ T1 (± tolerance)
 
    Result: inside_ip='100.64.1.100'
            subscriber='USER-A@telkom.net.id'
            private_port='34512'
 
Langkah 3: Cari di RADIUS Accounting
    Query: WHERE framed_ip='100.64.1.100'
           AND acct_start <= T1
           AND acct_stop ≥ T1 OR acct_stop IS NULL
 
    Result: username='USER-A'
            calling_station_id='AA:BB:CC:DD:EE:FF'
            nas_port='Gi0/1/0:123'
            circuit_id='RT01-OLT02-PON1-ONU5'
 
Langkah 4: Cari di Database Pelanggan
    Query: WHERE username='USER-A'
           OR mac_address='AA:BB:CC:DD:EE:FF'
 
    Result: Nama = "Budi Santoso"
            Alamat = "Jl. Merdeka No. 42, Jakarta"
            ID Pelanggan = "TEL-12345678"
            Status = "Active — Fiber 50Mbps"
 
Langkah 5: Verifikasi (jika perlu)
    - Apakah ada pelanggan lain di IP yang sama pada T1?
    - Apakah ada anomaly di log yang bisa invalidate korelasi?
    - Cross-check dengan DHCP log untuk device spesifik
 
→ Hasil: IP publik + source port + timestamp → Identitas pelanggan
→ Confidence: Tinggi (jika log CGN lengkap dan akurat)

6.3 Tantangan Implementasi Log Join

Masalah yang Sering Muncul saat Join CGNAT Log + RADIUS:
 
× Time mismatch: CGNAT log pakai UTC, RADIUS pakai local time +7
× IP reuse: 100.64.1.100 bisa dipakai user A pagi, user B sore
× Subscriber ID tidak konsisten: "USER-A" vs "user-a@telkom.net.id" vs "TEL-12345678"
× RADIUS session overlap: user reconnect sebelum session lama timeout
× Log loss: CGNAT gateway overload → drop log packet (syslog UDP)
× CGNAT pool rotation: IP publik berganti karena pool tired
× NAT keepalive: koneksi idle tetap di table → log create tanpa matching log end
× Multi-vendor: format log berbeda antara CGN tier 1 dan tier 2
 
Best Practice:
├── NTP sync semua device ke source yang sama (ntp.isp.net)
├── Subscriber ID format standar: username@realm (dari RADIUS)
├── Syslog over TCP/TLS (RFC 5425, 5426) — jangan UDP untuk critical log
├── Log buffer di CGN device → kirim ke collector secara reliable
├── Correlation ID yang join CGNAT + RADIUS + DHCP (session-id yang sama)
└── Retention policy yang align dengan regulasi (min 1 tahun untuk Indonesia)

6.4 Query Manual — Contoh Pencarian Attribution

Skenario: Anda adalah analis forensik. Ada serangan dari 203.0.113.10:2048
ke server korban pada 2025-07-02 pukul 14:30:00 UTC.
 
Query di Log Collector (ELK/Splunk — pseudo):
 
# Langkah 1: Cari di CGNAT log
index=cgnat_logs
outside_ip="203.0.113.10"
outside_port="2048"
timestamp>="2025-07-02T14:29:55Z" AND timestamp<="2025-07-02T14:30:05Z"
| table timestamp, inside_ip, inside_port, subscriber_id, remote_ip, remote_port
 
# Result:
# 14:30:00.100 | 100.64.1.100 | 34512 | USER-A | 198.51.100.20 | 443
# 14:30:00.150 | 100.64.1.100 | 34513 | USER-A | 198.51.100.20 | 443
 
# Langkah 2: Verifikasi tidak ada overlap
index=cgnat_logs
outside_ip="203.0.113.10"
timestamp>="2025-07-02T14:29:00Z" AND timestamp<="2025-07-02T14:31:00Z"
| stats count by inside_ip
| sort -count
 
# Result:
# 100.64.1.100 → 142 sessions
# 100.64.1.150 → 5 sessions (beda user, sama IP publik)
 
# Langkah 3: Cari subscriber detail di RADIUS
index=radius_accounting
framed_ip="100.64.1.100"
timestamp>="2025-07-02T00:00:00Z" AND timestamp<="2025-07-02T23:59:59Z"
| table username, acct_start, acct_stop, calling_station_id, nas_port
 
# Result:
# USER-A | 2025-07-02T06:00:00Z | 2025-07-02T23:00:00Z | AA:BB:CC:DD:EE:FF | Gi0/1/0:123
# (Active session covers 14:30 UTC → confirmed)

7. Tools & Data Sources

7.1 Perbandingan Tools untuk Analisis CGNAT Log

Tool	Fungsi	Data Source	Kelebihan	Kekurangan
ELK Stack (Elasticsearch + Logstash + Kibana)	Centralized log search + dashboard	Syslog CGNAT, IPFIX, RADIUS	Query cepat, visualisasi, scale horizontal	Resource heavy, butuh dedicated team
Splunk	Log aggregation + SIEM	Semua log	Enterprise-grade, correlation search, alerting	Mahal (license per GB/day)
SILK (SiLK — System for Internet-Level Knowledge)	NetFlow/IPFIX analysis	Flow data dari router	Efisien, billion-record scale, command-line, open source	Tidak bisa baca syslog, flow-only
flow-tools (flow-capture, flow-print)	Legacy NetFlow collector	NetFlow v5/v9	Ringan, stabil, mature	Tidak support CGNAT-specific fields, outdated
nfdump / nfsen	NetFlow analysis	NetFlow v5/v9/v10, IPFIX	nfdump cepat filtering, nfsen punya web UI	Tidak handle syslog format
Logstash + filter CGNAT	Parse syslog CGNAT ke structured	Syslog dari berbagai vendor	Custom parsing fleksibel, grok filter	Butuh konfigurasi manual per vendor
Custom Python/Go script	Query CGNAT log + join RADIUS	Flat file atau API CGN logger	Full control, bisa handle format non-standar	Maintenance burden, no built-in dashboard
Grafana + Loki	Log aggregation + visualisasi	Syslog (via Promtail)	Lebih ringan dari ELK, grafana dashboard	Query tidak sekuat Elasticsearch
Wireshark / tshark	Packet-level analysis	PCAP dari mirror port CGN	Detil maksimal	Tidak scalable untuk jutaan session
Zeek (dengan CGNAT plugin)	Network monitoring + structured logging	Traffic dari mirror port	Log terstruktur otomatis	Tidak inline, perlu span port

7.2 Arsitektur Referensi — Centralized Log Collector

                    ┌──────────────────────────────────────┐
                    │          CGNAT Gateways               │
                    │  [Cisco ASR1K] [Juniper MX] [Nokia]   │
                    └──────────┬──────────────┬─────────────┘
                               │              │
                    Syslog TCP ┘              └── IPFIX/NetFlow v9
                               │              │
                               ▼              ▼
                    ┌──────────────────────────────────────┐
                    │         Log Collector Layer           │
                    │  [rsyslog] [syslog-ng] [nfcapd]       │
                    │  → Buffer: Kafka / Redis              │
                    └──────────┬────────────────────────────┘
                               │
                               ▼
                    ┌──────────────────────────────────────┐
                    │       Processing / Parsing Layer       │
                    │  Logstash / Vector / Fluentd           │
                    │  → Grok filter CGNAT                   │
                    │  → Normalize ke unified schema         │
                    │  → Enrich dengan RADIUS data           │
                    └──────────┬────────────────────────────┘
                               │
                               ▼
                    ┌──────────────────────────────────────┐
                    │        Storage / Indexing Layer        │
                    │  Elasticsearch / Loki / ClickHouse     │
                    │  → Index: timestamp, IP, port, sub ID  │
                    │  → Retention: hot 30d, warm 90d,       │
                    │    cold archive 1yr+                   │
                    └──────────┬────────────────────────────┘
                               │
                               ▼
                    ┌──────────────────────────────────────┐
                    │        Query / Visualization           │
                    │  Kibana / Grafana / custom API         │
                    │  → Dashboard monitoring CGNAT          │
                    │  → Incident Response search            │
                    │  → Law enforcement query portal        │
                    └──────────────────────────────────────┘
                               │
                               ▼
                    ┌──────────────────────────────────────┐
                    │      RADIUS / AAA Integration          │
                    │  [RADIUS Server]                       │
                    │  → Accounting data sync                │
                    │  → Subscriber identity lookup          │
                    │  → MAC → username → pelanggan          │
                    └──────────────────────────────────────┘

7.3 Informasi yang Diekstrak dari NetFlow/IPFIX untuk CGNAT

IPFIX adalah evolusi NetFlow v9 yang bisa membawa field spesifik CGNAT:

IPFIX Field ID	Field Name	Tipe	Deskripsi CGNAT
8	sourceIPv4Address	IPv4	Inside IP (100.64.x.x)
12	destinationIPv4Address	IPv4	Remote server IP
7	sourceTransportPort	uint16	Inside source port
11	destinationTransportPort	uint16	Remote port
4	protocolIdentifier	uint8	TCP/UDP/ICMP
2	packetDeltaCount	uint64	Paket dalam flow
1	octetDeltaCount	uint64	Bytes dalam flow
152	flowStartSeconds	timestamp	Session start
153	flowEndSeconds	timestamp	Session end
346	natInsideSrcAddr	IPv4	Post-NAT private IP (CGN specific)
347	natInsideSrcPort	uint16	Post-NAT private port
348	natOutsideSrcAddr	IPv4	Pre-NAT public IP (yang dishare)
349	natOutsideSrcPort	uint16	Pre-NAT public port
350	natInsideDstAddr	IPv4	Post-NAT private dest (jarang)
351	natInsideDstPort	uint16	Post-NAT private dest port
384	subscriberId	string	Subscriber identity (vendor-specific IE)

7.4 Contoh Konfigurasi Parsing CGNAT — Logstash Grok

# Cisco ASR 1000 CGNAT syslog → Logstash grok pattern
# Raw log example:
# <134>2025-07-02T14:30:00.123Z CGN-GW-01: %CGNAT-6-SESSION: NAT
#   inside=100.64.1.100:34512 outside=203.0.113.10:1024
#   remote=198.51.100.20:443 protocol=TCP(6)
#   subscriber=USER-A@telkom.net.id session-id=0x8A3F2C1B flags=NEW
 
grok {
  match => {
    "message" => [
      "<%{NUMBER:facility_severity}>%{TIMESTAMP_ISO8601:timestamp}
       %{HOSTNAME:cgw_hostname}: %%{DATA:cgntag}:
       NAT inside=%{IP:inside_ip}:%{NUMBER:inside_port}
       outside=%{IP:outside_ip}:%{NUMBER:outside_port}
       remote=%{IP:remote_ip}:%{NUMBER:remote_port}
       protocol=%{DATA:protocol_name}\(%{NUMBER:protocol_number}\)
       subscriber=%{DATA:subscriber}
       session-id=%{DATA:session_id}%{DATA:flags}"
    ]
  }
}
 
# Output ke Elasticsearch:
# {
#   "inside_ip": "100.64.1.100",
#   "inside_port": 34512,
#   "outside_ip": "203.0.113.10",
#   "outside_port": 1024,
#   "remote_ip": "198.51.100.20",
#   "remote_port": 443,
#   "protocol": "TCP",
#   "subscriber": "USER-A@telkom.net.id",
#   "session_id": "0x8A3F2C1B",
#   "flags": "NEW",
#   "timestamp": "2025-07-02T14:30:00.123Z"
# }

8. Case Studies

8.1 E-Crime Takedown — IP Convergence Analysis (Europol)

Konteks: Operation Icarus (Europol 2023-2024)
Target: Dark web marketplace yang menggunakan bot CGNAT proxy untuk
        menyembunyikan identity admin.
 
Metode Attribution:
┌─────────────────────────────────────────────────────────────┐
│ 1. Analis ekstrak semua IP yang mengakses panel admin       │
│    selama 3 bulan via server access log.                    │
│                                                              │
│ 2. IP publik = 64 IP berbeda dari 12 ISP di 5 negara.       │
│    Semua IP adalah CGNAT IP — tidak bisa langsung traced.    │
│                                                              │
│ 3. Teknik: IP Convergence —                                │
│    a. Ambil semua IP publik yang muncul                       │
│    b. Cari CO-OCCURRENCE pattern:                            │
│       IP mana saja yang muncul bersamaan dalam waktu singkat │
│    c. Gunakan graph analysis: node=IP, edge=co-occurrence    │
│                                                              │
│ 4. Hasil: dari 64 IP, 52 IP adalah noise (user biasa),       │
│    tapi 12 IP menunjukkan pola aneh:                          │
│    - Mereka muncul dari CGNAT pool yang SAMA terus           │
│    - Dalam 1 jam, multiple IP dari pool yang sama            │
│    - Ini adalah teknik: admin paksa reconnect → dapat IP baru│
│                                                              │
│ 5. Setelah IP convergence: 12 IP → 2 subscriber dari         │
│    ISP Nordik (melalui CGNAT log).                           │
│    - Satu subscriber = admin marketplace                     │
│    - Satu subscriber = hosting server                        │
│                                                              │
│ 6. Takedown: 2 pelaku ditangkap, marketplace seized.         │
└─────────────────────────────────────────────────────────────┘
 
Key Takeaway: CGNAT bukan penghalang absolut. Dengan analisis
co-occurrence dan convergence, pola tersembunyi bisa diungkap.

8.2 APT C2 Identification via CGNAT Correlation (Volexity 2022)

Konteks: APT group (diyakini China-linked) menggunakan compromised
home router di Indonesia sebagai C2 proxy.
 
Latar Belakang:
- Volexity menemukan beacon dari IP publik Indonesia (180.240.x.x)
  ke server C2 di Rusia
- IP adalah CGNAT IP milik ISP besar Indonesia
- Target: perusahaan financial di Singapura
 
Tantangan:
- Satu IP publik dipakai 48 pelanggan
- Beacon traffic tidak konsisten — muncul 5-10 menit, hilang berjam-jam
- Tidak bisa bedakan mana beacon dan mana traffic normal
 
Pendekatan:
┌─────────────────────────────────────────────────────────────┐
│ 1. Analisis timing:                                        │
│    - Traffic beacon terjadi setiap Selasa & Kamis jam 14:00 │
│    - Tidak pernah di weekend                                 │
│    → BUKAN pola bot biasa (bot 24/7)                        │
│    → Curigakan: compromised device indoor                    │
│                                                              │
│ 2. CGNAT log analysis:                                      │
│    - Extraksi semua session dari IP publik saat beacon       │
│    - Filter: yang connect ke IP Rusia saja                   │
│    - Dapatkan inside IP: 100.64.3.45                        │
│    - Cek: apakah inside IP yang SAMA untuk semua beacon?     │
│    ⟶ Ya! Semua beacon dari 100.64.3.45                       │
│    → Bisa dipastikan satu device                             │
│                                                              │
│ 3. RADIUS + DHCP:                                           │
│    - 100.64.3.45 → subscriber "FULLNAME@domain"             │
│    - MAC = TP-Link router murah                              │
│    - Tidak ada VPN atau Tor di sisi subscriber               │
│    → APT compromise router CPE user biasa                     │
│                                                              │
│ 4. Remediasi:                                               │
│    - ISP disconnect subscriber                              │
│    - Notifikasi ke pemilik: router compromised               │
│    - C2 server sinkhole oleh CERT                            │
└─────────────────────────────────────────────────────────────┘
 
Key Takeaway: CGNAT log + timing correlation adalah kunci untuk
mengidentifikasi beacon APT di belakang shared IP.

8.3 Kasus Indonesia — Keterbatasan Attribution di Jaringan Nasional

Skenario Disadur dari Berita Publik (2023-2024):
 
Seorang pelaku mengirimkan ancaman pembunuhan via email
anonymous (ProtonMail → Tor → CGNAT WiFi publik).
 
Alur Forensik:
1. Email header: IP publik 36.68.x.x (Telkomsel)
2. Timestamp: 2024-01-15 10:23 WIB (UTC+7)
3. Request ke ISP (Telkomsel):
   - "Tolong cari log CGNAT dari IP 36.68.x.x pada jam 10:23"
4. Respon ISP:
   - "Data perlu waktu. Dasar hukum? Surat?"
   - "Format permintaan harus melalui Data Protection Officer"
   - "Diarsipkan, kami cek dulu"
 
Hasil Forensik (setelah 2 minggu):
┌─────────────────────────────────────────────────────────────┐
│ ✓ Log CGNAT ditemukan:                                      │
│   36.68.x.x: 45000 → 10.0.0.1:34567                        │
│   ✓ Subscriber ID = "ANONYM"                                 │
│   × Nama asli: TIDAK ADA (prepaid card, registrasi fiktif)  │
│   × Lokasi: TIDAK AKURAT (BTS triangulation = ±500m)       │
│   × Device: TIDAK TAHU (hidden di dalam CGNAT)              │
│   × WiFi publik: hotspot di mall — tidak ada login system   │
│                                                              │
│ ⟶ Dead end: CGNAT + prepaid + WiFi publik + Tor             │
└─────────────────────────────────────────────────────────────┘
 
Key Takeaway: CGNAT sendirian sudah menyulitkan. Ditambah
anonimisasi berlapis (Tor, prepaid, public WiFi) → attribution
mendekati impossible tanpa intelijen tambahan.

8.4 Insider Threat — Attribution via Port Block Consistency

Konteks: Perusahaan mendeteksi data exfiltration dari employee
yang menggunakan corporate VPN (which then goes through CGNAT
from home ISP).
 
Kasus:
- Employee melakukan exfil via corporate VPN → dari rumah pribadi
- VPN log menunjukkan: session dari IP publik 114.124.x.x
- IP publik = CGNAT milik Indihome
- 50+ pelanggan di IP yang sama → siapa?
 
Metode:
┌─────────────────────────────────────────────────────────────┐
│ Analisis Port Block:                                        │
│                                                              │
│ Dari VPN log:                                                │
│  114.124.x.x: 14320 → VPN server 443 (setiap hari jam 18:00) │
│  114.124.x.x: 14322 → VPN server 443                          │
│  114.124.x.x: 14325 → VPN server 443                          │
│  (port range 14320-14350 konsisten)                          │
│                                                              │
│ Cek CGNAT log:                                                │
│  Port 14320-14350 adalah dalam satu port block               │
│  Port block milik: inside IP 100.64.2.50                     │
│  Subscriber: employee_nik@company.com                        │
│  → Konfirmasi: employee tertentu                             │
│                                                              │
│ Tambahan:                                                     │
│  - VPN session di jam kerja = employee sedang WFH            │
│  - Volume exfil = 2GB/hari → tidak wajar                     │
│  - CGNAT log juga menunjukkan akses ke cloud storage         │
│    (Google Drive pribadi) via port lain dalam blok yang sama │
│  → Pattern: exfil terjadi setiap hari selama 3 minggu        │
│                                                              │
│ ⟶ Attribution sukses karena port block consistency.          │
└─────────────────────────────────────────────────────────────┘
 
Key Takeaway: Port Block Allocation (RFC 7422) MEMUDAHKAN attribution
karena port range konsisten per subscriber.

9. Privacy Dual-Use

9.1 CGNAT sebagai Privacy Layer (Accidental Privacy)

CGNAT secara tidak sengaja memberikan privacy benefit:
 
✅ Identitas tersembunyi secara default
   - Satu IP publik = puluhan/tibuan user
   - Tidak bisa dibedakan dari log server target saja
   - Efek: CGNAT = NAT anonimitas built-in
 
✅ Anti-tracking alami
   - Pelacak (ad networks, analytics) melihat IP publik yang dishare
   - Tidak bisa fingerprint individu dari IP saja
   - Catatan: masih bisa via cookie, browser fingerprint, dll
 
✅ Mempersulit data broker
   - Data broker (seperti jumlah, lokasi dari IP) tidak akurat untuk user CGNAT
   - Lokasi geografis di level BTS/kota, bukan rumah spesifik
 
✅ Cross-session isolation
   - Setiap reconnect CPE bisa dapat port block berbeda
   - Pelacakan jangka panjang lebih sulit via IP saja
 
❌ TAPI: Ini adalah privacy yang rapuh
   - Hanya IP-based tracking yang terhalang
   - Cookie, browser fingerprint, email tracking tetap jalan
   - ISP masih tahu SEMUA aktivitas (karena punya CGNAT log)
   - Law enforcement dengan otoritas masih bisa trace

9.2 CGNAT sebagai Hambatan Incident Response

❌ IR Teams:
 
➊ Waktu adalah musuh
   - Setiap jam yang terbuang = attacker lebih jauh
   - ISP memiliki SLA 6-24 jam untuk log CGNAT
   - Log mungkin sudah di-rotate (90 hari → tidak ada untuk kasus lama)
 
➋ Tidak semua ISP punya CGNAT logging
   - ISP kecil mungkin tidak mengaktifkan logging (biaya storage besar)
   - Beberapa ISP menggunakan CGNAT appliance murah tanpa fitur log
   - → Forensik tidak bisa dilanjutkan
 
➌ Format log tidak standar
   - Setiap vendor punya format berbeda
   - Join antara CGNAT log + RADIUS + DHCP sering bermasalah
   - Enterprise SIEM mungkin tidak punya parser CGNAT
 
➍ Permission & Legal Barrier
   - Di beberapa negara, ISP tidak bisa berikan data tanpa surat resmi
   - Proses legal bisa memakan waktu berhari-hari
   - Incident window: attack terjadi, attribution datang setelah damage
 
➎ Overhead Storage
   - ISP besar: 10-50 milyar log entry per hari
   - Storage cost tinggi → retention diperpendek
   - Kompresi lossy (sampling) → data tidak lengkap

9.3 Tabel: Keseimbangan Privacy vs Forensik

Aspek	Privacy Advocate View	Law Enforcement/IR View
CGNAT logging	Mass surveillance — ISP catat semua aktivitas warga	Essential for attribution — tanpa log, kejahatan tidak bisa dilacak
Data retention (90-365 hari)	Pelanggaran privacy, chilling effect	Minimal waktu untuk investigasi kejahatan kompleks
Port Block Allocation	Predictable → memudahkan fingerprinting	Memudahkan attribution tanpa log per-session
Deterministic mapping	Identitas permanen tersembunyi di IP publik	Korelasi lebih cepat untuk repeat offender
Real-time CGNAT query	Privacy nightmare — ISP bisa lacak real-time	Wajib untuk incident response yang responsif
Anonymization layer (Tor/VPN di atas CGNAT)	Hak fundamental untuk privacy digital	Tanda merah aktivitas kriminal — semakin banyak lapisan anonim, semakin mencurigakan

9.4 Rekomendasi Keseimbangan

Pendekatan yang Seimbang:
 
1. Logging Proporsional:
   - Log minimal: cukup untuk attribution (IP, port, timestamp, subscriber)
   - Jangan log payload atau konten komunikasi
   - Anonimisasi agregat untuk analisis non-forensik
 
2. Retention Terbatas:
   - 90 hari untuk data detail (session-level)
   - 1 tahun untuk data minimal (subscriber ↔ IP mapping, tanpa port)
   - Hapus otomatis setelah masa retention
 
3. Akses Ketat:
   - Log CGNAT hanya bisa diakses oleh:
     a. Tim NOC/abuse ISP (untuk operational)
     b. Law enforcement dengan surat resmi
     c. Incident responder dengan NDA dan SLA
   - Audit trail untuk setiap akses log
 
4. Transparansi:
   - Pelanggan berhak tahu bahwa ISP melakukan logging
   - Privacy policy yang jelas tentang retention dan akses
   - Opsi untuk menggunakan VPN/Tor jika menginginkan privacy ekstra
 
5. Alternatif Teknis:
   - Port Block Allocation (RFC 7422) sebagai pengganti full logging
   - NAT64/DNS64 untuk mengurangi ketergantungan pada IPv4 CGNAT
   - IPv6 native → eliminasi kebutuhan CGNAT sama sekali

10. Alternatif & Evolusi Teknologi

10.1 Perbandingan Alternatif CGNAT

Teknologi	Mekanisme	IPv6 Support	Logging Requirement	Adoption
CGNAT (NAT444)	PAT/shared IP — translation	Tidak langsung	WAJIB (RFC 6888)	Dominan di Asia, Afrika, LATAM
NAT64 + DNS64	IPv6-only client → IPv4 internet via translation	Side-by-side	Sama dengan CGNAT	Operator mobile (T-Mobile US, Telstra)
DS-Lite (RFC 7596)	IPv6 tunnel + CGNAT element	IPv6 native, IPv4 via tunnel	Sama dengan CGNAT	European operators (Deutsche Telekom, Free FR)
MAP-E (RFC 7597)	Encapsulation — IPv4-in-IPv6 tunnel	IPv6 native	Lebih rendah (deterministic mapping)	Softbank JP, Comcast US
MAP-T (RFC 7599)	Translation — IPv4 ↔ IPv6 (similar NAT64)	IPv6 native	Lebih rendah (deterministic)	Emerging — belum banyak deployed
LISP (RFC 6830)	Locator/ID separation — routing overlay	Bisa dual-stack	Berbeda: LISP mapping system	Enterprise/Campus, bukan residential
Pure IPv6	No NAT at all — every device has global address	NATIF	Tidak diperlukan	Nordics (DK, SE), US mobile, India (Reliance Jio)
464XLAT (RFC 6877)	CLAT+PLAT — client-side NAT64	IPv6-only client	Sama dengan CGNAT (PLAT side)	Android default, T-Mobile US massive deployment

10.2 Visual: Perbedaan Arsitektur Alternatif

DS-Lite:
[CPE] ─── IPv6-only WAN ───→ [AFTR (ISP)] ─── IPv4 Internet
   │                            │
   └──• IPv4 traffic → tunnel ke AFTR
      • AFTR melakukan CGNAT
      • Logging: AFTR side (sama dengan CGNAT)
   └──• IPv6 traffic → langsung ke IPv6 internet
 
 
MAP-E:
[CPE] ─── IPv6-only WAN ───→ [BR (ISP)] ─── IPv4 Internet
   │                            │
   └──• Port mapping DETERMINISTIK
      • Setiap CPE dapat blok port tetap (PSID = Port Set ID)
      • Tidak perlu session-level logging
      • Cukup log alokasi PSID
   └──• Contoh: PSID = 4 (port range 4096-6143)
      • 100 pelanggan dalam satu IP publik
      • Tapi setiap pelanggan punya port range tetap
 
 
NAT64 + DNS64:
[Client IPv6-only] ──→ [NAT64 Gateway] ──→ IPv4 Internet
   │                      │
   └──• DNS64: A query → synthesizes AAAA from IPv4 → client dpt IPv6
      • Client kirim packet ke IPv6 prefix NAT64 (64:ff9b::/96)
      • NAT64 translate IPv6 → IPv4
      • Logging: NAT64 gateway (mirror CGNAT)
 
 
464XLAT:
[Client] ──→ [CLAT (mobile/CPE)] ──→ [PLAT (ISP)] ──→ IPv4 Internet
   │            │                      │
   └──• CLAT: translate IPv4 → IPv6 (via NAT46)
      • PLAT: translate IPv6 → IPv4 (via NAT64)
      • Overall: client experience seperti NAT saja
      • BUT: CLAT di device, PLAT di ISP
      • Logging: PLAT side — sama dengan CGNAT

10.3 Mengapa IPv6 adalah Solusi Final

IPv6 = Address Abundance = No NAT Needed
 
Mengapa CGNAT tidak ideal:
× Single point of failure — jika CGN gateway down, ribuan pelanggan offline
× Performance bottleneck — semua traffic harus melalui NAT processor
× Logging overhead — storage, processing, compliance
× Application breakage — P2P, VoIP, gaming, VPN (IPsec, IKE)
× Troubleshooting complexity — menentukan "siapa" dari "IP mana"
× Privacy paradox — ISP punya log lengkap, tapi IR team tidak bisa akses cepat
 
IPv6 mengeliminasi semua masalah ini:
✓ Setiap device punya global unique address (2001:db8::/32 range)
✓ No NAT table, no port sharing, no logging untuk attribution
✓ End-to-end connectivity — P2P, VoIP, gaming work natively
✓ Troubleshooting — IP langsung = device langsung
✓ Privacy via Privacy Extensions (RFC 4941, RFC 8981):
  - Temporary addresses: berubah setiap 24 jam
  - Mencegah tracking via MAC-based IPv6 (EUI-64)
 
Tapi IPv6 punya masalah sendiri:
× Monitoring: IPv6 address space sangat besar → scanning attack surface besar
× Security: filter incoming connection harus lebih ketat (no NAT firewall)
× Transition: dual-stack selama bertahun-tahun
× Logging tetap diperlukan untuk law enforcement — bedanya lebih sederhana
 
Realisasi Industri (2025):
[         CGNAT dominant         ]──────→[      CGNAT + IPv6 dual      ]──────→[     IPv6 dominant    ]
  Asia, Afrika, LATAM now               Europe, US now             Nordics, Jio, T-Mobile US
 
→ Target: IPv6-only world → CGNAT hanya kenangan.
→ Realita: 10-20 tahun lagi sebelum itu terjadi.

10.4 Tabel: Dampak Setiap Alternatif terhadap Forensik

Alternatif	Attribution Complexity	Log Volume	IR Speed	Privacy Impact
CGNAT (NAT444)	Tinggi — butuh join CGN log + RADIUS	Sangat tinggi (miliaran/hari)	Lambat — 6-24 jam	Rendah — ISP tahu semuanya
CGNAT + Port Block	Sedang — cukup cek port range	Rendah (hanya alokasi blok)	Sedang — 1-4 jam	Sedang — predictable range
DS-Lite	Tinggi — AFTR log + RADIUS	Tinggi	Lambat	Rendah
MAP-E	Rendah — deterministic port mapping (PSID)	Rendah (hanya PSID allocation)	Cepat — 30 menit	Sedang — PSID tetap
MAP-T	Rendah — sama dengan MAP-E	Rendah	Cepat	Sedang
NAT64	Tinggi — gateway NAT64 log	Tinggi	Lambat	Rendah
464XLAT	Sedang — PLAT side log	Sedang	Sedang	Rendah
Pure IPv6	Sangat rendah — IP langsung = device	Minimal (DHCPv6 log saja)	Cepat — real-time	Sedang — privacy extension
CGNAT + VPN/Tor	Sangat tinggi — CGNAT hanya layer 1 dari banyak	CGNAT log tidak berguna sendiri	Sangat lambat	Tinggi — user anonim

11. Bottom Line

Bottom Line

CGNAT adalah realita pahit yang harus dihadapi praktisi keamanan jaringan. Di satu sisi, CGNAT memperpanjang umur IPv4 dan memungkinkan konektivitas global di tengah kelangkaan alamat IP. Di sisi lain, CGNAT adalah musuh terbesar attribution forensik — mengaburkan identitas pelaku di balik IP publik yang dishare oleh puluhan pelanggan.

Takeaway Kunci untuk Threat Hunter & Analis Forensik:

IP publik saja TIDAK CUKUP untuk attribution di era CGNAT. Selalu butuh 5-tuple lengkap (IP:port source & destination + protocol + timestamp).

Log CGNAT adalah sumber truth — tanpa akses ke CGNAT log ISP, attribution berhenti di IP publik.

Waktu adalah musuh — setiap jam delay mengurangi probabilitas log masih tersedia.

Port Block Allocation (RFC 7422) adalah teman terbaik forensik — port range konsisten per subscriber memudahkan korelasi tanpa log super-detail.

Regulasi retention bervariasi per negara — 90 hari sampai 5 tahun. Kenali yurisdiksi ISP yang berurusan dengan kasus kamu.

IPv6 adalah solusi final — CGNAT hanya tambal ban. Native IPv6 menghilangkan masalah attribution sama sekali.

VPN/Tor di atas CGNAT = attribution wall yang sangat sulit ditembus tanpa intelijen tambahan.

Referensi & Cross-References Vault

Lihat Juga

network-security — OSI Layer model, CGNAT ada di Layer 3

ids-ips-waf-nsm-comparison — Tools untuk monitoring jaringan, termasuk analisis flow & CGNAT logging

arp-spoofing-incident-addendum — Contoh incident forensik di Layer 2, metodologi berbeda dengan CGNAT attribution

threat-hunting-methodology — Threat hunting framework dengan data source CGNAT log

logging-compliance-guide — Panduan retention log sesuai regulasi Indonesia

ipv6-migration — Migrasi IPv6 dan dampaknya terhadap security monitoring

Note ini adalah living document. CGNAT terus berkembang seiring migrasi IPv6 dan munculnya regulasi baru. Last updated: 2025-07-02

Azhar's Notes

Navigation

CGNAT & IP Attribution Deep Dive

🕸️ CGNAT & IP Attribution — Carrier-Grade NAT, Logging, dan Dampaknya terhadap Forensik Jaringan

Daftar Isi

1. Pendahuluan: Apa itu CGNAT?

1.1 Mengapa CGNAT Ada?

1.2 Arsitektur Dasar CGNAT (NAT444)

1.3 RFC yang Relevan

2. Perbandingan: CGNAT vs Traditional NAT vs IPv6

2.1 Tabel Perbandingan

2.2 Visual: Perbedaan Arsitektur

2.3 Kenapa ISP Memilih CGNAT daripada IPv6 Saja?

3. Mekanisme Logging CGN

3.1 Arsitektur Logging CGNAT

3.2 Teknik Port Block Allocation (RFC 6888 Section 8)

3.3 Log Entry CGNAT — Field Minimal (RFC 6888 Section 14)

3.4 Cara Kerja 5-Tuple Binding di CGNAT

3.5 Sumber Logging Lain

4. Logging Compliance & Regulasi

4.1 Perbandingan Regulasi Global

4.2 Implikasi GDPR Terhadap Logging CGNAT

4.3 Regulasi Indonesia — Detail

5. Attribution Challenges

5.1 Masalah Inti: Satu IP, Banyak User

5.2 Time-Based Correlation — Kompleksitas

5.3 ISP Cooperation Latency

5.4 CGNAT Case: Skenario Attribution Gagal

6. Mapping CGNAT Logs

6.1 Anatomi Log CGNAT — Format Vendor Berbeda

6.2 Proses Mapping — Dari IP Publik ke Individu

6.3 Tantangan Implementasi Log Join

6.4 Query Manual — Contoh Pencarian Attribution

7. Tools & Data Sources

7.1 Perbandingan Tools untuk Analisis CGNAT Log

7.2 Arsitektur Referensi — Centralized Log Collector

7.3 Informasi yang Diekstrak dari NetFlow/IPFIX untuk CGNAT

7.4 Contoh Konfigurasi Parsing CGNAT — Logstash Grok

8. Case Studies

8.1 E-Crime Takedown — IP Convergence Analysis (Europol)

8.2 APT C2 Identification via CGNAT Correlation (Volexity 2022)

8.3 Kasus Indonesia — Keterbatasan Attribution di Jaringan Nasional

8.4 Insider Threat — Attribution via Port Block Consistency

9. Privacy Dual-Use

9.1 CGNAT sebagai Privacy Layer (Accidental Privacy)

9.2 CGNAT sebagai Hambatan Incident Response

9.3 Tabel: Keseimbangan Privacy vs Forensik

9.4 Rekomendasi Keseimbangan

10. Alternatif & Evolusi Teknologi

10.1 Perbandingan Alternatif CGNAT

10.2 Visual: Perbedaan Arsitektur Alternatif

10.3 Mengapa IPv6 adalah Solusi Final

10.4 Tabel: Dampak Setiap Alternatif terhadap Forensik

11. Bottom Line

Referensi & Cross-References Vault

Tampilan Grafik

Daftar Isi