4. EAP数据包格式

下图是EAP数据包格式简略图。数据传输从左边到右边。

Code编码

编码项是一个字节，表示EAP数据包类型，编码值有如下几项：

1请求

2应答

3成功

4失败

由于EAP仅定义上面4种编码，其他编码的EAP数据包会被认证端和对等端丢弃。

Identifier标识

标识项是一个字节。用于匹配应答和请求。

Length长度

长度项是两个字节，表示整个EAP数据包有多少个字节，包括编码、标识、长度和数据项。超出指定长度的数据作为数据链路层的无效数据，一收到就必须丢弃。如果收到的信息里，长度项的值大于所收到的字节数，则须丢弃该信息。

Data数据

数据项可以是0个或多个字节。数据项的格式是由编码项决定的。

4.1. 请求和应答

描述

认证端发请求包（编码项值为1）给对等端。每个请求都有一个类型项，用于表示请求什么。要等到一个有效的应答、重试次数超出或者底层失败提示后，其他请求才可以发送。

重发请求必须保持相同的标识，以便区分是否新请求。数据项的内容是由请求类型决定的。对等端必须发送一个应答来响应一个有效的请求。应答必须只能在收到一个有效请求后才发送，绝不能用定时器重复发送。

如果对等端收到一个有效的重复请求，对该请求它已发送过一次应答了，这时无需再去处理该请求，只须将原先的应答重发一次。必须按顺序处理接收到的请求，必须等处理完一个请求后才能进行下一个请求。

下面是请求和应答数据包格式简略图。数据从左到右传输。

Code编码

1表示请求

2表示应答

Identifier标识

标识项是一个字节。如果由于等待应答超时，重新发送请求包，则该包的标识项应该和上次的保持一致。认证端收到的应答标识与它发送的请求标识不一致时，应丢弃该应答。

为了不混淆新请求和重发，新包的标识值只需不同于上次请求标识，不必都是唯一的。有一个办法可达到这个目的，即标识用一个初始化值，每次发请求时递增一次。建议使用一个随机数而不是0来初始化标识,这样可以增加序列攻击的难度。

由于对每次会话来说标识空间是唯一的，不会限制认证端同时只有256个认证会话。类似，对于重认证，EAP会话可能持一段较长时间，也不会限制仅256个来回。

实现时需注意：认证端负责重发请求信息。如果请求信息是来自其他地方，比如后台认证服务器，那么认证端需要保存该请求的副本以便实现重发请求。对等端负责在处理副本请求信息前先检测和转发副本请求信息，包括将他们转给外方。认证端也负责将标识不匹配的应答信息丢弃，包括将它们发给后台认证服务器用于验证。由于认证端可以在收到对等端发出的应答前重发申请，认证端可以收到多个应答，每应答都有匹配的标识。直到认证端收到一个新请求，否则标识值是不会变的，因此认证端转发应答给后台认证服务器，一次只转发一个。

Length长度

长度项由两个字节组成，表示EAP包的字节数，包括编码、标识、长度、类型和类型数据项。超出Length值的数据必须丢弃。

Type类型

类型项由一个字节组成，表示请求或应答的类型。每个EAP请求或应答都必须指定一个类型。本文第５节有提到类型的初始化规范。

应答的类型项要么与请求类型匹配，要么符合普通的Nak或者扩展的Nak(请看5.3节)以表示该请求类型不被对等端接受。在发送一个非Nak应答后，对等端绝不能发一个Nak(不管是普通Nak或扩展Nak)去响应请求。EAP服务器收到与请求不匹配的应答时必须丢弃。

类型数据

类型数据项因请求或都相关应答的类型而异。

4.2. 成功和失败

认证端在完成EAP认证方法后，向对等端发送一个成功包，表示认证端已成功认证对等端。认证端必须发一个编码为3(成功)的EAP包。如果认证端不能认证对等端（无效　应答），在处理完没成功EAP方法后，必须发一个编码值为4（失败）的EAP数据包。认证端在发出一个失败应答前可能会发多个请求，以便定位错位。成功和失败包绝不能带有其他数据。

