เจาะลึก IPsec และ IKEv2 ทีละขั้น ไล่หาสาเหตุเมื่อ Tunnel ไม่ขึ้น

ticket ประเภท site-to-site tunnel ไม่ขึ้น เป็นงานที่ชวนให้เปลี่ยนค่าไปเรื่อยๆ แบบสุ่ม ลองเปลี่ยน encryption พิมพ์ pre-shared key ใหม่ เปิดปิด PFS แล้วก็หวังว่าจะหาย ผมพบว่าจะใจเย็นกว่ามาก ถ้ามอง IPsec เป็นขั้นตอนสั้นๆ ต่อกันไม่กี่ขั้น ซึ่งแต่ละขั้นมีแค่สำเร็จหรือไม่สำเร็จ ถ้ารู้ว่าตอนนี้ติดอยู่ขั้นไหน log จะบอกเองว่าต้องแก้อะไรต่อครับ

บทความนี้จะขึ้น tunnel สมมติระหว่างเกตเวย์สองตัวคือ GW-A และ GW-B ทีละ exchange และในแต่ละขั้นจะบอกว่าตอนสำเร็จหน้าตาเป็นอย่างไร และตอนพังหน้าตาเป็นอย่างไร แหล่งอ้างอิงหลักคือตัวมาตรฐานเอง ได้แก่ RFC 4301 (สถาปัตยกรรม IPsec), RFC 7296 (IKEv2) และ RFC 4303 (ESP) ส่วนคำแนะนำด้าน configuration ผมอิง Guide to IPsec VPNs, SP 800-77 Rev. 1 ของ NIST (มิถุนายน 2563) เอกสารยาวพอสมควร แต่บท troubleshooting ของมันใช้งานได้จริงมากครับ

ใน lab นี้ GW-A ดูแล subnet 198.51.100.0/24 และ GW-B ดูแล 192.0.2.0/24 ซึ่งเป็นช่วงตัวอย่างที่ RFC 7296 ใช้ในหัวข้อ 2.9 และเราจะได้ใช้มันตรงนั้นพอดี

ขั้น 0: ภาพในหัว (SPD, SAD, PAD)

ก่อนแพ็กเก็ตแรกจะวิ่ง ควรรู้ก่อนว่าเกตเวย์กำลังตัดสินใจเรื่องอะไร RFC 4301 อธิบายฐานข้อมูลไว้สามตัว

• SPD (Security Policy Database) ทุกแพ็กเก็ตที่ข้ามขอบเขตของ IPsec จะ match entry ใน SPD และแต่ละ entry มี action หนึ่งในสามแบบ คือ PROTECT, BYPASS หรือ DISCARD (RFC 4301 หัวข้อ 4.4.1) policy "traffic จาก 198.51.100.0/24 ไป 192.0.2.0/24: PROTECT" คือสิ่งที่อยู่เบื้องหลัง tunnel ของเรา
• SAD (Security Association Database) แต่ละ entry เก็บพารามิเตอร์ของ Security Association หนึ่งตัว เช่น key, algorithm, sequence counter และ lifetime (หัวข้อ 4.4.2)
• PAD (Peer Authorization Database) เป็นตัวเชื่อม SPD กับ IKE บอกว่า peer ไหนคุยกับเราได้ แต่ละ peer ยืนยันตัวตนด้วยวิธีใด และ peer แต่ละตัวมีสิทธิ์อ้าง identity และ traffic ชุดไหนได้บ้าง (หัวข้อ 4.4.3)

รายละเอียดหนึ่งที่ลืมกันง่าย คือ SA เป็นแบบ simplex คือป้องกัน traffic ได้ทิศทางเดียว traffic สองทางจึงต้องใช้ SA เป็นคู่ และ IKE ก็สร้าง SA เป็นคู่เสมอ (RFC 4301 หัวข้อ 4.1) เวลาคำสั่ง "show" ของ vendor แสดง SPI สองค่าสำหรับ tunnel เดียว นี่คือเหตุผล: ค่าหนึ่งขาเข้า อีกค่าขาออกครับ

