88705562_p0.jpg

1. Point-to-Point Protocol 特性

  • 在广域网中提供远距离的数据传输
  • 面向字节的点到点链路层协议，用于全双工的同异步链路上进行点到点的数据传输
  • 不要需要ARP解析和MAC地址的封装，只需要把报文发到该链路上，PPP工作后就会在本设备上得到一条对端的32位主机路由
  • 通过Keepalive报文来检测链路状态
  • PPP 的所有报文都需要双向协商（认证看情况例外）
  • PPP 是一个协议簇，本身没有协议状态，只有特定的协议，如 LCP 和 NCP 才有协议状态的转换
  • PPP 由三类协议簇组成
    • 链路控制协议（LCP）：建立、拆除和监控 PPP 链路
    • 网络层控制协议（NCP）：协商在该数据链路上所传输的数据包格式和类型
    • 扩展协议（CHAP和PAP）：网络认证

      2. 帧结构

image.png

3. LCP 协议

用于协商链路层参数。建立、拆除和监控数据链路参数协商。LCP可以自动检测链路环境，比如是否存在环路、协商链路参数、最大数据包长度、认证等

  • SP或MP
  • 最大接收单元MRU
  • 认证方式和链路防环（魔术字）

1）LCP 报文类型

报文类型 作用
Configure-Request 包含发送者试图使用的参数列表（请求建立连接）
Configure-ACK 表示完全接受对端发送的Configure-Request的参数（接受对端请求报文中的参数值）
Configure-NAK 表示对端发送的Configure-Request中的参数在本地不合法（某些参数取值不被认可）
Configure-Reject 表示对端发送的Configure-Requset中的参数本地不能识别（参数不能识别，进行匹配拒绝）

LCP 的三类报文

  • 链路配置：用于建立和配置链路
    • Configure-Request（匹配请求）
    • Configure-ACK（匹配确认）
    • Configure-NAC（匹配否认）
    • Configure-Reject（匹配拒绝）
  • 链路终止
    • Terminate-Request（终止请求）
    • Terminate-ACK（终止确认）

  • 链路维护

    • Code-Reject（代码拒绝）
    • Protocol-Reject（协议拒绝）
    • Echo-Request（回波请求）
    • Echo-Reply（回波应答）
    • Discard-Request（抛弃请求）

      2）LCP 链路参数协商

  • IPHC 支持对 RTP 和 TCP 报文头的压缩

    • RTP 压缩包括数据部分和头部分，典型的 RTP 负载是 20 ~ 160 字节，压缩比约为 1.82
    • TCP 压缩后可到 3 ~ 5 字节
  • 魔术字检测环路：收到一个 Configure-Request 报文后，将报文中的魔术字与本地产生的魔术字进行比较
    • 如果收到魔术字如果不同，则表示无环路，当其他参数也协商成功后，使用 Configure-ACK 报文进行确认
    • 如果收到魔术字相同，则发送一个 Configure-NAK 报文，携带一个新的魔术字。另一端设备收到 Configure-NAK 报文后，会产生新的 Configure-Request 报文，携带新的魔术字。如果链路有环路，则这个过程会不断的持续下去；如果没有环路，则报文交互会很快恢复正常 | 参数 | 作用 | 规则 | 缺省值 | | —- | —- | —- | —- | | 最大接受单元（MRU） | PPP 数据帧中 Information 字段的总长度 | 自动协商两端设置的较小值 | 1500 | | 认证协议（PAP、CHAP） | 认证对端使用的认证协议 | 被认证方必须支持认证方使用的认证协议并正确配置，否则协商不成功 | 不认证 | | 魔术字（Magic-Number） | 随机产生的数字，用于建立链路环路，如果收到的 LCP 报文中的魔术字和本地产生的魔术字相同，则认为有环路 |
      - 一端支持而另一端不支持魔术字，表示链路无环，认为协商成功
      - 两端都支持则使用检测机制
      | 开启 | | 协议字段压缩（IPHC） | IP 报文头压缩协议是一个主机到主机的协议，用于在 IP 网络上承载语音、视频等实时多媒体业务，在 PPP 链路上和 FR 链路上应用的低速链路技术（包括 POS 接口） | 两端需要同时开启 | 未开启 | | 多链路捆绑（MP） | 增加链路带宽，实现链路负载和提高冗余性 | 两端需要同时开启 | 未开启 | | 链路质量监控 | 监控链路质量 | 两端需要同时开启 | 未开启 | | 地址和控制字段压缩 | 属于链路层压缩，针对数据帧头中的地址和控制字段进行压缩 | 两端需要同时开启 | 未开启 |

