在本课中,你将了解IPsec IKEv2。
完成本课后,你应该能够实现上图显示的目标。
通过展示对IPsec IKEv2的充分理解,你将能够解释IKEv2及其协商过程的差异和优势。
在本节中,你将了解IKEv1和IKEv2之间的区别。
虽然IKEv1仍然被广泛使用,但在决定是继续使用IKEv1还是更换它时,你必须考虑多个因素。值得注意的是,IKEv1的开发在十多年前就停止了,未经维护的代码可能会导致安全漏洞。IKEv1已移至历史状态,其一些RFC规格已过时。
IKEv1中使用的一些算法不再被积极部署或研究,这带来了你应该避免的未知安全风险。一些IKEv1功能从未达到标准状态,有些甚至没有RFC。
尽管IKEv1已弃用,但它仍然可以满足一些系统要求:
● 当作为拨号客户端的FortiGate设备需要RADIUS或LDAP身份验证时:由于FortiOS没有可扩展身份验证协议(EAP)客户端,FortiGate设备无法对RADIUS或LDAP服务器进行身份验证。在这种情况下,必须使用IKEv1。
● 当需要多个阶段的身份验证时:虽然IKEv2可以为这一要求提供解决方案,但它需要多个身份验证交换或使用基于隧道的EAP(TEAP)的EAP链。
FortiOS已经使用IKEv1超过20年,它推动了修复和优化。
IKEv1和IKEv2是不兼容的协议,可以实现相同的目标,但方式不同。
IKE版本2不与IKE版本1互操作,但它们都有足够的共同的标头格式,两个版本都可以明确地在同一UDP端口上运行。
虽然核心IKEv1功能是通过多个RFC定义的,但主要的IKEv2 RFC在单个文档中涵盖了许多相同的功能,如网络地址转换-横向(NAT-T)、模式-cfg、EAP、死对等检测(DPD)等。
过渡到IKEv2有多种原因:
● IKEv2是一个强大而可靠的协议,开发人员正在积极研究。
● IKEv2协商需要更少的消息,这意味着在建立隧道时减少了延迟。初始交换是两次往返(四条消息),这允许子SA的设置附带在该交换上。
其他新的改进如下:
● 碎片化的协商从第一条消息开始。
● DoS保护。
● IKE/IPSEC SA的重键逻辑定义更准确。
● 为简化实现和安全性分析,将保护IKE消息的密码语法替换为紧密基于ESP的密码语法。
迁移到IKEv2的其他原因有:
● 使用标准EAP作为身份验证和非对称身份验证
● 按ID匹配拨号第1阶段的选项
IKEv2为流量选择器提供了灵活性。你可以为每个流量选择器指定有效负载类型,而不是用ID有效负载超载它们。
IKEv2还支持使用叠加网络ID、SA会话恢复和快速崩溃检测的设置。
上图总结了IKEv1和IKEv2中IPsec功能的比较。
关于交换模式,在IKEv1中,野蛮模式提供了减少第1阶段交换次数的优势。相比之下,IKEv2不使用主模式或野蛮模式;然而,其相当于第1阶段的模式可能只需要两次交换。
在身份验证功能中,在IKEv1中,身份验证必须是对称的。IKEv2提供了灵活性,允许发起者和响应者在协商期间使用不同的身份验证方法。
作为IKEv2改进的一部分,NAT-T是一个内置功能。IKEv1不原生支持NAT-T。NAT-T功能后来被包括在内,以使IKEv1能够通过NAT设备工作。
IKEv2的另一个改进是流量选择器的灵活性,它允许对IPsec隧道保护的流量进行更精细的控制。IKEv2还支持在建立子SA后动态更新流量选择器。
在本节中,你将了解IKEv2交换用于协商IPsec隧道的步骤。
与IKEv1不同,IKEv2是一个可靠的协议:发起者重新发送请求,直到它收到相应的响应或认为IKE SA失败。在后一种情况下,发起人丢弃了IKE SA以及与无响应的同行协商的任何子SA。
IKEv1有一个明确划定的第1阶段交换,其中包含六个数据包,然后是三个数据包的第2阶段交换。IKEv2交换是可变的。充其量,它只能交换四个数据包。最坏的情况是,这可能会增加到多达30个数据包,这取决于身份验证的复杂性。
初始交换发生后,任何后续流量都会触发CREATE_CHILD_SA交换,这相当于IKEv1中的第2阶段交换。
IKEv2没有野蛮模式或主模式。
IKEv2不使用第1阶段或第2阶段的概念,但FortiOS CLl和GUl命令和术语以IKEv1为中心,因此你在配置IKEv2设置时确实使用了这些概念和术语。
IKEv2 SA的设置配置在第1阶段进行。子SA的设置配置在第2阶段进行。
在IKEv2谈判期间,有四个交换。初始交换是:IKE_SA_INIT和IKE_AUTH。
IKE_SA_INIT交换:
● 协商安全配置,保护IKE流量。
● 启用DoS保护(cookie机制)。
IKE_Auth交换:
● 执行两个IKE端点的相互身份验证。
● 配置IP/掩码、DNS等设置。
● 设置子SA的搭便车。为IPsec SA进行IP流和安全设置的谈判。
Create_Child_SA交换:
● 创建一个新的子SA或重新键换现有的子SA。
● 更新IKE SA。
信息交换:
● 在IKE端点之间传输控制消息。
使用IKE的通信总是从IKE_SA_INIT和IKE_AUTH交换开始(在IKEv1中称为第1阶段)。SA_INIT是IKEv2初始交换的第一次往返。SA_INIT交换通常需要一次往返。
如果响应者请求另一个密钥交换(INVALID_KE_PAYLOAD通知),或者如果DoS保护(cookie通知)启动,交换将扩展到两次往返。
如果密钥交换重新协商和DoS保护都完成,交换将增加到三次往返。
IKE_AUTH(身份验证)在SA_INIT之后进行,是初始交换的最后阶段。它受加密算法和SA_INIT密钥的保护。
双方交换他们的身份——ID发起者(IDi)或ID响应者(IDr)——并提供他们声称的身份(AUTH)的证明。
当不使用EAP时,IKE_AUTH由单个请求和响应交换组成。使用EAP时,IKE_AUTH由多个请求和响应交换组成。交换的数量取决于正在使用的EAP方法。
默认情况下,在IKE_AUTH过程中与IKEv2安全联盟协商一个IPsec (piggyback child)安全联盟。如果需要额外的IPsec sa(例如配置了多个FortiOS阶段2),则在后续的CREATE_CHILD_SA交换过程中协商。
根据IKEv2的设计,在IKE_AUTH交换过程中不需要交换Diffie-Hellman公钥。因此,fortify和对等体之间的任何phase 2 Diffie-Hellman组配置不匹配,只会在IKE_AUTH创建的子SA第一次更新密钥(CREATE_CHILD_SA exchange)时发生。
此交换由单个请求和响应对组成,在IKEv1中被称为第2阶段交换。初始交换完成后,它可以由IKE_SA的两端发起。初始交换之后的所有消息都使用IKE交换前两条消息中协商的加密算法和密钥进行加密保护。所有后续消息都包含一个加密的有效负载,即使它们在文本中被称为“空”。任一端点都可以启动CREATE_CHILD_SA交换,因此在此交换中,“发起者”一词指的是启动此交换的端点。
在IKE_SA操作过程中的不同点,同行可能需要相互传达有关错误或某些事件通知的控制消息。为了实现这一目标,IKE定义了信息交换。信息交换只能在初始交换后进行,并受到协商密钥的加密保护。
在本节中,你将学习用于监控IKEv2隧道的命令,以及用于调试和排除IKEv2故障的命令。
监视、调试和排除IKEv2故障的命令与IKEv1相同。
diagnose vpn ike gateway list命令可以提供隧道的详细信息。diagnose vpn ike gateway clear命令用来关闭阶段1。在进行故障诊断时,可以使用此命令强制进行隧道协商,但请谨慎使用。
diagnose vpn tunnel list命令用来显示当前所有激活隧道的IPsec SA信息。
为了调试IPsec IKEv2的连接,可以像IKEv1一样使用命令diagnose debug application ike,并使用命令diagnose vpn ike log filter应用过滤器,以收集指定隧道的调试输出。
启用调试命令diagnose debug application ike并启动IPsec协商后,可以分析IKEv2协商过程。
在最初的谈判中,你可以看到SA INIT交换。上图显示SA INIT已发送,发起者收到了SA_INIT响应。
成功进行SA INIT交换后,将进行IKE_AUTH交换。调试输出显示收到的主题和此响应。
上图显示了发起人发送的AUTH交换及其收到的回复。
成功交换IKE_SA_INIT和IKE_AUTH后,发生CHILD_SA交换。
在此交换中,同行协商CHILD_SA和流量选择器——流量选择器响应器(TSr)和流量选择器发起器(TSi)。
上图展示了你在本课中涵盖的目标。
通过掌握本课中涵盖的目标,你了解了对IKEv2的改进、其协商过程以及如何使用IKEv2协议调试IPsec隧道。