สรุปคือหน้าที่ของ IKE คือเติม SAD เมื่อแพ็กเก็ต match entry แบบ PROTECT ใน SPD แต่ยังไม่มี SA IKE จะเป็นคนสร้างขึ้นมา (RFC 7296 หัวข้อ 2.9)

ขั้น 1: IKE_SA_INIT สองข้อความที่วิ่งแบบอ่านได้

การคุยกันของ IKEv2 ทุกครั้งเริ่มด้วยสอง exchange คือ IKE_SA_INIT และ IKE_AUTH ซึ่ง RFC 7296 ระบุว่า "known in IKEv1 as Phase 1" และปกติรวมกันแล้วใช้สี่ข้อความ (หัวข้อ 1.2) ทุก exchange ของ IKE เป็นคู่ request กับ response

 ┌─────────┐                                        ┌─────────┐ 
 │ GW-A  ● │         IKEv2  ·  site-to-site         │ GW-B  ● │ 
 └─────────┘                                        └─────────┘ 
      │                                                  │      
      │──────────── IKE_SA_INIT  SAi1 KEi Ni ───────────►│      
      │◄─────────── IKE_SA_INIT  SAr1 KEr Nr ────────────│      
      │                                                  │      
      │ ┌┄ IKE SA  SK{…} ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐ │      
      │═══════ IKE_AUTH SK{IDi AUTH SAi2 TSi TSr} ══════►│      
      │◄══════ IKE_AUTH SK{IDr AUTH SAr2 TSi TSr} ═══════│      
      │ ┆                                              ┆ │      
      │ ┆  ┌┄ CHILD SA pair (ESP) ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐  ┆ │      
      │ ┆  ┆                                        ┆  ┆ │      
      │ ┆  ┆                  data                  ┆  ┆ │      
      │ ┆  ┆                                        ┆  ┆ │      
      │ ┆  └┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘  ┆ │      
      │ └┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘ │      
 ─ in the clear   ═ inside the IKE SA                · ● ·      
 UDP 500 · 4500 if NAT is seen          rekey timer ·     ·     
                                                     · · ·      

คู่แรกเจรจา algorithm แลก nonce และทำ Diffie-Hellman exchange

GW-A  HDR, SAi1, KEi, Ni           -->
      <--  HDR, SAr1, KEr, Nr, [CERTREQ]   GW-B

SAi1 คือรายการ crypto suite ที่ GW-A ยอมรับสำหรับ IKE SA, KEi คือ Diffie-Hellman public value และ Ni คือ nonce ของ GW-A ฝั่ง GW-B เลือกมาหนึ่ง suite ตอบกลับใน SAr1 และทำ Diffie-Hellman ให้ครบด้วย KEr หลังจากนี้แต่ละฝั่งคำนวณค่าที่เรียกว่า SKEYSEED ได้ แล้ว derive ออกมาเป็น SK_e และ SK_a (key สำหรับ encryption และ integrity แยกกันแต่ละทิศทาง) กับ SK_d ที่ใช้เป็นต้นทางของ key ของ Child SA ภายหลัง (RFC 7296 หัวข้อ 1.2)

มีจุดหักมุมอยู่หนึ่งจุด GW-A ต้องส่ง Diffie-Hellman value ไปก่อนจะรู้ว่า GW-B จะเลือก group ไหน จึงต้องเดา ถ้าเดาผิด GW-B จะตอบด้วย notify INVALID_KE_PAYLOAD พร้อมบอก group ที่ต้องการ แล้ว GW-A ต้องส่งใหม่พร้อมรายการ proposal ครบชุดอีกครั้ง (หัวข้อ 1.2) การเห็น round trip เพิ่มหนึ่งรอบใน log จึงเป็นเรื่องปกติ แต่ถ้าวนซ้ำไม่จบก็ไม่ปกติครับ

หน้าตาเวลาพังในขั้นนี้

