IPSec协议的简单介绍

这个东东我也不太懂，只好大家共同学习共同进步呀！
先给个介绍吧：
　　目前建造虚拟专网的国际标准有IPSEC（RFC 1825-1829）和L2TP（草案draft-ietf-pppext-l2tp-10）。其中L2TP是虚拟专用拨号网络协议，是IETF根据各厂家协议（包括微软公司的PPTP、Cisco的L2F）进行起草的，目前尚处于草案阶段。IPSEC是一系列基于IP网络（包括Intranet、Extranet和Internet）的，由IETF正式定制的开放性IP安全标准，是虚拟专网的基础，已经相当成熟可靠。L2TP协议草案中规定它（L2TP标准）必须以IPSEC为安全基础（见draft-ietf-pppext-l2tp-security-01）。因此，阐述VPN的工作原理，主要是分析IPSEC的工作原理。
　　IPSEC提供三种不同的形式来保护通过公有或私有IP网络来传送的私有数。
　　认证――作用是可以确定所接受的数据与所发送的数据是一致的，同时可以确定申请发送者在实际上是真实发送者，而不是伪装的。
　　数据完整――作用是保证数据从原发地到目的地的传送过程中没有任何不可检测的数据丢失与改变。
　　机密性――作用是使相应的接收者能获取发送的真正内容，而无意获取数据的接收者无法获知数据的真正内容。
　　在IPSEC由三个基本要素来提供以上三种保护形式：认证协议头（AH）、安全加载封装（ESP）和互联网密匙管理协议（IKMP）。认证协议头和安全加载封装可以通过分开或组合使用来达到所希望的保护等级。
　　认证协议头（AH）是在所有数据包头加入一个密码。正如整个名称所示，AH通过一个只有密匙持有人才知道的“数字签名”来对用户进行认证。这个签名是数据包通过特别的算法得出的独特结果；AH还能维持数据的完整性，因为在传输过程中无论多小的变化被加载，数据包头的数字签名都能把它检测出来。不过由于AH不能加密数据包所加载的内容，因而它不保证任何的机密性。两个最普遍的AH标准是MD5和SHA-1，MD5使用最高到128位的密匙，而SHA-1通过最高到160位密匙提供更强的保护。
　　安全加载封装（ESP）通过对数据包的全部数据和加载内容进行全加密来严格保证传输信息的机密性，这样可以避免其他用户通过监听来打开信息交换的内容，因为只有受信任的用户拥有密匙打开内容。ESP也能提供认证和维持数据的完整性。最主要的ESP标准是数据加密标准（DES），DES最高支持56位的密匙，而3DES使用三套密匙加密，那就相当于使用最高到168位的密匙。由于ESP实际上加密所有的数据，因而它比AH需要更多的处理时间，从而导致性能下降。
　　密匙管理包括密匙确定和密匙分发两个方面，最多需要四个密匙：AH和ESP各两个发送和接收密匙。密匙本身是一个二进制字符串，通常用十六进制表示，例如，一个56位的密匙可以表示为5F39DA752E0C25B4。注意全部长度总共是64位，包括了8位的奇偶校验。56位的密匙（DES）足够满足大多数商业应用了。密匙管理包括手工和自动两种方式，手工管理系统在有限的安全需要可以工作得很好，而自动管理系统能满足其他所有的应用要求。
　　使用手工管理系统，密匙由管理站点确定然后分发到所有的远程用户。真实的密匙可以用随机数字生成器或简单的任意拼凑计算出来，每一个密匙可以根据集团的安全政策进行修改。 　　使用自动管理系统，可以动态地确定和分发密匙，显然和名称一样，是自动的。自动管理系统具有一个中央控制点，集中的密匙管理者可以令自己更加安全，最大限度的发挥IPSEC的效用。
　　IPSEC的实现方式
　　IPSEC的一个最基本的优点是它可以在共享网络访问设备，甚至是所有的主机和服务器上完全实现，这很大程度避免了升级任何网络相关资源的需要。在客户端，IPSEC架构允许使用在远程访问介入路由器或基于纯软件方式使用普通MODEM的PC机和工作站。而ESP通过两种模式在应用上提供更多的弹性：传送模式和隧道模式。
　　IPSEC Packet 可以在压缩原始IP地址和数据的隧道模式使用
　　传送模式通常当ESP在一台主机（客户机或服务勤）上实现时使用，传送模式使用原始明文IP头，并且只加密数据，包括它的TCP和UDP头。
　　隧道模式通常当ESP在关联到多台主机的网络访问介入装置实现时使用，隧道模式处理整个IP数据包――包括全部TCP/IP或UDP/IP头和数据，它用自己的地址做为源地址加入到新的IP头。当隧道模式用在用户终端设置时，它可以提供更多的便利来隐藏内部服务器主机和客户机的地址
下面有一些网址：
www.freeSWan.org      Linux下的使用IPSec协议的自由软件，有源码,很不错的；
www.microsoft.com/china/technet/windows2000/win2ksrv/technote/ ispstep.asp  windows2000中内含的IPSec
www.ipsec.org/email/   Email邮递列表；
www.ipsec.dk
当然还有就是RFC文档啦！

