Apakah data selalu dienkripsi dalam komunikasi IPv6?


30

Saya sepertinya tidak bisa mendapatkan jawaban langsung atas pertanyaan ini. Wikipedia mengatakan "IPsec adalah bagian integral dari paket protokol dasar dalam IPv6," tetapi apakah itu berarti bahwa SEMUA komunikasi selalu dienkripsi, atau apakah itu berarti enkripsi adalah opsional, tetapi perangkat harus dapat memahaminya (harus digunakan )?

Jika enkripsi bersifat opsional, apakah ini sistem operasi yang memutuskan apakah akan menggunakan enkripsi, ataukah aplikasi? Apakah sistem operasi dan perangkat lunak yang populer umumnya memungkinkan enkripsi?

Saya akan menyelidiki ini sendiri, tetapi saya tidak memiliki konektivitas IPv6.

Perbarui: Oke, jadi opsional. Pertanyaan tindak lanjut saya: biasanya, apakah aplikasi yang menentukan apakah akan menggunakan enkripsi, atau apakah itu sistem operasi?

Contoh spesifik: Bayangkan saya memiliki versi Windows terbaru dengan dukungan IPV6 asli, dan saya mencari sesuatu di ipv6.google.com menggunakan Mozilla Firefox. Apakah akan dienkripsi?


16
IPSec seperti kunci di pintu; itu mungkin bagian dari pintu, tetapi itu tidak berarti pintu itu harus dikunci.
Chris S

@ Chris S: Komentar yang luar biasa, Anda memiliki suara saya untuk itu.
SplinterReality

Jawaban:


31

Tidak.

IPv6 memiliki built-in IPsec sebagai bagian dari protokol, dan itu bukan baut seperti halnya dengan IPv4. Namun, ini tidak berarti itu diaktifkan secara default, itu hanya berarti itu adalah (secara teoritis) overhead yang lebih rendah pada tumpukan jaringan.

Secara umum, penggunaan IPsec ditentukan pada tingkat IP dari tumpukan jaringan, dan karenanya ditentukan oleh kebijakan sistem itu sendiri. mis. Sistem A mungkin memiliki kebijakan yang mengharuskan AH dan ESP untuk berkomunikasi dengan subnet 4.0.0.0/8.

Perbarui: untuk menjadi jelas, aplikasi tidak peduli - itu hanya tahu itu harus membuka koneksi jaringan di suatu tempat dan mengirim / menerima data ke bawah itu. Sistem kemudian harus mencari tahu apakah akan menegosiasikan IPsec untuk koneksi yang diminta yang diberikan. IPsec sangat dirancang untuk menjadi mekanisme otentikasi / enkripsi tingkat rendah dan sengaja dibuat agar protokol dan aplikasi tingkat tinggi tidak perlu khawatir.

Yang mengatakan, itu hanya kontrol keamanan tingkat jaringan lain, dan tidak harus digunakan secara terpisah atau diandalkan untuk menjamin 'keamanan' - jika Anda mencoba untuk memecahkan dan mengotentikasi masalah, sangat mungkin Anda menginginkan aplikasi untuk menegakkan semacam otentikasi tingkat pengguna sementara meninggalkan otentikasi tingkat mesin turun ke IPsec.


1
Terima kasih karena telah menolak mitos populer yang mengerikan.
Marcin

3
Oh, hal-hal yang seharusnya. Mungkin kita akan mendapatkan ini di IPv8 dalam beberapa ratus tahun.
Michael Hampton

1
Saya tidak setuju - enkripsi harus selalu dimungkinkan, dan yang terbaik, sangat mudah. Mandat jenis kontrol keamanan tertentu terlepas dari keberadaan kontrol lain agak picik sehubungan dengan kasus penggunaan di mana Anda secara aktif tidak ingin enkripsi tingkat IP.
growse

20

Jawaban singkat: Tidak.

Jawaban panjang: IPsec dipertimbangkan ketika merancang IPv6, dalam arti bahwa, tidak seperti dalam IPv4, IPsec (saat digunakan) adalah bagian dari header IPv6.

Penjelasan lebih lanjut: di IPv4, IPsec berjalan di atas IP itu sendiri. Ini sebenarnya adalah protokol Layer 4 yang 'menyamar' sebagai protokol Layer 3 (sehingga protokol L4 biasa dari TCP dan UDP masih dapat bekerja). ESP (Encapsulating Payload Keamanan) tidak dapat menjangkau antara paket IP. Akibatnya, paket IPsec biasanya akan mengurangi kapasitas payload jika fragmentasi dicegah. Plus, karena itu di atas IP, header IP tidak dilindungi.

Dalam IPv6, IPsec adalah bagian dari IP itu sendiri. Itu dapat menjangkau paket, karena header ESP sekarang menjadi bagian dari header IP. Dan karena terintegrasi dengan IP, lebih banyak bagian dari header IP dapat dilindungi.

Saya harap penjelasan 'singkatnya' saya cukup jelas.


1
Sebenarnya, AH menandatangani seluruh paket, yang berarti tidak ada yang dapat diubah (mis. NAT merusaknya.) Inilah sebabnya mengapa sangat sedikit terowongan IPSec yang menggunakan AH. Dan itu adalah salah satu dari banyak header ekstensi , tidak secara harfiah "bagian dari header IP."
Ricky Beam

2

Untuk Anda Pertanyaan Tindak Lanjut:

Sistem operasi menentukan kapan harus menggunakan enkripsi. Opsi "kebijakan" ini berada dalam panel kontrol / kebijakan konfigurasi. Anda mengatakan hal-hal seperti "jika Anda ingin terhubung ke alamat apa pun di subnet ab12 :: Anda harus memiliki rahasia Blah1234". Ada opsi untuk menggunakan PKI.

Saat ini aplikasi tidak dapat menambah kebijakan ini atau menuntut kebijakan ini sudah diatur. Ada disebutkan di bagian soket ipv6 linux "dukungan IPSec untuk header EH dan AH hilang."


1

Untuk pertanyaan tindak lanjut Anda, ya dan tidak.

Aplikasi dapat menentukan enkripsi, tetapi enkripsi dilakukan pada tingkat aplikasi. Ada berbagai pasangan protokol yang tidak terenkripsi / terenkripsi menggunakan port yang berbeda seperti HTTP / HTTPS, LDAP / LDAPS, IMAP / IMAPS, dan SMTP / SSMTP. Ini semua menggunakan enkripsi SSL atau TLS. Beberapa layanan akan menawarkan opsi startTLS yang memungkinkan koneksi terenkripsi dimulai pada port yang biasanya tidak dienkripsi. SSH adalah aplikasi yang selalu menggunakan koneksi terenkripsi. Enkripsi ujung ke ujung untuk kasus ini. (Ada algoritma enkripsi NULL yang dapat digunakan, dan konten yang dienkripsi akan diangkut tanpa enkripsi.)

IPSEC dikonfigurasikan oleh administrator dan aplikasi tidak akan mengetahui apakah koneksi dienkripsi atau tidak. Saya terutama melihat IPSEC digunakan untuk menjembatani lalu lintas antar LAN melalui koneksi yang tidak aman (koneksi VPN). Saya percaya IPSEC dapat berlaku hanya untuk sebagian rute, sehingga pada beberapa segmen jaringan data ditransmisikan secara jelas (tidak terenkripsi).

Diberi pilihan, saya akan menggunakan enkripsi aplikasi karena enkripsi jaringan tidak banyak digunakan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.