• ไม่มีการตอบกลับเลย ส่วนใหญ่เป็นเรื่อง reachability เพราะ IKE ต้องส่งจากและไปที่ UDP port 500 หรือ 4500 (หัวข้อ 2.23) ให้ตรวจเส้นทาง ACL และไฟร์วอลล์ที่อยู่ระหว่างทาง
• NO_PROPOSAL_CHOSEN แปลว่าไม่มี suite ไหนที่อีกฝั่งยอมรับเลย (หัวข้อ 3.10.1) ให้เทียบ encryption, PRF, integrity และ DH group ของทั้งสองฝั่งทีละช่อง
• ได้ notify COOKIE อันนี้เป็นกลไกป้องกัน DoS ไม่ใช่ error เมื่อ responder มีโหลดสูง มันขอให้ initiator พิสูจน์ก่อนว่ารับแพ็กเก็ตที่ address ที่อ้างได้จริง แล้วค่อยเก็บ state ใดๆ (หัวข้อ 2.6)

อย่าคาดหวังว่า packet capture จะช่วยได้มาก แม้แต่ในขั้นนี้ NIST เขียนไว้ตรงๆ ว่า tcpdump "not very useful" สำหรับ debug IKE เพราะดูได้แค่ IKE_SA_INIT exchange แรก ซึ่งเห็นแทบจะแค่ DH group หลังจากนั้นทุกอย่างถูกเข้ารหัสหมด ให้เปิด IKE debug log แทน และอย่าลืมปิดเมื่อแก้เสร็จครับ (SP 800-77r1 หัวข้อ 6.3)

ขั้น 2: IKE_AUTH พิสูจน์ว่าเป็นใคร

คู่ที่สองวิ่งอยู่ภายใน IKE SA ที่เพิ่งได้มา สัญลักษณ์ SK{…} หมายถึง "เข้ารหัสและป้องกัน integrity ด้วย SK_e และ SK_a ของทิศทางนั้น"

GW-A  HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}  -->
      <--  HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}                 GW-B

แต่ละฝั่งประกาศ identity (IDi, IDr) และพิสูจน์ด้วย payload AUTH ซึ่งใช้ได้ทั้ง signature จาก private key ของ certificate หรือ shared secret นอกจากนี้ AUTH ยังป้องกัน integrity ของข้อความ IKE_SA_INIT ก่อนหน้าด้วย ถ้าการเจรจาถูกแก้ไขระหว่างทางจะถูกจับได้ตรงนี้ ถ้าใช้ shared secret ชื่อใน ID payload ต้องสอดคล้องกับ key ที่ใช้ (RFC 7296 หัวข้อ 1.2)

สังเกตครึ่งหลังของแต่ละข้อความ: SAi2, TSi, TSr IKE_AUTH ไม่ได้ทำแค่ authentication แต่ยังเจรจา Child SA ตัวแรก ไปด้วย ดังนั้น IKE_AUTH ที่ผ่านจะได้ tunnel ที่ใช้งานได้ภายในสี่ข้อความครับ

หน้าตาเวลาพังในขั้นนี้

