点对点协议介绍

点对点协议介绍
PPP协议主要是设计用来通过拨号或专线方式建立点对点连接发送数据。

PPP协议将IP，IPX 和NETBEUI包封装在PP桢内通过点对点的链路发送。

PPP协议主要应用于连接拨号用户和NAS。

PPP拨号会话过程可以分成4个不同的阶段。

分别如下：
阶段1：创建PPP链路
PPP使用链路控制协议（LCP）创建，维护或终止一次物理连接。

在LCP阶段的初期，将对基本的通讯方式进行选择。

应当注意在链路创建阶段，只是对验证协议进行选择，用户验证将在第2阶段实现。

同样，在LCP阶段还将确定链路对等双方是否要对使用数据压缩或加密进行协商。

实际对数据压缩/加密算法和其它细节的选择将在第4阶段实现。

阶段2：用户验证
在第2阶段，客户会PC将用户的身份明发给远端的接入服务器。

该阶段使用一种安全验证方式避免第三方窃取数据或冒充远程客户接管与客户端的连接。

大多数的PPP方案只提供了有限的验证方式，包括口令验证协议（PAP），挑战握手验证协议（CHAP）和微软挑战握手验证协议（MSCHAP）。

1.口令验证协议（PAP）
PAP是一种简单的明文验证方式。

NAS要求用户提供用户名和口令，PAP以明文方式返回用户信息。

很明显，这种验证方式的安全性较差，第三方可以很容易的获取被传送的用户名和口令，并利用这些信息与NAS建立连接获取NAS提供的所有资源。

所以，一旦用户密码被第三方窃取，PAP无法提供避免受到第三方攻击的保障措施。

2.挑战-握手验证协议（CHAP）
CHAP是一种加密的验证方式，能够避免建立连接时传送用户的真实密码。

NAS向远程用户发送一个挑战口令（challenge），其中包括会话ID和一个任意生成的挑战字串（arbitrary challengestring）。

远程客户必须使用MD5单向哈希算法（one-wayhashingalgorithm）返回用户名和加密的挑战口令，会话ID以及用户口令，其中用户名以非哈希方式发送。

CHAP对PAP进行了改进，不再直接通过链路发送明文口令，而是使用挑战口令以哈希算法对口令进行加密。

因为服务器端存有客户的明文口令，所以服务器可以重复客户端进行的操作，并将结果与用户返回的口令进行对照。

CHAP为每一次验证任意生成一个挑战字串来防止受到再现攻击（replay attack).在整个连接过程中，CHAP将不定时的向客户端重复发送挑战口令，从而避免第3方冒充远程客户（remoteclient impersonation)进行攻击。

3.微软挑战-握手验证协议（MS-CHAP）
与CHAP相类似，MS-CHAP也是一种加密验证机制。

同CHAP一样，使用MS-CHAP 时，NAS会向远程客户发送一个含有会话ID和任意生成的挑战字串的挑战口令。

远程客户必须返回用户名以及经过MD4哈希算法加密的挑战字串，会话ID和用户口令的MD4哈希值。

采用这种方式服务器端将只存储经过哈希算法加密的用户口令而不是明文口令，这样就能够提供进一步的安全保障。

此外，MS-CHAP同样支持附加的错误编码，包括口令过期编码以及允许用户自己修改口令的加密的客户-服务器（client-server)附加信息。

使用MS-CHAP，客户端和NAS双方各自生成一个用于随后数据加密的起始密钥。

MS-CHAP使用基于MPPE的数据加密，这一点非常重要，可以解释为什么启用基于MPPE的数据加密时必须进行MS-CHAP验证。

在第2阶段PPP链路配置阶段，NAS收集验证数据然后对照自己的数据库或中央验证数据库服务器（位于NT主域控制器或远程验证用户拨入服务器）验证数据的有效性。

阶段3：PPP回叫控制（callbackcontrol)
微软设计的PPP包括一个可选的回叫控制阶段。

该阶段在完成验证之后使用回叫控制协议（CBCP）如果配置使用回叫，那么在验证之后远程客户和NAS之间的连接将会被断开。

然后由NAS使用特定的电话号码回叫远程客户。

这样可以进一步保证拨号网络的安全性。

NAS只支持对位于特定电话号码处的远程客户进行回叫。

阶段4：调用网络层协议
在以上各阶段完成之后，PPP将调用在链路创建阶段（阶段1）选定的各种网络控制协议（NCP).例如，在该阶段IP控制协议（IPCP）可以向拨入用户分配动态地址。

在微软的PPP 方案中，考虑到数据压缩和数据加密实现过程相同，所以共同使用压缩控制协议协商数据压缩（使用MPPC）和数据加密（使用MPPE）。

数据传输阶段
一旦完成上述4阶段的协商，PPP就开始在连接对等双方之间转发数据。

每个被传送的数据报都被封装在PPP包头内，该包头将会在到达接收方之后被去除。