不知道这些东西是你在那里copy&paste来的，看起来相当老。
你说的rfc 1825-1829是老的标准，ietf已经强烈要求废除
这个老标准，并且表明不安全。现有的标准是rfc2401到2408。
目前也并不出于草案阶段。目前2001.12的关于ipsec的草案有
ipsec的mib库定义，ipsec的策略库模型，ipsec和nat不兼容
的解决方案等。这都是一些外围定义。

由于ipsec的标准和我很早以前做的vpn source之类的东西很
接近，而且正好去年下半年我了解ipsec的时候在linux下工作，
这一年来我基本上就是在windows平台下实现这些玩艺。我的
感觉，最困难的不是核心驱动程序，最困难的就是定义策略模型。
那个rfc draft把我简直吓得快要晕过去。

这个东东我也不太懂，只好大家共同学习共同进步呀！
先给个介绍吧：
　　目前建造虚拟专网的国际标准有IPSEC（RFC 1825-1829）和L2TP（草案draft-ietf-pppext-l2tp-10）。其中L2TP是虚拟专用拨号网络协议，是IETF根据各厂家协议（包括微软公司的PPTP、Cisco的L2F）进行起草的，目前尚处于草案阶段。IPSEC是一系列基于IP网络（包括Intranet、Extranet和Internet）的，由IETF正式定制的开放性IP安全标准，是虚拟专网的基础，已经相当成熟可靠。L2TP协议草案中规定它（L2TP标准）必须以IPSEC为安全基础（见draft-ietf-pppext-l2tp-security-01）。因此，阐述VPN的工作原理，主要是分析IPSEC的工作原理。
　　IPSEC提供三种不同的形式来保护通过公有或私有IP网络来传送的私有数。
　　认证――作用是可以确定所接受的数据与所发送的数据是一致的，同时可以确定申请发送者在实际上是真实发送者，而不是伪装的。
　　数据完整――作用是保证数据从原发地到目的地的传送过程中没有任何不可检测的数据丢失与改变。
　　机密性――作用是使相应的接收者能获取发送的真正内容，而无意获取数据的接收者无法获知数据的真正内容。
　　在IPSEC由三个基本要素来提供以上三种保护形式：认证协议头（AH）、安全加载封装（ESP）和互联网密匙管理协议（IKMP）。认证协议头和安全加载封装可以通过分开或组合使用来达到所希望的保护等级。
　　认证协议头（AH）是在所有数据包头加入一个密码。正如整个名称所示，AH通过一个只有密匙持有人才知道的“数字签名”来对用户进行认证。这个签名是数据包通过特别的算法得出的独特结果；AH还能维持数据的完整性，因为在传输过程中无论多小的变化被加载，数据包头的数字签名都能把它检测出来。不过由于AH不能加密数据包所加载的内容，因而它不保证任何的机密性。两个最普遍的AH标准是MD5和SHA-1，MD5使用最高到128位的密匙，而SHA-1通过最高到160位密匙提供更强的保护。
　　安全加载封装（ESP）通过对数据包的全部数据和加载内容进行全加密来严格保证传输信息的机密性，这样可以避免其他用户通过监听来打开信息交换的内容，因为只有受信任的用户拥有密匙打开内容。ESP也能提供认证和维持数据的完整性。最主要的ESP标准是数据加密标准（DES），DES最高支持56位的密匙，而3DES使用三套密匙加密，那就相当于使用最高到168位的密匙。由于ESP实际上加密所有的数据，因而它比AH需要更多的处理时间，从而导致性能下降。
　　密匙管理包括密匙确定和密匙分发两个方面，最多需要四个密匙：AH和ESP各两个发送和接收密匙。密匙本身是一个二进制字符串，通常用十六进制表示，例如，一个56位的密匙可以表示为5F39DA752E0C25B4。注意全部长度总共是64位，包括了8位的奇偶校验。56位的密匙（DES）足够满足大多数商业应用了。密匙管理包括手工和自动两种方式，手工管理系统在有限的安全需要可以工作得很好，而自动管理系统能满足其他所有的应用要求。
　　使用手工管理系统，密匙由管理站点确定然后分发到所有的远程用户。真实的密匙可以用随机数字生成器或简单的任意拼凑计算出来，每一个密匙可以根据集团的安全政策进行修改。 　　使用自动管理系统，可以动态地确定和分发密匙，显然和名称一样，是自动的。自动管理系统具有一个中央控制点，集中的密匙管理者可以令自己更加安全，最大限度的发挥IPSEC的效用。
　　IPSEC的实现方式
　　IPSEC的一个最基本的优点是它可以在共享网络访问设备，甚至是所有的主机和服务器上完全实现，这很大程度避免了升级任何网络相关资源的需要。在客户端，IPSEC架构允许使用在远程访问介入路由器或基于纯软件方式使用普通MODEM的PC机和工作站。而ESP通过两种模式在应用上提供更多的弹性：传送模式和隧道模式。
　　IPSEC Packet 可以在压缩原始IP地址和数据的隧道模式使用
　　传送模式通常当ESP在一台主机（客户机或服务勤）上实现时使用，传送模式使用原始明文IP头，并且只加密数据，包括它的TCP和UDP头。
　　隧道模式通常当ESP在关联到多台主机的网络访问介入装置实现时使用，隧道模式处理整个IP数据包――包括全部TCP/IP或UDP/IP头和数据，它用自己的地址做为源地址加入到新的IP头。当隧道模式用在用户终端设置时，它可以提供更多的便利来隐藏内部服务器主机和客户机的地址
下面有一些网址：
www.freeSWan.org      Linux下的使用IPSec协议的自由软件，有源码,很不错的；
www.microsoft.com/china/technet/windows2000/win2ksrv/technote/ ispstep.asp  windows2000中内含的IPSec
www.ipsec.org/email/   Email邮递列表；
www.ipsec.dk
当然还有就是RFC文档啦！
 

