(1) PPPoE( Point to Point Protocol over Ethernet ,基于以太网的点对点协议)的工作流程包含发现( Discovery) 和会话( Session) 两个阶段,发现阶段是无状态的,目的是获得PPPoE 终端(在局端的ADSL设备上)的以太网MAC 地址,并建立一个惟一的PPPoE SESSION-ID。发现阶段结束后,就进入标准的PPP会话阶段。
(2) 当一个主机想开始一个PPPoE会话,它必须首先进行发现阶段,以识别局端的以太网MAC地址,并建立一个PPPoE SESSION-ID。在发现阶段,基于网络的拓扑,主机可以发现多个接入集中器,然后允许用户选择一个。当发现阶段成功完成,主机和选择的接入集中器都有了他们在以太网上建立PPP连接的信息。直到PPP会话建立,发现阶段一直保持无状态的Client/Server(客户/服务器)模式。一旦PPP会话建立,主机和接入集中器都必须为PPP虚接口分配资源。
(3) PPPOE可以防止ARP攻击。PPPOE能真正防止ARP的原因不在于,PPPOE接口IP和以太网接口IP不同,也不是通讯建立后不再用MAC等原因。而是因为PPPOE根本就没用的ARP协议,尽管它是用以太帧封装的,但它获得服务器MAC的方法不是用ARP协议,而是通过PADI包,所以它可以防止ARP攻击。
(1) PPP帧格式如下
看到总共多了8个字节,其中首尾字节都是帧的起始和结束标志位,A表示地址,C表示控制。
协议的两个字节,表示后面信息部分的数据协议是什么,包括:
数值 |
说明 |
0x0021 |
信息字段是IP数据报。 |
0xC021 |
信息字段是链路控制数据LCP。 |
0x8021 |
信息字段是网络控制数据NCP。 |
0xC023 |
信息字段是安全性认证PAP。 |
0xC025 |
信息字段是LQR。 |
0xC223 |
信息字段是安全性认证CHAP。 |
(2) PPPoE的报文就是在PPP的报文前面再加上PPPOE头和以太网的报头,使得PPPoE可以通过简单桥接设备连入远端接入设备。
PPPOE字段如下:
各个字段解释如下:
字段 |
说明 |
Destination_address |
一个以太网单播目的地址或者以太网广播地址(0xffffffff)。对于Discovery数据包来说,该域的值是单播或者广播地址,PPPoE Client寻找PPPoE Server的过程使用广播地址,确认PPPoE Server后使用单播地址。对于Session阶段来说,该域必须是Discovery阶段已确定的通信对方的单播地址。 |
Source_address |
源设备的以太网MAC地址。 |
Ether_type |
16bits,以太网类型。
(a) 0x8863(Discovery阶段或拆链阶段)。 (b) 0x8864(Session阶段)。 |
Ver |
4bits,PPPoE版本号,值为0x1。 |
Type |
4bits,PPPoE类型,值为0x1。 |
Code |
8bits,PPPoE报文类型。
(a) 0x00,表示会话数据。 (b) 0x09,表示PADI报文。 (c) 0x07,表示PADO或PADT报文。 (d) 0x19,表示PADR报文。 (e) 0x65,表示PADS报文。 |
Session_ID |
16bits,对于一个给定的PPP会话,该值是一个固定值,并且与以太网Source_address和Destination_address一起实际地定义了一个PPP会话。值0xffff为将来的使用保留,不允许使用。 |
Length |
16bits,定义PPPoE的Payload域长度。不包括以太网头部和PPPoE头部的长度。 |
数据 |
有时也称之为净载荷域,在PPPOE的不同阶段该域内的数据内容会有很大的不同。在PPPOE的发现阶段时,该域内会填充一些Tag(标记);而在PPPOE的会话阶段,该域则携带的是标准的点对点协议包(PPP Packet)。 |
(3) 在PPPOE 报文数据域中的标记封装格式
从上图中可以看出,标记的封装格式采用的是大家所熟知的TLV 结构,也即是(类型+长度+数据)。
(a) 标记的类型域为2 个字节,下表列出了各种标记类型的含义:
标记类型 |
标记说明 |
0x0000 |
表示PPPOE报文数据域中一串标记的结束,为了保证版本的兼容性而保留,在有些报文中有应用。 |
0x0101 |
服务名,主要用来表明网络侧所能提供给用户的一些服务。 |
0x0102 |
访问集中器名,当用户侧接收到了AC的回应的PADO 报文时,就可获从所携带的标记中获知访问集中器的名子,而且还可以据此来选择相应的访问集中器。 |
0x0103 |
主机唯一标识,类似于PPP数据报文中的标识域,主要是用来匹配发送和接收端的,因为对于广播式的网络中会同时存在很多个PPPOE的数据报文。 |
0x0104 |
AC-Cookies ,主要被用来防止恶意性DOS功击。 |
0x0105 |
销售商的标识符。 |
0x0110 |
中继会话ID ,对于PPPOE的数据报文也同样可以像DHCP 报文一样被中断到另外的AC上终结,这个字段则是用来维护另一个连接的。 |
0x0201 |
服务名错误,当请求的服务名不被对端所接受时,会在响应的报文中携带这个标记。 |
0x0202 |
访问集中器名出错。 |
0x0203 |
一般性错误。 |
(b) 标记的长度域为2 个字节,它用来指明标记数据域的长度。
(c) 标记的数据域中用来放置不同类型标记所对应的相关数据。
(1) 接入
当用户拨号接入ISP后,就建立了一条从用户PC机到ISP的物理连接。这时,用户PC机向ISP发送一系列LCP分组(封装成多个PPP帧),来建立LCP连接。这些分组及其响应选择了PPP参数以及进行网络层配置,NCP给新接入的用户分配临时IP地址。这样用户PC机就成为因特网上一个有IP地址的主机了。
(2) 总体流程
PPPoE的发现阶段一共分为4步,分别 是:PADI(PPPoE Active Discovery Initiation),PADO(PPPoE Active Discovery Offer),PADR(PPPoE Active Discovery Request),PADS(PPPoE Active DiscoverySession- confirmation)。当完成这四步之后,用户主机(PC)和访问集中器(AC)双方就能获知对方唯一的MAC地址和唯一的会话ID。MAC地址和 会话ID共同定义了唯一的PPPoE会话。
PPPoE Discovery的以太网类型域为0x8863。
主机广播发起分组,分组的目的地址为以太网的广播地址 0xffffffffffff ,CODE(代码)字段值为0x09( PADI Code), SESSION-ID(会话ID )字段值为0x0000。PADI 分组必须至少包含一个服务名称类型的标签( Service Name Tag ,字段值为0x0101),向接入集中器提出所要求提供的服务。
接入集中器收到在服务范围内的PADI 分组,发送PPPoE有效发现提供包分组, 以响应请求。其中CODE字段值为0x07( PADO Code), SESSION-ID 字段值仍为0x0000。PADO分组必须包含一个接入集中器名称类型的标签(Access Concentrator Name Tag,字段值为0x0102 ),以及一个或多个服务名称类型标签( Service Name Tag ,字段值为0x0101),表明可向主机提供的服务种类。PADO和PADI 的 Host-Uniq Tag 值相同。
主机在可能收到的多个PADO分组中选择一个合适的PADO分组,然后向所选择的接入集中器发送PPPoE有效发现请求分组。其中CODE字段为0x19 (PADR Code), SESSION_ID字段值仍为0x0000。PADR分组必须包含一个服务名称类型标签( Service Name Tag ,字段值为0x0101),确定向接入集线器(或交换机)请求的服务种类。当主机在指定的时间内没有接收到PADO,它应该重新发送它的PADI分组,并且加倍等待时间,这个过程会被重复期望的次数。
接入集中器收到PADR分组后准备开始PPP会话, 它发送一个PPPoE有效发现会话确认PADS分组。其中CODE字段值为0x65( PADS Code),SESSION-ID 字段值为接入集中器所产生的一个惟一的PPPoE会话标识号码。PADS分组也必须包含一个服务名称类型标签( Service Name Tag ,字段值为0x0101)以确认向主机提供的服务。当主机收到PADS 分组确认后,双方就进入PPP会话阶段。PADS和PADR的Host-Uniq Tag 值相同。
(1) Host-Uniq
在PPPoE发现阶段的四个步骤中,PPPoE头的Payload中始终含有这样一个TLV:
Tag_Type = 0x0103 (表示为Host-Uniq)
Tag_Length = 12 (12个字节的长度)
Tag_Value = 1c:00:00:00:00:00:00:00:38:00:00:00
Host-Uniq为主机唯一标识,类似于PPP数据报文中的标识域,主要是用来匹配发送和接收端的。因为对于 广播式的网络中会同时存在很多个PPPoE的数据报文。
(2) AC-Cookie
PADO和PADR数据包里面都含有 Tag_Type为AC-Cookie的Tag,20Bytes。Ac-Cookie是为了防止拒绝服务攻击(Denial of Service,简称DOS)。访问集中器(AC)能够根据PADR的源地址来重新产生唯一的Tag_Value。使用这种方法,AC可以确保PADI的 源地址是可达的,并对该地址的并行会话数进行限制。
PPP会话的建立,需要两端的设备都发送LCP数据包来配置和测试数据通信链路。用户主机与接入集中器根据在发现阶段所协商的PPP 会话连接参数进行PPP 会话。一旦PPPoE会话开始, PPP数据就可以以任何其他的PPP封装形式发送。所有的以太网帧都是单播的。PPPoE会话的SESSION-ID一定不能改变,并且必须是发现阶段分配的值。
LCP的Request 主机和AC 都要给对方发送, LCP协商阶段完成最大传输单元( MTU),是否进行认证和采用何种认证方式( Authentication Type )的协商。
(1) LCP协议数据报文分类
报文类型 |
说明 |
链路配置报文 |
用来建立和配置一条链路,主要包括Configure-Request 、Configure-Ack 、Configure-Nak 和Configure-Reject 报文。 |
链路维护报文 |
用来管理和调试链路, 主要包括Code-Reject、Protocol-Reject 、Echo-Request、Echo-Reply 和Discard-Request 报文。 |
链路终止报文 |
用来终止一条链路,主要包括Terminate-Request 和Terminate-Reply 报文。 |
(2) LCP协商过程
LCP 协商的过程如下:协商双方互相发送一个LCP Config-Request 报文,确认收到的Config-Request 报文中的协商选项,根据这些选项的支持与接受情况,做出适当的回应。若两端都回应了Config-ACK,则标志LCP链路建立成功,否则会继续发送Request 报文,直到对端回应了ACK报文为止。
说明:
字段 |
说明 |
Config-ACK |
若完全支持对端的LCP选项, 则回应Config-ACK报文, 报文中必须完全携 带对端Request 报文中的选项。 |
Config-NAK |
若支持对端的协商选项,但不认可该项协商的内容,则回应Config-NAK报文,在Config-NAK 的选项中填上自己期望的内容,如:对端MRU 值为1500,而自己期望MRU 值为1492,则在Config-NAK 报文中埴上自己的期望值1492。 |
Config-Reject |
若不能支持对端的协商选项,则回应Config-Reject 报文,报文中带上不能支持的选项,如Windows 拨号器会协商CBCP(被叫回呼) ,而ME60 不支持CBCP功能,则回将此选项拒绝掉。 |
若不能支持对端的协商选项,则回应Config-Reject 报文,报文中带上不能支持的选项,如Windows 拨号器会协商CBCP(被叫回呼) ,而ME60 不支持CBCP功能,则回将此选项拒绝掉。
(1) 客户端配置协商
(a) win7客户端发送 Configure-Request
(b) ubuntu服务端不支持CBCP功能,则回将此选项拒绝掉。回应Configure-Reject
(c) win7客户端重新发送 Configure-Request
(d) ubuntu 服务端发送 Configure-Ack
(2) 服务端配置协商
(a) ubuntu 服务端发送 Configure-Request
(b) win7 客户端发送 Configure-Ack
会话双方通过LCP协商好的认证方法进行认证, 如果认证通过了, 才可以进行下面的网络层
的协商。认证过程在链路协商结束后就进行。
(1) PAP(Password Authentication Protocol,口令认证协议)认证
PAP为两次握手协议,它通过用户名及口令来对用户进行验证。PAP验证过程如下:
当两端链路可相互传输数据时, 被验证方发送本端的用户名及口令到验证方, 验证方根据本端的用户表(或Radius 服务器)查看是否有此用户,口令是否正确。如正确则会给对端发送Authenticate-ACK 报文, 通告对端已被允许进入下一阶段协商; 否则发送NAK报文, 通告对端验证失败。此时,并不会直接将链路关闭。只有当验证不过次数达到一定值(缺省为10)时,才会关闭链路。
PAP的特点是在网络上以明文的方式传递用户名及口令,如在传输过程中被截获,便有
可能对网络安全造成极大的威胁。因此,它适用于对网络安全要求相对较低的环境。
(2) CHAP(Challenge Handshake Authentication Protoco,l 质询握手认证协议)认证
CHAP为三次握手协议。只在网络上传输用户名,并不传输用户口令,因此它的安全性要比PAP高。CHAP的验证过程为:
首先由验证方( Server)向被验证方( Client)发送一些随机产生的报文,并同时将本端的主机名附带上一起发送给被验证方。被验证方接到对端对本端的验证请求( Challenge)时,便根据此报文中验证方的主机名和本端的用户表查找用户口令字, 如找到用户表中与验证方主机名相同的用户,便利用报文ID、此用户的密钥用Md5 算法生成应答( Response),随后将应答和自己的主机名送回。验证方接到此应答后,用报文ID、本方保留的口令字(密钥)和随机报文用Md5 算法得出结果, 与被验证方应答比较, 根据比较结果返回相应的结果(ACK or NAK)
(a) 接受认证端发送Challenge。
(b) 申请认证端发验证请求报文。
(c) 接受认证端回应认证接受报文。
经过以上三次报文交互后, CHAP认证完成。
NCP有很多种,如IPCP、BCP、IPv6CP,最为常用的是IPCP( Internet Protocol Control Protocol )协议。NCP的主要功能是协商PPP报文的网络层参数, 如IP 地址, DNS Server IP地址,WINS Server IP 地址等。PPPoE用户主要通过IPCP来获取访问网络的IP 地址或IP 地址段。NCP流程与LCP流程类似,用户与ME 设备之间互相发送NCP Config-Request 报文并且互相回应NCP Config-Ack报文后,标志NCP己协商完,用户上线成功, 可以正常访问网络了。IPCP的协商过程是基于PPP 状态机进行协商的。经过双方协商,通过配置请求、配置确认、配置否认等包文交换配置信息,最终由initial ( 或closed)状态变为Opened 状态。IPCP状态变为Opened 的条件必须是发送方和接收方都发送和接收过确认包文。IPCP 协商过程中,协商包文可包含多个选项,即参数。各个选项的拒绝或否认都不能影响IPCP的UP,IPCP可以无选项协商,无选项协商也同样能够UP。选项有IP Address、网
关、掩码等,其中IP Address 是最重要的一个选项, 有些厂家的实现必须这个选项得到确认,大多数厂家的实现允许这个选项为空。
NCP的基本协商流程见下图:
用户和接入设备对IP 服务阶段的一些要求进行多次协商,以决定双方都能够接收的约定。
如: IP 业务阶段使用的IP 压缩协议等。双方的协议是通过报文中包含的Option 项进行协商的,每一个Option 都是一个需要协商的问题。最后双方都需要对方答复Configure_Ack 的同意报文。
(1) Configuration Request
(2) Configuration Ack
设备主动发送Echo Request 进行PPPoE心跳保活, 若3 次未得到服务器的响应, 则设备主动释放地址。发LCP Echo Request 的时候,魔术字字段要和之前通信的Configure_Request 使用的魔术字字段保持一致。
有些设备或终端不支持主动发送Echo-Request 报文, 只能支持回应Echo-Reply 报文。
PPPoE 还有一个PADT( PPPOE Active Discovery Terminate)分组,它可以在会话建立后的任何时候发送, 来终止PPPoE会话,也就是会话释放。它可以由主机或者接入集中器发送,目的地址填充为对端的以太网的MAC 地址。当对方接收到一个PADT( PPPOE Active Discovery Terminate)分组,就不再允许使用这个会话来发送PPP 业务。PADT 分组不需要任何标签,其CODE字段值为0xa7( PADT Code),SESSION-ID字段值为需要终止的PPP会话的会话标识号码。在发送或接收PADT后,即使正常的PPP终止分组也不必发送。PPP对端应该使用PPP协议自身来终止PPPoE会话, 但是当PPP不能使用时,可以使用PADT。