如果指定的方法规范里没提到支持该点的话，认证端是绝不能发成功或失败包的。当对等端收到发送方没明确允许的成功或失败包时，必须丢弃。这样就可以保证流氓认证端不能够在没经正常的EAP方法会话时通过发送成功包来直通认证。

实现时需注意：由于成功和失败包不会有应答，认证端是不会重发的，因而就有可能丢失。对等端必须允许该情况发生。请看3.4节，如何处理底层成功和失败指示。

如2.1节描述的，EAP会话只允许有单个的EAP认证方法。EAP方法可能有结果提示。认证端发一个失败提示给对等端后，不管对等端是否应答，都必须发一个失败包。当认证端发一个成功提示给对等端，并接到对等端的成功提示后，必须发一个成功包。

对于对等端，一旦方法没成功完成（即，要么对等端发一个失败结果指示，要么对等端决定中断会话），对等端必须中止会话并对底层提示失败。对等端必须忽略成功包。最后，超时不会引起失败包丢失。

对于对等端，在两边交换成功结果提示后，必须丢弃失败包。对等端可能在没收到EAP成功包时推断EAP成功包已丢失，认证已成功。

如果认证端没发结果提示，对等端将会继续会话，一旦方法完成，对等端会等待一个成功或失败包，这两个都不能丢弃。在没收到成功或失败包时，对等端应该中断对话，以免因丢失包为EAP失败包时引起的长时间超时。

如果对等端想被认证端认证，但又做不到时，认证端必须发一个失败包，绝不能发成功包。在限制访问的情况下，认证端可能忽略对等端的认证请求。这时认证端必须发一个成功包。

当对等端被认证端成功认证，但认证端没发结果提示时，认证端可能发失败包以拒绝访问，这时对等端没有访问网络的权限。

下面是成功和失败包格式的简略图。数据传输从左到右。

Code编码

3表示成功

4表示失败

Indetifier标识

标识项由１个字节组成，用于匹配应答和回应。标识项必须与应答的标识一致。

Length长度

4

4.3. 重发行为

由于认证进程常涉及用户输入，在确定重发策略和认证超时时需多加注意。默认情况下，EAP是跑在不可靠的底层，EAP重发定时器应该被动态评估。建议最大的重发次数为3~5次。

当跑在一个可靠底层时，认证端重发定时器应该设置为一个无限值，表示EAP层不重发。对等端可能还保持着一个超时值，这样可以避免无限期等待请求。

当认证进程要求用户输入时，会话时间取决于用户的响应性能而不是网络特性，这样动态RTO评估就没有帮助了。相反，重发定时器应该设置为适合用户反应的值，某些情况下要求更长的超时值，比如涉及到令牌卡。

为了将EAP认证端引向一个合适的超时值，后台认证服务器可以给认证端一些提示。

为了动态评估EAP重发定时器，建议使用SRIT、RTTVR和RTO等评估算法，包括使用Karn算法，再配合下面的修改：

[a]为了避免在分布式系统里多个定时器的同步行为，重发定时器用一个抖动值计算，该抖动值是通过使用RTO值和随机增加一个在~RTOmin/2~RTOmin/2之间的值得出的。另外，也可能通过计算得出这个抖动值。这就是伪随机。请参考RFB1750，讨论伪随机数的产生。

[b]当EAP在一个单链路上传输时，更小的RTOinitial值、RTOmin和RTOmax可能用到。建议RTOinitial=1秒、RTOmin=200ms、RTOmax=20秒。

[c]当EAP在一个单链路上传输时（相对于Internet），评估会基于每个认证端而不是基于每个会话。这样就使重发评估可以最大限度地使用链路层的信息。

[d]在多次回退定时器后，EAP实现可能会清除SRTT和RTTVAR，因为在这种情况下，当前的SRTT和RTTVAR可能是假的。一旦SRTT和RTTVAR被清除后，应该用下一个RTT样令（RFC2988中有描述）去初始化它们。