3）LCP 链路协商

① 链路协商成功过程

image.png

  1. R1 向 R2发送 Configure-Request 报文，该报文包含链路层的参数，每个链路层参数使用 “类型，长度，取值” 的结构表示
  2. R2 收到 Configure-Request 报文后，并且每个参数取值都能接受，则回应一个 Configure-ACK 报文
  3. R1 如果没有收到 R2 发送的 Configure-ACK 报文，则每隔 3s 重传一次（最多发送10次）。如果连续发送 10 次仍然没有收到 Configure-ACK 报文，则认为对端不可用，停止发送 Configure-Request 报文；R1 如果收到 R2 发送的 Configure-ACK 报文，则链路协商成功

    ② 链路协商不成功过程

    如果连续 5 次协商仍然不成功，则不再继续协商

image.png

  1. R1 向 R2发送 Configure-Request 报文后，如果 R2 认为部分或全部参数值不认同，则 R2 需要向 R1 回应一个 Configure-NAK 报文
  2. R2 回应的 Configure-NAK 报文中，只包含了不能认同的参数列表，并且将参数取值修改为自身能认同的取值发向 R1
  3. R1 根据收到的 Configure-NAK 报文后，将 Configure-Request 中的参数修改为 R2 能够认同的值，重新发送

  4. 如果连续 5 次协商仍然不成功，则不再继续协商

    ③ 链路协商不能识别过程

    image.png

  5. R2 收到 R1 发送的 Configure-Request 报文后，如果 R2 不能识别此报文中的部分或全部链路层参数，则 R2 需要向 R1 回应一个 Configure-Reject 报文，该报文中只包含不被识别的参数列表

  6. R1 收到 R2 的 Configure-Reject 后，重新发送一个 Configure-Request 报文，该报文中不包含 R2 不识别的参数列表

    ④ 检测链路状态过程

    LCP 建立连接之后，使用 Echo-Request 和 Echo-Reply 报文检测链路状态

image.png

  • 当设备收到一个 Echo-Request 报文后，应当回应一个 Echo-Reply 报文，表示链路状态正常

    ⑤ 连接关闭过程

    • 认证不成功或手工关闭等原因可以使 LCP 关闭建立的连接
    • LCP 建立连接之后，使用 Terminate-Request 和 Terminate-ACK 报文连接关闭

image.png

  • 设备通过 Terminate-Request 报文请求对端关闭连接，对端设备收到后，需要回应 Terminate-ACK 报文进行确认关闭连接
  • 如果发送了 Terminate-Request 报文，但没有收到 Terminate-ACK，则每 3s 重传一次，连续两次重传没有收到 Terminate-ACK 报文，则认为对端不可用，关闭连接

    4. NCP 协议

用于协商网络层参数。对不同的上层协议进行连接建立和参数协商（如 IPCP、IPXCP、MPLSCP、IPv6CP）

