802.1x兼容实现
基于端口的控制最大的特点就是不需对现有的数据进行封装，这种特点可以带来一大堆的好处，其中之一就是验证的灵活的实现。排开了与现有协议的兼容性的问题，只需要简单的程序就可实现具备认证能力的客户端。
然后灵活造成的负面效应就是各种私自改动标准协议的现象的泛滥。由于802.1x协议是基于supplicant,authenticator, authentication server三方的协议。而现实中这三方全部利用厂商提供的软硬件实现。于是出现了很多私有化的802.1x协议的设备和客户端。
除了802.1x本身优越的特性之外，协议还对厂商来说具备一定的广告价值。能够在自己的设备上实现802.1x是很值得炫耀的事情。然而还有一系列其他因素影响的厂商的实现。于是厂商的实现中出现了一系列的限制功能。至于这些功能是否侵犯了用户的权力不在本文的讨论范围之内。本文主要讨论一般私有协议的特征以及厂商如何在标准协议的基础上实现这些特性的。本文并不介绍802.1x协议本身，如果对802.1x比较陌生的话请参阅相关的资料。
由于厂商需要将802.1x的字样写在产品的功能列表上，这就导致了厂商必须完整的实现802.1x而私有的加上厂商定制的部分。通常情况下，限制多加在supplicant所安装的计算机上，如检测多网卡、代理服务器等等。这些限制通常也都在客户端完成，而且也不需要向设备传输数据。所以，厂商只要开发出具有一大队限制的客户端，然后在协议中限制使用厂商自己的客户端就行了！
考虑代码的重复利用和人的懒惰特性。厂商是不会将似有的协议实现得特别背离标准的。如果那一现幸运的出现国际客户的话，厂商必须提供具有标准验证功能的产品。所以从supplicant,authenticator都要实现标准的802.1x协议。而私有的协议，一般只在标准的验证过程中附加一些信息。而且这种附加必须可以通过软件的设置灵活的去掉。甚至，在同标准的设备认证时，可以让设备忽略这些信息的存在。
本着这条宗旨，RG实现的客户端将对客户端的认证加在了客户端所有的请求和回应的数据包的尾端。而且，这种追加并未改变标准协议数据报文中所标称的数据包长度。也就是说，标准的设备根本不会处理这些追加的信息。
这种标识是单向的，也就意味着只能通过提取一些简单的authenticator也能获取的信息，进行简单的加密或者计算之后发送出去。比如IP,netmask,dns,gateway.等等。在RG的协议中还包含了客户端的程序名称等信息。由于IP,netmask,dns,gateway等等在有些情况下可能只能在认证之后才能通过dhcp得到。因此个人猜想应该是有程序名之类的才是这种判断的有效部分。而IP等信息可能仅仅是作为未来可能的实现包含在了协议中，方便将来只在交换机升级软件即可进行更下严密的限制。
另一个影响实现的因素就是性能，性能导致私有的化的协议附加不可能有比标准EAP中的几种认证算法有更高的时间空间复杂度。如果在客户端还好，在交换机等设备上过多的请求将导致显著的性能下降，影响厂商的产品在评测中的表现。所以，上文提到的认证信息交换机无法全部进行判断。一个很好的证据就是，在我测试的学校开始用xsuppcliant向RG私有组播地址发送标准的认证数据报文，从Start-Frame开始一直到Response/OTP之前一直能同交换机进行有效的通信。而只有进行Respond/OTP的时候才需要在报文的尾端加入RG私有的信息。然而过了几天正好在交换机升级以后。Start-Frame也必须追加私有信息才能获得回应了。而这期间整个学校的学生用户一直在正常使用RG原来的windows客户端。
由于这种方法易于从数据报文破解，厂商还必须实现其他的方法来提高自己的客户端被替换的难度。连接的保持提供了这个机会，在标准中连接的保持属于状态机的实现部分。而RG使用一个种定时发送数据包的方法来保证客户同authenticator之间的连通状态。而且，交换机反会的success包中出了一些文字信息之外包含了一个会话的初始ID，通过某种算法的依次计算，每次发送不同的数据包来和交换机确认连接。而交换机会也会通过计算来推断客户端的合法性。
基于以上的原理，就可以在开源的客户端上实现对私有协议的兼容。echo/keepalive包是标准没有的，但是通过状态机定时隔几秒改变一些标识来处理发包也是很容易的。由于目前尝试破解私有协议的人士很多，厂商的算法被反汇编以后已经被重写常了C语言代码。只要将这些代码嵌入到一个开源稳定的客户端当中，即可实现多个平台的无限制的私有802.1x认证。