• AUTHENTICATION_FAILED IKE SA จะไม่ถูกสร้าง (หัวข้อ 1.2) ตัวต้องสงสัยประจำคือ PSK ไม่ตรงกัน ประเภทหรือค่าของ ID ไม่ตรงกับที่อีกฝั่งคาดไว้ (IP address, FQDN หรือ certificate DN) หรือ certificate chain ที่อีกฝั่งไม่เชื่อถือ
• IKE SA ขึ้นแต่ Child SA ไม่ขึ้น RFC 7296 ระบุ notify ที่ทำให้ Child SA ล้มเหลว โดยไม่ ล้ม IKE SA ไว้ เช่น NO_PROPOSAL_CHOSEN และ TS_UNACCEPTABLE (หัวข้อ 1.2) ถ้าเกตเวย์แสดง phase 1 "up" แต่ phase 2 "down" ก็คือกรณีนี้ ให้ดู proposal ของ Child SA (SAi2) และ traffic selector
• ข้อความ IKE_AUTH ขนาดใหญ่หายไปกลางทาง เมื่อใช้ certificate ข้อความ IKE_AUTH อาจใหญ่ถึงหลาย KB เมื่อข้อความใหญ่กว่า path MTU ก็จะถูก fragment ที่ระดับ IP และอุปกรณ์ NAT หรือ ISP บางรายทิ้ง IP fragment IKEv2 message fragmentation (RFC 7383 หัวข้อ 1.1) เขียนมาเพื่อกรณีนี้โดยตรง ถ้าแพลตฟอร์มรองรับก็ควรเปิดทั้งสองฝั่ง
• responder บันทึกว่าเชื่อมต่อสำเร็จแต่สั้นมาก NIST อธิบายว่า responder ตั้ง Child SA เสร็จ ก่อน ที่ initiator จะตรวจ AUTH ของ responder ถ้า initiator ไม่ยอมรับ สิ่งเดียวที่ทำได้คือลบ IKE SA ทันที ซึ่งมองจากฝั่ง responder จะดูแปลกๆ (SP 800-77r1 หัวข้อ 6.4) ถ้าเจออาการนี้ ให้ไปอ่าน log ฝั่ง initiator

ขอพูดเรื่อง pre-shared key สักหน่อยครับ NIST ระบุว่า PSK authentication มักถูกเลือกใช้เพราะตั้งค่าง่ายที่สุด และใช้บ่อยที่สุดกับ gateway-to-gateway tunnel NIST แนะนำ PSK ที่ "pseudorandomly created and has at least 128 bits of entropy" เตือนว่า PSK สั้นๆ ที่มาจากคำในพจนานุกรมเสี่ยงต่อ offline dictionary attack และไม่สนับสนุนอย่างยิ่งให้ใช้ group PSK ร่วมกันหลาย peer (SP 800-77r1 หัวข้อ 3.3.4) ช่วงหลังของเอกสารยังไปไกลกว่านั้น คือให้ใช้ public-key authentication มากกว่า PSK, PSK เหมาะกับ gateway-to-gateway tunnel ที่ข้ามขอบเขตการบริหาร (administrative domain) และภายใน administrative domain เดียวกันไม่ควรใช้ PSK เลย (หัวข้อ 7.2.2)

ขั้น 3: traffic selector ส่วนที่ทำให้งงมากที่สุด

TSi และ TSr คือวิธีที่เกตเวย์สองฝั่งตกลงกันว่า Child SA จะขน traffic ชุดไหน traffic selector แต่ละตัวประกอบด้วยช่วง address ช่วง port และ IP protocol ID ใน lab ของเรา GW-A จะเสนอ TSi = 198.51.100.0–198.51.100.255 และ TSr = 192.0.2.0–192.0.2.255 ถ้า GW-B เห็นด้วยก็จะส่งค่าเดิมกลับมา (RFC 7296 หัวข้อ 2.9)

IKEv2 ยอมให้ responder narrow proposal ลงเหลือเฉพาะส่วนที่ policy ของตัวเองอนุญาต ถ้าไม่มีส่วนไหนรับได้เลยจะตอบ TS_UNACCEPTABLE (หัวข้อ 2.9) narrowing มีประโยชน์ แต่ก็ซ่อนความไม่ตรงกันได้เหมือนกัน คือ tunnel ขึ้น แต่บาง subnet ผ่านไม่ได้แบบเงียบๆ เพราะ SA ครอบคลุมแค่บางส่วนของสิ่งที่อีกฝั่งคาดไว้

