当它出现时 , 这个通知有效载荷应该有下列格式:
o有效载荷长度-设定有效载荷的长度 数据的大小(4)
oDOI-设定到IPSECDOI(1)
o协议ID-从选择的SA选择了协议ID集合
oSPI大小-设定到任何一个16(16)(2个8字节ISAKMPcookies)或4(4)(一IPSECSPI)
o通知消息类型-到REPLAY-STATUS的集合
oSPI-设定到2个ISAKMPcookies或到发送者的入站IPSECSPI
o通知数据-4字节值:
0=不可重放探测
1=启用重放探测
4.6.3.3INITIAL-CONTACT
当一个方面希望通知其它方这是这是同遥远系统建立的第一个SA时 , INITIAL-CONTACT状态消息可以被使用 。这条通知消息的接收装置然后可能选择删除任何存在的Sa , 它在传送系统时重新启动 , 并且假设不再为传送系统的原有Sa存取与他们联系的密钥材料 。当使用时 , 通知数据域的内容应该为空(即有效载荷长度应该被设置为被通知有效载荷的固定长度) 。
当前 , 通知有效载荷必须有下列格式:
o有效载荷长度-设定有效载荷的长度 数据的大小(0)
oDOI-设定到IPSECDOI(1)
o协议ID-从选择的SA选择了协议ID集合
oSPI大小-设定到16(16)(2个8字节ISAKMPcookies)
o通知消息类型-到INITIAL-CONTACT的集合
oSPI-设定到2个ISAKMPcookies
o通知数据-<不被包括>
4.7IPSEC密钥交换要求
IPSECDOI不介绍附加的密钥交换类型 。
5.安全考虑
整个备忘录属于因特网密钥交换协议(IKE),它以一种安全的并且好鉴定的方式 , 联合ISAKMP([ISAKMP])和[OAKLEY]来提供密钥材料来源 。各种各样的安全协议和文件中转换鉴别的非凡讨论能在相关的基础文件和密码参考书目中找到 。
6.IANA需要考虑的事项
这个文件包含一些需要IANA来维持的“魔法”数字 。这个章节解释由IANA来使用的标准 , 用这个标准在每一个这些列表中分配附加数字 。在前面章节中没有明确说明的所有值对IANA来说是保留的 。
6.1IPSEC位置定义
这个位置定义是一个32位bitmask , 它描绘IPSECSA的建议和商谈被实现的环境 。请求分配新位置应该由一个RFC来完成 , 这个RFC由关联位来解释 。
假如这个RFC不在标准轨迹上(也就是说 , 它是一个报告的或实验的RFC) , 它应该在RFC被公开和转化标识符被指派之前被明确的回复或被IESG认可 。
这个上层的两位在合作系统中被保留用作私有用途 。
6.2IPSEC安全协议标识符
这个安全协议标识符适合一个8位值 , 它标识一个正需要讨论的安全协议 。请求分配一个新的安全协议标识符应该由一个RFC来实现 , 它描叙了这个需要的安全协议 。[AH]和[ESP]是这个安全协议文件中的例子 。
假如这个RFC不在标准轨迹上(也就是说 , 它是一个报告的或实验的RFC) , 它应该在这个RFC被公开和这个转化被指岀之前明确的评论和由IESG来认可 。
这些值249-255在合作系统中被保留作为私有用途 。
6.3IPSECISAKMP转移标志符
这个IPSECISAKMP转移标志符是一个8位的值 , 它标识一个用来流通的密钥交换协议 。
请求分配新的ISAKMP转移标志符应该由RFC来完成 , 它描叙这个需要的密钥交换协议 。[IKE]是一个这种文件中的例子 。
假如RFC不在标准轨迹上(也就是说 , 它是一个报告的或实验的RFC) , 它应该在RFC被公开和这个转移标识符被分配之前明确的指出和通过IESG来证实 。
在合作系统中保留249-255这些值作为私有用途来使用 。
6.4IPDECAH转移标识符
这个IPSECAH转移标识符是一个8位值 , 它鉴别一个特定的算法法则来为AH提供完整保护 。请求分配一个新的AH转移标识符应该由一个RFC来协助完成 。这个RFC描绘了怎样在AH框架中用这个运算法则 。
推荐阅读
- 因特网子网
- SRP鉴别和秘钥交换系统
- 以太网交换技术向城域网渗透
- 匿名私密照片交换APP YY换图怎么注册
- 中间系统 IS-IS主机名动态交换机制
- 剑盾 怎么交换
- 从VoIP到软交换的蜕变
- office2016永久激活密钥教程
- 无线ATM交换机的实现
- 安全报文交换协议