1）IPCP

  • IPCP 用于协商 IP 参数，使 PPP 可以传输 IP 数据包
  • IPCP 使用和 LCP 相同的协商机制和报文类型，但 IPCP 不是调用 LCP，只是工作过程、报文等和 LCP 相同
  • 两端 IP 地址不在同一网段也会进行 IPCP 协商

    2）IPCP 静态协商 IP 地址

    image.png
  1. R1 和 R2 都需要发送 Configure-Request 报文，在此报文中包含本地配置的 IP 地址
  2. R1 和 R2 收到对端的 Configure-Request 报文之后，检查其中的 IP 地址，如果该 IP 地址是一个合法的单播地址，并且没有与本地的 IP 地址冲突，则认为对端可以使用该地址，此时会回应一个 Configure-ACK 报文进行确认

  3. 通过 IPCP 发送的信息，PPP 链路的两端都可以知道对端使用的 32位 IP 地址

    3）IPCP 动态协商 IP 地址

    image.png

  4. R1 向 R2 发送一个 Configure-Request 报文，此报文中含有 IP 地址 0.0.0.0（代表向对端请求 IP 地址）

  5. R2 收到报文后，认为 0.0.0.0 地址不合法，此时会使用 Configure-NAK 报文回应一个新的 IP 地址
  6. R1 收到后，更新本地 IP 地址为 R2 分配的 IP 地址，并重新发送一个 Configure-Request 报文，该报文中包含 R2 为 R1 分配的 IP 地址
  7. R2 收到报文后，认为包含的 IP 地址为合法地址，回应一个 Configure-ACK 报文进行确认

    5. 认证

可以进行单向或者双向认证

认证协议 口令方式 特性
PAP（密码认证协议） 明文口令 两次握手交互
1. 被认证方发起请求认证
1. 认证方进行校验
CHAP（挑战握手协议） 密文口令，采用 Hash 算法（可以防止DDoS攻击） 三次握手交互
1. 认证方进行拨入
1. 认证方向被认证方发起挑战报文
1. 认证方发送响应报文，认证方进行校验是否成功

1）PAP 认证过程

PPP - 图10

  1. 被认证方将配置的用户名和密码使用 Authenticate-Request 报文，以明文的方式发送给认证方
  2. 认证方收到被认证方发送的用户名和密码后，查看本地数据库中的用户名和密码是否匹配；如果匹配则返回 Authenticate-ACK 报文，表示认证成功；如果不匹配则返回 Authenticate-NAK 报文，表示失败

    2）CHAP 认证

    ① CHAP 报文类型

    Challenge 对密码做 Hash 运算（将 Identifier + 密码 + Challenge 连成一个整体），得到 16 字节长的摘要信息，然后放在 Respoonse 报文中

报文类型 作用
Challenge（挑战） 用于认证方向被认证方发起验证过程，Data 字段包含 Challenge
Response（响应） 用于被认证方向认证方返回用户信息，Data 字段含有用户名以及 Hash 运算后的密码信息
Success（成功） 用于认证方向被认证方发送认证成功信息
Failure（失败） 用于认证方向被认证方发送失败信息

② CHAP 认证过程

PPP - 图11
认证方配置了用户名的认证过程：

  1. 认证方主动发起认证请求，认证方向被认证方将本端的用户名附带在随机产生的 Challenge 报文上发送
  2. 被认证方接受到认证请求后，先检查本端接口上是否配置了 CHAP 密码。如果配置，则被认证方将生产的密文（Identifier + 密码 + 随机数）和自己的用户名发回给认证方；如果没有配置，则根据认证方发来的用户名在本端的 AAA 数据库中查找对应的密码，将产生的密文（Identifier + 密码 + 随机数）和自己的用户名通过 Respons 报文发回给认证方
  3. 认证方将自己本身保存的密码、Identifier 和随机数进行 Hash（MD5），并和收到 Response 报文中的密文进行比对。如果一致则认证通过；如果不一致则认证失败