vendor ไม่ได้เรียกสิ่งนี้ว่า traffic selector เหมือนกันทุกเจ้า Palo Alto Networks เรียกว่า proxy ID เอกสารของเขาระบุว่ากับ IKEv1 นั้น PAN-OS รองรับเฉพาะ proxy ID ที่ตรงกันเป๊ะ (exact match) ส่วน IKEv2 รองรับ traffic selector narrowing นอกจากนี้ proxy ID แต่ละตัวนับเป็น VPN tunnel หนึ่งตัวในความจุ tunnel ของไฟร์วอลล์ และถ้า traffic ถูก NAT ให้ใช้ network หลัง NAT (Palo Alto Networks, Proxy ID for IPSec VPN) จะเรียกชื่ออะไรก็ตาม ให้เขียน selector ของทั้งสองฝั่งวางคู่กันเป็นคู่ source/destination จากมุมมองของแต่ละเกตเวย์ ความผิดแบบกลับด้านกันมองเห็นง่ายบนกระดาษ แต่หายากมากเมื่อดูผ่าน GUI สองตัวที่หน้าตาไม่เหมือนกันครับ

ขั้น 4: ESP สิ่งที่วิ่งอยู่บนสายจริงๆ

เมื่อมี Child SA แล้ว traffic ของผู้ใช้จะถูกขนด้วย ESP ใน tunnel mode เกตเวย์จะเอาแพ็กเก็ตต้นฉบับทั้งก้อนมาห่อ แล้วใส่ IP header ใหม่ไว้ด้านหน้า

                 ESP tunnel mode, layer by layer                
                                                                
  GW-A: encapsulate ▸                      ◂ GW-B: decapsulate  
                                                                
                                                                
                                                                
                      [IP][TCP][  data  ]                       
                    host→host                                   
                                                                
                                                                
                                                                
 ▒ = ciphertext                                                 
                                                                
                                                                
 GW-A ─■────────═════════───────────────────────────────══ GW-B 
         on the wire: outer header, SPI and seq readable        

RFC 4303 ระบุชัดว่าแต่ละส่วนได้รับการป้องกันแบบไหน ตารางด้านล่างคือตาราง 1 ของ RFC ซึ่งเป็นกรณีที่ใช้อัลกอริทึม encryption และ integrity แยกกัน (หัวข้อ 2) ส่วน cipher แบบ combined mode อย่าง AES-GCM มีตารางของตัวเองแยกไว้

ผลที่ตามมาซึ่งสำคัญในการใช้งานจริงมีสามข้อ

1. outer header ไม่ได้รับการป้องกันจาก ESP ใน transport mode นั้น ESP ป้องกันเฉพาะโปรโตคอลชั้นถัดไป ไม่รวม IP header ที่อยู่ด้านหน้า (RFC 4301 หัวข้อ 4.1) ส่วนใน tunnel mode ทุกอย่างที่เราสนใจอยู่ด้านในหมด outer header มีแค่ address ของเกตเวย์ถึงเกตเวย์
2. SPI และ sequence number อ่านได้ แต่แก้ไขโดยไม่ถูกจับไม่ได้ นี่คือสิ่งที่ทำให้ฝั่งรับหา SA ที่ถูกต้องได้และทำ anti-replay ได้ anti-replay ใช้ได้เฉพาะเมื่อเลือก integrity และเมื่อใช้ sequence number ขนาด 32 บิต ฝั่งรับต้องรองรับ window อย่างน้อย 32 แพ็กเก็ต โดยแนะนำให้ใช้ 64 เป็นค่าเริ่มต้น (RFC 4303 หัวข้อ 1 และ 3.4.3)
3. outer IP header ระบุ protocol 50 header ที่อยู่หน้า ESP จะมีค่า protocol เป็น 50 (RFC 4303 หัวข้อ 2) ถ้ามี NAT คั่นกลางระหว่าง peer และทั้งสองฝั่งรองรับ NAT traversal, IKEv2 จะตรวจเจอระหว่าง IKE_SA_INIT และทั้งสองฝั่งต้องห่อ ESP ด้วย UDP โดยย้ายไปใช้ port 4500 (RFC 7296 หัวข้อ 2.23 รูปแบบอยู่ใน RFC 3948) ไฟร์วอลล์ที่อยู่บนเส้นทางจึงต้องอนุญาต UDP 500, UDP 4500 และ IP protocol 50 ในกรณีที่ไม่มี NAT