前一段时间，我刚实现了win9x,nt,2k平台的IPSec内核和其上的vpn系统。其实，如果单纯实现ipsec内核的话，难点在于如何规范的实现IPSec标准，以用于与其他IPSec实现通讯。如果在IPSec基础上实现vpn,还有很多工作要作的，不是说有了IPSec就可以了。这次最大的体会就是即便是ietf的rfc,离实际应用也是有很大距离的，举个例子，nat的问题，在rfc中最大的问题出在修改ip head上，而实际中，很多nat根本会抛弃ipsec包。不过rfc中也有这个问题的对策。

至于编程，其实很简单。
我刚做这个的时候，完全是驱动的门外汉，就靠着大量的读例子，读书，上网看文章，指望问那些所谓的高手是没用的，他们不会告诉你真正的答案，答案就在网上，就在代码里，人，一定要靠自己。希望我的经历能给后来的兄弟一点启示。

遇到救星了 ，我现在也是实现了ipsec内核了，下一步就是想做vpn，都不知道从哪里入手。看了一些资料什么虚拟拨号，认证过程等等看的都头晕，是不是都要自己一步步实现？可否介绍一下l2tp这个协议是不是跟ipsec集成再一起再中间层实现。不明白的问题是在是太多了，再问几个：
经过加密后数据包是不是还得靠自己进行分段？

还有ipsec中一个遗留问题pmtu是靠什么解决的？
按树上办法转发icmp数据包好像没什么效果。

前一段时间，我刚实现了win9x,nt,2k平台的IPSec内核和其上的vpn系统。其实，如果单纯实现ipsec内核的话，难点在于如何规范的实现IPSec标准，以用于与其他IPSec实现通讯。如果在IPSec基础上实现vpn,还有很多工作要作的，不是说有了IPSec就可以了。这次最大的体会就是即便是ietf的rfc,离实际应用也是有很大距离的，举个例子，nat的问题，在rfc中最大的问题出在修改ip head上，而实际中，很多nat根本会抛弃ipsec包。不过rfc中也有这个问题的对策。