认证方没有配置用户名的认证过程：

  1. 认证方主动发起认证请求，认证方向被认证方发送随机产生的 Challenge 报文
  2. 被认证方接收到认证方的请求后，将 Identifier、密码和随机数进行 Hash，将生成的密文和自己的用户名通过 Respoons 报文发回给认证方
  3. 认证方将自己本身保存的密码、IDientifier 和随机数进行 Hash，并和收到 Respoonse 报文中的密文进行比对。如果一致则认证通过；如果不一致则认证失败

    3）CHAP 与 PAP 验证过程对比

  • PAP 认证中，口令以明文方式在链路上发送，完成 PPP 链路建立后，被验证方会不停地在链路上反复发送用户名和口令，直到身份验证过程结束，所以安全性不高
  • CHAP 认证中，验证协议为三次握手验证协议。它只在网络上传输用户名，而并不传输用户密码，因此安全性比 PAP 认证高

    6. 建链过程

1）阶段解释

image.png

  • Dead 阶段：链路不可用阶段（接口Down）
  • Establish 阶段：链路建立阶段
  • Authenticate 阶段：验证阶段
  • Network 阶段：网络层协商阶段
  • Terminate 阶段：网络终止阶段

    2）建立链接过程

  1. 开始建立 PPP 链路时，先进入 Establish 阶段，PPP 链路进行 LCP 协商（协商内容包括：SP、MP、MRU、验证方式、魔术字等），如果链路被断开则会返回到 Dead 阶段（Dead 阶段 也是 PPP 链路开始和结束的阶段）
  2. 如果有认证，进入 Authenticate 阶段，开始 CHAP 或 PAP 认证，如果验证成功 LCP 状态仍为 Opened；如果没有认证直接进入 Network 阶段进行 NCP 协商，如果协商失败直接进入 Terminate 阶段，拆除链路，LCP 状态转换为 Down
  3. Network 阶段进行 NCP 协商。通过 NCP 协商来选择和配置一个网络协议并进行网络层参数协商
  4. NCP 协商成功后，PPP 链路将一直保持通信。NCP 协商包括 IPCP、MPLSCP 等，IPCP 主要协商双方的 IP 地址
  5. Terminate 阶段，如果所有的资源都被释放，通信双方将回到 Dead 阶段，直到通信双方重新建立 PPP 链接。PPP 能在任何时候终止链路

    7. 其他注意事项

  • PPP 两端配置的 IP 地址不一致是否可以通信？
    • 可以，PPP 的 NCP 协议可以获取到对端设备的 IP 地址，即使两端的 IP 地址不在同一网段依然可以通信
  • PPP 环路问题
    • 在同一个网段：PPP 会产生自身和邻居的 32 位主机路由，并且还会产生一条去往该网段的路由和广播地址路由，如果有流量去往不存在的 IP 地址，则会通过去往该网段的路由进行转发，从而造成环路
    • 在不同的网段：PPP 会产生自身和邻居的 32 位主机路由，并且只产生一条去往本端网段的路由和本端广播地址的路由，不会产生对端网段的路由，所以不会造成环路
  • OSPF 在 PPP 链路上 Cost 的问题
    • 同一网段：由于直连可达，直连优于 OSPF ，所以路由表中 Cost 为 0
    • 不同网段：由于需要计算去往对端地址开销 48 和去往对端网段的开销 48，所以在路由表中为 96
  • PAP 和 CHAP 协议各自的特点
    • PAP：两次握手机制，采用明文方式传输密码，被认证方主动请求建立连接（对攻击的处理效果不好）
    • CHAP：三次握手机制，采用密文传输密码，认证方主动请求建立连接，被认证方将密码通过MD5算法生成的密文和自己的用户名发回给认证方（有效的避免再生攻击和尝试攻击）
  • 用户名/密码配置在接口和全局的区别
    • 被认证方：接口有限，接口没有配置在查全局
    • 认证方：只使用全局用户名对应的密码
  • 挑战报文的随机数的作用和缺点
    • 作用：防重放攻击，如果发现报文中有以前使用的随机数，就认为存在重放攻击
    • 缺点：需要额外保存使用的随机数，随着记录的时间越长，保存和查询的开销越大