แล้ว transport mode ล่ะ RFC 4301 ระบุว่า นอกจากข้อยกเว้นแคบๆ สองข้อ ถ้าปลายด้านใดด้านหนึ่งของ SA เป็น security gateway แล้ว SA นั้นต้องเป็น tunnel mode (หัวข้อ 4.1) และ IKEv2 จะสร้าง tunnel mode เสมอ เว้นแต่ทั้งสองฝั่งตกลงกันด้วย USE_TRANSPORT_MODE (RFC 7296 หัวข้อ 1.3.1) สำหรับ site-to-site สิ่งที่จะเห็นจึงเป็น tunnel mode ครับ

ขั้น 5: lifetime, PFS และ rekeying

ถ้า tunnel ขึ้นได้ปกติแล้วหลุดไปหลังผ่านไประยะเวลาหนึ่งที่ค่อนข้างตายตัว ให้ดูที่การ rekey ครับ

การสร้าง Child SA ใหม่และการ rekey ใช้ exchange เดียวกันคือ CREATE_CHILD_SA ซึ่งฝั่งไหนจะเริ่มก็ได้ RFC 7296 ระบุว่า "some of its function was referred to as a Phase 2 exchange in IKEv1" (หัวข้อ 1.3) การ rekey จะสร้าง SA ใหม่ก่อน แล้วค่อยลบ SA เก่าทีหลัง (หัวข้อ 2.8)

ข้อเท็จจริงสองข้อที่อธิบายเรื่องแปลกๆ ตอน rekey ได้หลายกรณี

• IKEv2 ไม่ได้เจรจา lifetime แต่ละฝั่งบังคับใช้ lifetime ตาม policy ของตัวเอง และฝั่งที่ lifetime สั้นกว่าจะเป็นคนเริ่ม rekey เสมอ (RFC 7296 หัวข้อ 2.8) lifetime ไม่ตรงกันจึงไม่ใช่ error แต่ทำให้คาดเดายากขึ้นว่าฝั่งไหนจะเริ่ม rekey ตารางค่าแนะนำของ NIST ระบุ 24 ชั่วโมงสำหรับ IKE SA และ 8 ชั่วโมงสำหรับ IPsec SA (SP 800-77r1 ตาราง 1)
• PFS ที่ไม่ตรงกันจะซ่อนตัวจนถึง rekey ครั้งแรก request ของ CREATE_CHILD_SA ใส่ payload KE ของตัวเองได้ เพื่อทำ Diffie-Hellman ใหม่ ให้ Child SA ตัวใหม่มี forward secrecy ที่แข็งแรงขึ้น (หัวข้อ 1.3) แต่ Child SA ตัวแรกถูกสร้างใน IKE_AUTH ซึ่งไม่มี DH exchange แยก NIST จึงเขียนว่า DH group ที่ไม่ตรงกัน "will only become apparent during a rekey message exchange hours later" (SP 800-77r1 หัวข้อ 6.4) ถ้า tunnel หลุดตรงเวลาทุกครั้งหลังครบ lifetime ของ Child SA ให้เทียบค่า PFS ของสองฝั่งเป็นอย่างแรก

liveness check ก็เกี่ยวข้องตรงนี้ IKEv2 ตรวจว่า peer ยังอยู่ไหมด้วย INFORMATIONAL request เปล่าๆ ที่อีกฝั่งต้องตอบ (RFC 7296 หัวข้อ 1.4 และ 2.4) NIST แนะนำว่าอย่าตั้ง dead peer detection probe ต่ำกว่าหนึ่งนาที เพราะบนลิงก์ที่หนาแน่น probe ที่ถูกทิ้งอาจทำให้ tunnel ที่ยังดีอยู่ถูกรื้อ แล้วเพิ่ม traffic สำหรับสร้าง tunnel ใหม่ลงบนลิงก์ที่หนักอยู่แล้ว (SP 800-77r1 หัวข้อ 6.4)