至于编程，其实很简单。
我刚做这个的时候，完全是驱动的门外汉，就靠着大量的读例子，读书，上网看文章，指望问那些所谓的高手是没用的，他们不会告诉你真正的答案，答案就在网上，就在代码里，人，一定要靠自己。希望我的经历能给后来的兄弟一点启示。

说句老实话，我本来实在是不想多说什么，但是我实在是太敬佩了，
因此有几个问题想请教：
不知道你做的IPSEC能够和W2K或是Freeswan互通吗？还有NAT，
你能够讲讲RFC里面的对策是什么吗？我看英文头比较大:-)，
因此看得就比较慢，我的印象是，好像这个问题没有什么办法，
如果说一定有，就是重新定义NAT，或者IPSEC，或者不用NAT，
或者不用IPSEC。对于FTP协议的NAT，NAT网关可不仅修改一个
TCP HEADER，可是要修改内容的，不知道RFC新的draft有没有
什么新的方法？

还有一个细节，IPSEC的定义需要自动发起IKE协商（如果没有SA的
话），不知道你在核心层代码里面是如何让你的IKE应用程序（一个
SERVICE）发起IKE的呢？当时可是在DPC优先级上。

还有一个痛苦的问题，组包的问题。碎包很好解决，可是组包
就非常痛苦。不知道老兄你是如何实现的？

最后，让我困惑了很久的问题，关于策略的定义和交换分发的问题，
我一直找不到一个比较好的方案。

这些问题都是让我曾经通宵不眠，并且因此熬红了双眼的，最后
那个策略的问题，让我至今都抑郁。

在学习驱动开发的过程中，HU先生对于新人的“热心解答”的风范，“循循善诱”的态度，我记忆犹新，以至于要如前所发文中所提，特意留言后来的兄弟，凡事一定要靠自己。

在每一个新技术目前，都是入门有早晚而已。不见得某项技术谁做的早，谁做的多，这个人就有多了不起的。

我的专业是网络安全，VPN只是我研究课题之一，RFC也看了一点，当然了，肯定达不到HU先生那么高深的程度。

我做的VPN,很弱，借鉴了大量FREESWAN的东西，以至于凑巧可以和FREESWAN互操作，至于2K,没试过。

其他的技术细节，只不过是根据我自己程序的实现而写的，无论是分片重组，IPSEC内核与IKE通讯，UDP封装，还是策略，都是根据RFC&DRAFT和WINDOWS驱动编程的小技巧的实现而已。

不止HU先生实在不愿多说，我更不愿，回复这篇，仍是提醒后来的兄弟，驱动开发也不是多大的难题，关键在于要有信心，你一定行的，入门有早晚而已，坚持下去，你一定能做成你想做的事情！

祝所有和我当初一样辛苦的兄弟早日达成心愿！

发起ike过程，一开始用了一个笨办法，就是应用层不断的调用一个接口函数，查看是否有ike请求。
现在用事件通知上层应用程序，有新的ike请求，然后应用程序通过接口读取所需的信息
不知有没有更好的解决办法

动态密钥交换过程，我把spi也进行交换。这样spi值只要在本机唯一就可以了。也不知道这种实现方法是否合理？

发起ike过程，一开始用了一个笨办法，就是应用层不断的调用一个接口函数，查看是否有ike请求。
现在用事件通知上层应用程序，有新的ike请求，然后应用程序通过接口读取所需的信息
不知有没有更好的解决办法

动态密钥交换过程，我把spi也进行交换。这样spi值只要在本机唯一就可以了。也不知道这种实现方法是否合理？

核心驱动要通知app一个事件，那是有非常标准的方法
的，用异步io或者event都可以。ike的麻烦在于
问题是在收到一个包的时候，此刻正在dpc优先级，该
优先级不可重入，所以该过程不退出，ike的包也发不出。
此时只好把这个包放到队列里去，等到ike已经成功，
再把这个包发出去。这样要保持一个队列，每次发送的
时候要先检索这个队列。

以上是我的解法。

在学习驱动开发的过程中，HU先生对于新人的“热心解答”的风范，“循循善诱”的态度，我记忆犹新，以至于要如前所发文中所提，特意留言后来的兄弟，凡事一定要靠自己。

在每一个新技术目前，都是入门有早晚而已。不见得某项技术谁做的早，谁做的多，这个人就有多了不起的。

我的专业是网络安全，VPN只是我研究课题之一，RFC也看了一点，当然了，肯定达不到HU先生那么高深的程度。