如果在阶段1选择使用数据压缩并且在阶段4完成了协商，数据将会在被传送之间进行压缩。

类似的，如果如果已经选择使用数据加密并完成了协商，数据（或被压缩数据）将会在传送之前进行加密。

点对点隧道协议（PPTP）
PPTP是一个第2层的协议，将PPP数据桢封装在IP数据报内通过IP网络，如Internet 传送。

PPTP还可用于专用局域网络之间的连接。

RFC草案“点对点隧道协议”对PPTP协议进行了说明和介绍。

该草案由PPTP论坛的成员公司，包括微软，Ascend，3Com，和ECI 等公司在1996年6月提交至IETF。

可在如下站点 参看草案的在线拷贝.PPTP使用一个TCP连接对隧道进行维护，使用通用路由封装（GRE）技术把数据封装成PPP数据桢通过隧道传送。

可以对封装PPP桢中的负载数据进行加密或压缩。

图7所示为如何在数据传递之前组装一个PPTP数据包。

第2层转发（L2F）
L2F是Cisco公司提出隧道技术，作为一种传输协议L2F支持拨号接入服务器将拨号数据流封装在PPP桢内通过广域网链路传送到L2F服务器（路由器）。

L2F服务器把数据包解包之重新注入（inject)网络。

与PPTP和L2TP不同，L2F没有确定的客户方。

应当注意L2F 只在强制隧道中有效。

（自愿和强制隧道的介绍参看“隧道类型”）。

第2层隧道协议（L2TP）
L2TP结合了PPTP和L2F协议。

设计者希望L2TP能够综合PPTP和L2F的优势。

L2TP是一种网络层协议，支持封装的PPP桢在IP，X.25，桢中继或ATM等的网络上进行传送。

当使用IP作为L2TP的数据报传输协议时，可以使用L2TP作为Internet网络上的隧道协议。

L2TP还可以直接在各种W AN媒介上使用而不需要使用IP传输层。

草案RFC“第2层隧道协议”对L2TP进行了说明和介绍。

该文档于1998年1月被提交至IETF。

可以在以下网站 获得草案拷贝。

IP网上的L2TP使用UDP和一系列的L2TP消息对隧道进行维护。

L2TP同样使用UDP 将L2TP协议封装的PPP桢通过隧道发送。

可以对封装PPP桢中的负载数据进行加密或压缩。

图8所示为如何在传输之前组装一个L2TP数据包。

PPTP与L2TP
PPTP和L2TP都使用PPP协议对数据进行封装，然后添加附加包头用于数据在互联网络上的传输。

尽管两个协议非常相似，但是仍存在以下几方面的不同：
1.PPTP要求互联网络为IP网络。

L2TP只要求隧道媒介提供面向数据包的点对点的连接。

L2TP可以在IP（使用UDP），桢中继永久虚拟电路（PVCs),X.25虚拟电路（VCs）或ATM VCs网络上使用。

2.PPTP只能在两端点间建立单一隧道。

L2TP支持在两端点间使用多隧道。

使用L2TP，用户可以针对不同的服务质量创建不同的隧道。

3.L2TP可以提供包头压缩。

当压缩包头时，系统开销（overhead）占用4个字节，而PPTP 协议下要占用6个字节。

4.L2TP可以提供隧道验证，而PPTP则不支持隧道验证。

但是当L2TP或PPTP与IPSEC共同使用时，可以由IPSEC提供隧道验证，不需要在第2层协议上验证隧道。

IPSec隧道模式
IPSEC是第3层的协议标准，支持IP网络上数据的安全传输。

本文将在“高级安全”一部分中对IPSEC进行详细的总体介绍，此处仅结合隧道协议讨论IPSEC协议的一个方面。

除了对IP数据流的加密机制进行了规定之外，IPSEC还制定了IPoverIP隧道模式的数据包格式，一般被称作IPSEC隧道模式。

一个IPSEC隧道由一个隧道客户和隧道服务器组成，
两端都配置使用IPSEC隧道技术，采用协商加密机制。

为实现在专用或公共IP网络上的安全传输，IPSEC隧道模式使用的安全方式封装和加密整个IP包。

然后对加密的负载再次封装在明文IP包头内通过网络发送到隧道服务器端。

隧道服务器对收到的数据报进行处理，在去除明文IP包头，对内容进行解密之后，获的最初的负载IP包。

负载IP包在经过正常处理之后被路由到位于目标网络的目的地。

IPSEC隧道模式具有以下功能和局限：
1.只能支持IP数据流
2.工作在IP栈（IPstack）的底层，因此，应用程序和高层协议可以继承IPSEC的行为。

3.由一个安全策略（一整套过滤机制）进行控制。

安全策略按照优先级的先后顺序创建可供使用的加密和隧道机制以及验证方式。

当需要建立通讯时，双方机器执行相互验证，然后协商使用何种加密方式。

此后的所有数据流都将使用双方协商的加密机制进行加密，然后封装在隧道包头内。