เลือก algorithm

มีแหล่งอ้างอิงที่ดีอยู่สองชุด ตาราง 1 ของ NIST แนะนำ IKEv2 (IKEv1 อยู่ในกลุ่ม legacy), AES แบบ GCM, CTR, CBC หรือ CCM, HMAC-SHA-256/384/512 และ DH group 14 ถึง 21 และแนะนำให้ PFS ใช้ group ที่เท่ากันหรือแข็งแรงกว่า group ของ IKE exchange แรก (SP 800-77r1 ตาราง 1) สำหรับคนที่กำลังย้ายออกจาก IKEv1 นั้น NIST ระบุว่า 3DES, MD5, SHA-1 และ DH group 2 กับ 5 "should not be used" และให้ใช้ AES-CBC กับ HMAC-SHA-2 หรือ AES-GCM ร่วมกับ DH group 14 หรือ ECDH group (19, 20 หรือ 21) แทน (หัวข้อ 3.9)

ข้อกำหนดการ implement ของ IETF ก็ไปในทางเดียวกัน สำหรับ IKEv2 RFC 8247 กำหนด DH group 14 เป็น MUST, group 19 เป็น SHOULD และ group 2 กับ 5 เป็น SHOULD NOT ส่วน ESP นั้น RFC 8221 กำหนด AES-GCM ที่มี ICV 16 ไบต์เป็น MUST และ 3DES เป็น SHOULD NOT ตารางเหล่านี้บอกว่า implementation ต้อง รองรับ อะไร ซึ่งไม่เท่ากับสิ่งที่เราควร เลือกใช้ เสียทีเดียว แต่ก็ชี้ไปทางเดียวกันครับ

แล้วตัว IKEv1 เองล่ะ RFC 9395 (เมษายน 2566) ย้าย IKEv1 ไปอยู่ในสถานะ Historic และ NIST ระบุว่า IKEv1 "should not be used for new deployments" (SP 800-77r1 หัวข้อ 3.11) มีกับดักเล็กๆ ที่ NIST พูดถึงด้วย คือ vendor แต่ละเจ้าหมายถึง "SHA-2" ไม่เหมือนกัน บางเจ้าหมายถึงเฉพาะ SHA2-256 บางเจ้าหมายถึงทั้งตระกูล จึงต้องเทียบ hash ที่ใช้จริงของทั้งสองฝั่ง (หัวข้อ 6.4)

ลำดับการ troubleshoot

นี่คือทั้งหมดข้างบนรวบเป็น checklist ลำดับมีความสำคัญ เพราะแต่ละขั้นถือว่าขั้นก่อนหน้าผ่านแล้วครับ

ขั้นที่ 6 ขอขยายความ NIST อธิบายกับดักคลาสสิกไว้สองแบบ แบบแรก ถ้า traffic ภายในถูก NAT เป็น public address ของเกตเวย์ ก่อน ตรวจ IPsec policy, source address จะไม่ match policy อีกต่อไป และแพ็กเก็ตอาจออกไปโดยไม่ถูกเข้ารหัส แบบที่สอง ใน route-based VPN ถ้า route ที่ชี้เข้า tunnel ไม่ตรงกันทั้งสองฝั่ง traffic อาจถูกเข้ารหัสทางเดียวแต่อีกทางไม่ (SP 800-77r1 หัวข้อ 6.4 และ 6.5) จุดยืนของ NIST เองคือให้ใช้ policy-based VPN ที่ระบุ subnet ชัดเจน มากกว่า selector แบบ 0.0.0.0/0 แล้วพึ่ง routing แม้จะบริหารยากกว่าก็ตาม ถ้าใช้ tunnel แบบ route-based ก็ต้องตั้งใจดูแล route และ security policy ของสองฝั่งให้สอดคล้องกันเสมอครับ

นิสัยที่ช่วยประหยัดเวลา: ตอน tunnel ล่ม ให้ถามตัวเองก่อนว่า "ตอนนี้อยู่ขั้นไหน" แล้วค่อยเปลี่ยนอะไร ดู IKE log ครั้งเดียวมักได้คำตอบครับ