我做的VPN,很弱，借鉴了大量FREESWAN的东西，以至于凑巧可以和FREESWAN互操作，至于2K,没试过。

其他的技术细节，只不过是根据我自己程序的实现而写的，无论是分片重组，IPSEC内核与IKE通讯，UDP封装，还是策略，都是根据RFC&DRAFT和WINDOWS驱动编程的小技巧的实现而已。

不止HU先生实在不愿多说，我更不愿，回复这篇，仍是提醒后来的兄弟，驱动开发也不是多大的难题，关键在于要有信心，你一定行的，入门有早晚而已，坚持下去，你一定能做成你想做的事情！

祝所有和我当初一样辛苦的兄弟早日达成心愿！

看起来你当年不知道在哪里受过我的某次不友好的打击，
还是当时我没有理你？总之伤了你一颗好学上进的心，
因此你对“HU先生对于新人的“热心解答”的风范，
“循循善诱”的态度，我记忆犹新，以至于要如前所
发文中所提，特意留言后来的兄弟，凡事一定要靠自己。”

如果是前者，那么我这里说抱歉，一不小心说错了话，
并且从而让你伤心，还怀着一颗善良的心告诫后面的
兄弟要小心。对于你的崇高品质，我非常佩服。同事
我也要回去反省自己是不是话说的过多，过头，要加强
自身的修养。

如果是我某次怠慢了你的问题，从而让你难过，因为
你本来想凡事都不靠自己，或希望某些事不靠自己，
看到我似乎偶尔回答的颇为详细，并且对我不切合实际
的产生了什么幻想的话，我要怀着沉痛的心情为打破
了你的这种幻想而抱歉。

同时我真的很奇怪，我虽然偶尔说话刻薄，但是似乎
还没有说过什么让人印象深刻的话，就更没有听人说
过我的某句话让他记忆犹新，大家的评价一般都是\"
this fellow is really boring\"。莫非你非常敏感？
我喜欢敏感的女人，但是不太喜欢敏感的男人。

我不知道这里是不是有人现在还没有建立“凡事要靠自己”，
我希望他们也能够象这位老兄一样，凡事要靠自己。

不过这位老兄大量的借鉴了freeswan的soure code，全盘
copy某些库函数也未必不可能，不知道是不是凡事要靠自己
的典范呢？freeswan我印象中是gnu项目，使用source是必须
在gnu条款下的，不知道这位老兄能不能我们也产生点“某些
事不必靠自己”的幻想，open source一下呢？

至今我在白云黄鹤站公布了不少的source，其中包括9x平台下的
完整vpn核心source。这位老兄当然觉得我公布的不够多，对
于新人不够友好，如果我对于在成长道路上跋涉的你进行过什么
打击，我这里再次的说抱歉，同时我要提醒你，你现在已经
“都是根据RFC&DRAFT和WINDOWS驱动编程的小技巧的实现而已。”
这水平很让我佩服，应该不再是新人了吧？我很想看看这位
成长起来的新人对于现在的新人是不是能够比我当时做得更好，
还是仅仅只是送给他们一句话“凡事要靠自己”？

版主的意思是不是将发出去的包都缓存起来
等待ike调用完成

不过如果在ike完成前，有很多数据包要发送，那是不是也要缓存起来，这样的队列是不是太大了点

我这里在ike没有完成前都是简单的将数据包丢弃，根本没有考虑到缓存。

不知我对版主话的理解有没有错？

版主的意思是不是将发出去的包都缓存起来
等待ike调用完成

不过如果在ike完成前，有很多数据包要发送，那是不是也要缓存起来，这样的队列是不是太大了点

我这里在ike没有完成前都是简单的将数据包丢弃，根本没有考虑到缓存。

不知我对版主话的理解有没有错？

你的理解没有错，的确需要缓存，ipsec的规范是这样要求的，
w2k也是这样实现的。否则无法建立连接，难道要让用户再建立
一次sock?很多程序都只会弹一个对话框之后退出。

并不是要缓存所有的包，而是一个目的地址只缓存一个包，
后来的覆盖新的。（w2k是这样做的）不过因为是发送端的处理，
任何人我想都不至于会对自己的机器进行恶意拒绝服务攻击吧？

这下糟糕了 有点添加代码了
还是看rfc文档好，为了方便我就是看了一些中文的ipsec资料
根本没有提到这方面的问题

不过还是有个问题
如果发的是udp的数据包，如果只缓存一个数据包，好像没多大作用