Hardening remote access VPN

ทุกอย่างข้างบนใช้กับ remote access VPN ได้เหมือนกัน แต่เกตเวย์ประเภทนี้หันหน้าเข้าหาอินเทอร์เน็ตทั้งหมด ความเสี่ยงจึงสูงกว่า ในเดือนกันยายน 2564 NSA และ CISA เผยแพร่เอกสารร่วมชื่อ Selecting and Hardening Remote Access VPN Solutions ประกาศของ NSA ระบุว่า VPN server เป็นเป้าที่น่าสนใจเพราะเป็นทางเข้าสู่เครือข่ายที่ได้รับการป้องกัน และ APT ระดับรัฐหลายกลุ่มได้นำ CVE สาธารณะมาใช้โจมตีอุปกรณ์ VPN การโจมตีสำเร็จอาจทำให้ผู้โจมตีขโมย credential, รันโค้ดจากระยะไกล, ลดความแข็งแรงของการเข้ารหัส traffic, hijack session และอ่านข้อมูลสำคัญจากตัวอุปกรณ์ได้ (ประกาศของ NSA; alert ของ CISA)

คำแนะนำหลักของทั้งสองหน่วยงานมีดังนี้

• เลือก VPN ที่อิงมาตรฐาน และผลิตภัณฑ์ที่ผ่านการทดสอบและรับรองแล้ว (ตัวอย่างที่ให้ไว้คือ NIAP Product Compliant List)
• ใช้การยืนยันตัวตนที่แข็งแรง เช่น multi-factor authentication
• ลง patch และอัปเดตอย่างรวดเร็ว
• ลด attack surface ด้วยการปิดฟีเจอร์ที่ VPN ไม่จำเป็นต้องใช้

NIST เสริมอีกสองข้อสำหรับ remote access ที่ใช้ IKE โดยเฉพาะ คือไม่สนับสนุนอย่างยิ่งให้ใช้ group PSK และ remote access ควรใช้ EAP-TLS หรือ machine certificate ในการยืนยันตัวตน (SP 800-77r1 หัวข้อ 3.3.4 และ 7.2.2)

ส่งท้าย

IKEv2 ดูซับซ้อนส่วนใหญ่เพราะ vendor กระจายค่าตั้งของมันไว้หลายหน้าจอ แต่ข้างใต้แล้ว มันคือสี่ข้อความเพื่อให้ได้ tunnel ที่ใช้งานได้ exchange แบบเดียวสำหรับสร้าง SA ใหม่และ rekey หลังจากนั้น และรูปแบบ ESP ที่ข้อกำหนดฉบับปัจจุบันออกตั้งแต่ธันวาคม 2548 (RFC 4303) เมื่อบอกได้ว่า tunnel ติดอยู่ขั้นไหน การ troubleshoot IPsec ก็กลายเป็นการไล่ checklist แทนการเดาครับ

แหล่งอ้างอิง

• RFC 4301: Security Architecture for the Internet Protocol
• RFC 4303: IP Encapsulating Security Payload (ESP)
• RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)
• RFC 7383: IKEv2 Message Fragmentation
• RFC 3948: UDP Encapsulation of IPsec ESP Packets
• RFC 8221: Cryptographic Algorithm Implementation Requirements and Usage Guidance for ESP and AH
• RFC 8247: Algorithm Implementation Requirements and Usage Guidance for IKEv2
• RFC 9395: Deprecation of the IKEv1 Protocol and Obsoleted Algorithms
• NIST SP 800-77 Rev. 1: Guide to IPsec VPNs (หน้าเอกสาร) และ PDF
• Palo Alto Networks: Proxy ID for IPSec VPN
• NSA: NSA, CISA Release Guidance on Selecting and Hardening Remote Access VPNs
• CISA: CISA and NSA Release Guidance on Selecting and Hardening VPNs