【每日文稿】2025-01-20
今日共有11篇文稿更新，涉及6个area里的9个WG
ART
satp
- Title: Secure Asset Transfer Protocol (SATP) Gateway Crash Recovery Mechanism
- Authors: Rafael Belchior(rafael.belchior@tecnico.ulisboa.pt), Miguel Correia(miguel.p.correia@tecnico.ulisboa.pt), Andre Augusto(andre.augusto@tecnico.ulisboa.pt), Thomas Hardjono(hardjono@mit.edu)
- Summary: 本文是关于在数字资产转移协议(SATP)中的崩溃恢复机制。主要讨论了两种模式：自愈模型和主备备份模型。 在自愈模型中，当一个节点发生故障时，它会尝试自我恢复。如果超出了资产转移的时间限制，它将向其他节点发送“恢复”消息来请求最新的状态。然后，它根据共享的日志进行同步，更新自己的日志并继续执行协议。 在主备备份模型中，一个节点可能会永远无法恢复，但其失败会被另一台备份节点检测到，并将其视为主节点。如果有心跳消息，则可以推断出这个错误，从而自动接管主节点的角色。 总的来说，这两种模式都考虑到了数据丢失的风险，并确保了交易的一致性和完整性。
- Diff: 新的版本文档提供了更详细的信息和定义了安全资产转移协议（SATP）的安全恢复机制。该机制在SATP中的两种角色之间实现故障恢复，并遵守双重验证不发生的情况。文档提出了两种不同的恢复模型：自愈模型和备份门当户对模型。这两种模型分别适用于不同情况下的系统。 与旧版本相比，新的文档添加了关于恢复流程、日志格式以及如何存储日志等细节。它还提到了公共和私有日志存储模式的选择，这些模式有不同的优点和缺点，取决于系统的部署环境。此外，文档还强调了日志API的重要性，用于提供标准化的日志访问接口。 总的来说，新的文档提供了更多详细的恢复策略和方法，有助于满足当前需要增加系统可用性和可靠性的需求。
stir
- Title: OCSP Usage for Secure Telephone Identity Certificates
- Authors: Jon Peterson(jon.peterson@transunion.com), Sean Turner(sean@sn3rd.com)
- Summary: 本文主要讨论了在电信网络中使用证书来认证电话号码时，如何实现实时状态信息的需求。提出了一种解决方案：通过在线证书状态协议（OCSP）在PASSporT中插入一个声明，以将实况信息发送给验证服务。文稿分析了不同方案的优缺点，并给出了推荐的方法。 总的来说，文稿介绍了OCSP作为一种解决方案，为需要实时状态信息的情况提供了支持。它允许验证服务从认证中心获取证书的实况信息，而不需要进行额外的网络往返。文稿还探讨了隐私和安全方面的考虑，提出了相应的解决方案。
- Diff: 这篇新版本的英文标准文稿主要介绍了如何使用在线证书状态协议（OCSP）来验证基于电话号码授权列表的数字证书的时效性。相对于旧版，主要有以下几方面的主要区别： 1. 新版增加了对OCSP扩展的支持，包括在PASSporT中插入OCSP声明，以实现实时获取认证服务关于正在处理的电话号码状态。 2. 增加了对电话号码授权列表（TN授权列表）支持，并讨论了如何利用OCSP与之配合，以满足动态更新电话号码列表的需求。 3. 对于多级证书授权（delegate certificates），推荐采用OCSP来验证其有效性，以弥补传统方式依赖长生命周期证书导致的不足。 4. 引入了用于标识电话号码和证书授权列表的新的OCSP扩展元素。 5. 提出了几种减少网络往返请求时间延迟的方案，如通过将OCSP查询同步到客户端，或者从认证服务直接检索。 总的来说，新版标准化文档更注重实用性和灵活性，提供了更多的实现细节和建议，旨在适应不同环境和需求，提供更为高效的证书验证机制。
GEN
modpod
- Title: IETF Community Moderation
- Authors: Lars Eggert(lars@eggert.org), Eliot Lear(lear@lear.ch)
- Summary: 本文主要提出了建立一个社区管理员团队的想法，以统一管理所有参与渠道的干预行为。该团队由五个人组成，包括来自世界各地的人士，以便更好地应对全球性的IETF参与者。此外，它还规定了与工作小组的沟通和协调方式，并允许他们决定在任何情况下采取何种行动来解决问题。 该文档指出，如果必要，可以设立额外的过程或规则来执行其角色，但这些过程和规则应得到社区意见，并且需要公开而不是记录为RFC系列。此外，对于新加入的人员，他们需要接受培训，而现有的人员也需要进行更新。 最后，该文档讨论了如何处理冲突，以及如何将情况提交给理事会进行考虑。此外，还指出了如何保护组织免受可能由于非法、粗俗或明显骚扰的行为所带来的法律风险。
- Diff: 本文提出了一个新的改进方案，为所有的互联网工程任务组（Internet Engineering Task Force, IETF）提供一种统一的管理机制来处理各种参与渠道中的破坏性行为。这个团队将由至少五个人组成，并由IEF特设委员会（Internet Engineering Task Force Standing Committee, IESG）任命和替换成员。该团队负责制定并执行针对所有参与渠道的统一规范，包括邮件列表、聊天频道等。它还提供了一个讨论平台，允许参与者提出关于如何处理破坏性行为的意见。在处理任何争议时，参与者应首先向团队报告，然后由团队决定是否采取行动。 与旧版本的主要区别在于： 1. 新版本引入了一个专门的“IETF社区论坛”，用于公开讨论关于角色分配、过程设定以及其他相关问题。旧版没有这一部分。 2. 新版本要求创建一个公共的讨论列表，供社区成员讨论整个治理框架及其实施细节。旧版中没有明确提及这一点。 3. 新版本增加了对团队多样性的要求，以确保它们能够有效运营全球范围内的各个时间区，以及能迅速响应问题。旧版没有提到多样性要求。 4. 新版本更加强调透明度，规定了对于团队操作流程和决策的详细描述，以便让社区可以更好地理解其工作。旧版中缺乏这方面的内容。
INT
intarea
- Title: IPv4 routes with an IPv6 next hop
- Authors: Juliusz Chroboczek(jch@irif.fr), Warren "Ace" Kumari(warren@kumari.net), Toke Høiland-Jørgensen(toke@toke.dk)
- Summary: 该文档讨论了使用IPv6地址作为下一个跳地址来路由IPv4数据包的技术，即所谓的"v4-via-v6"路由。这种技术使网络能够跨越没有分配IPv4地址的路由器之间的网络，从而实现IPv4到IPv6的连接。文中还详细描述了这一技术在操作、实施和安全方面的考虑，并讨论了与传统IPv4和IPv6路由相关的协议。最后，文稿总结了支持IPv4-via-v6功能的设备及其状态。 总的来说，本文是关于改进IPv4数据包路由的一个重要贡献，它扩展了IPv4和IPv6路由协议的功能，并提供了一种灵活的方式来利用IPv4数据包跨越不同地址族的网络。然而，由于现有的IPv4和IPv6路由协议可能无法直接处理这种情况，因此需要开发新的路由协议来支持这一新特性。
- Diff: 上述新版本的英文标准文稿（draft-chroboczek-intarea-v4-via-v6-03）是针对IPv4路由和IPv6下一跳技术的一种探讨。主要内容包括： 1. 提出了“v4-via-v6”路由的概念，即使用IPv6下一跳地址来路由IPv4数据包。 2. 描述了这一概念在操作层面是如何实现的，包括结构、前向平面的操作、以及各种协议对v4-via-v6支持的方式等。 3. 讨论了如何通过配置修改使现有设备支持v4-via-v6功能。 4. 对于可能遇到的安全问题，提出了相应的解决方案。 5. 对一些关键概念进行了定义和解释。 相较于旧版本，本版主要侧重于讨论v4-via-v6路由的技术实现和设计，增加了关于IPv4路由、IPv6下一跳和安全等方面的讨论，同时给出了详细的参考链接。总的来说，本版更加强调了v4-via-v6路由技术的实现细节和相关安全性考虑。
- Title: Safe(r) Limited Domains
- Authors: Warren "Ace" Kumari(warren@kumari.net), Andrew Alston(andrew-ietf@liquid.tech), Éric Vyncke(evyncke@cisco.com), Suresh Krishnan(suresh.krishnan@gmail.com), Donald E. Eastlake 3rd(d3e3e3@gmail.com)
- Summary: 本文主要讨论了安全有限域协议的问题。它分析了有限领域协议泄漏的风险，并提出了一种新的解决方案：使用层二协议标识机制来确保有限领域的协议不会泄露到网络之外。这个机制允许在边界节点上手动配置特定的层二协议标识符，以防止协议泄漏。同时，文中还讨论了一些相关的安全性考虑和IANA考虑，以及作者的联系方式等信息。总的来说，文稿提供了一个有效的解决方案来解决有限领域协议泄漏的问题。
- Diff: 摘要 随着对“有限域”文档描述的协议仅用于“有限域”的趋势，这些文档往往没有清晰定义边界是如何实施和强制的，或者需要网络运营商在所有边界节点上为这些有限域添加过滤器来保护全球互联网免受这些协议的影响，并防止其反向影响。这导致了对“泄露”概念的关注。 本文档讨论了“失败开放”与“失败关闭”协议的概念，以及如何使用层2协议标识机制设计安全可靠的限域协议。为了说明这一点，本文引用了[RFC8799]中的相关章节。 此外，它还探讨了使用层3类型的限域协议时，“失败闭合”比“失败开启”更安全的原因，以及在这种情况下采用扩展的层2协议标识符（如Extended EtherType）的好处。 总结：相比旧版英文标准文稿，新版本增加了更多的细节和例子以支持观点，同时在介绍层次化解决方案时也进行了深入分析。此外，新的文档引入了一个新的标题“Fail-open versus Fail-closed”，进一步强调了这两种不同策略的不同优势和风险。
RTG
bess
- Title: SAVI in an EVPN network
- Authors: Eric Levy-Abegnoli(elevyabe@gmail.com), Pascal Thubert(pascal.thubert@gmail.com), Ratko Kovacina(rkovacin@cisco.com)
- Summary: 是一篇关于源地址验证改善(SAVI)技术在Ethernet虚拟私有网络(EVPN)中的应用的研究文档。主要讨论了如何将SAVI和EVPN结合起来，以实现源地址验证，以及如何处理不同类型的地址（DHCP分配地址、SLAAC和其他IPv6地址）。 文档首先概述了SAVI的基本原理，包括三个步骤：识别合法源地址，绑定合法地址到主机，并确保源地址与绑定地址匹配。然后，它介绍了两种部署模型，一种是将SAVI置于客户边缘路由器(CE)和提供商边缘路由器(PE)/隧道端点(VTEP)之间，另一种是在PE/VTEP内部集成SAVI功能。 文档接着讨论了SAVI对DHCP分配地址的支持以及如何使用DHCP Snooping来避免源地址被侵扰。同时，它也分析了SLAAC和IPv6地址的情况，指出SAVI可以验证SLAAC地址，但需要注意源地址可能未被验证的情况。 文档还提出了几个安全考虑，例如如何防止SAVI和EVPN之间的冲突。最后，它指出了SAVI在Intra-domain和Inter-domain网络中的作用，以及如何与其他技术结合提高安全级别。 总的来说，这篇文档提供了SAVI在EVPN网络中的应用实例，强调了SAVI和EVPN相结合的重要性，以及它们如何协同工作以提供源地址验证。
- Diff: 以上是新的英文标准文稿的一个总结： 1. 文档使用了关键字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"来表示规定。 2. 状态语言描述了这些规定是否必须遵守、被推荐遵守或可选遵循。 3. 文档中定义了Savni的概念，并详细介绍了它的工作原理和行为模式。它提供了一种源地址验证机制，用于验证IPv6网络中的合法源地址。 4. 文档讨论了Savni在IPv6邻居发现协议(ND)、DHCPv6、DHCPv4服务器以及BGP MPLS-Ethernet VPN等场景下的部署方法。 5. 对于一些特定类型的地址（如DHCPv6/DHCPv4分配的地址），文档还提到了与EVPN网络交互的方式。 6. 比较起来，旧版本文档更加简短，没有对具体的实现细节进行深入说明，而是更多地集中在概要性的概念介绍上。而新版本则提供了更详细的交互机制和部署模型分析。
pce
- Title: Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
- Authors: Mike Koldychev(mkoldych@proton.me), Siva Sivabalan(msiva282@gmail.com), Samuel Sidor(ssidor@cisco.com), Colby Barth(cbarth@juniper.net), Shuping Peng(pengshuping@huawei.com), Hooman Bidgoli(hooman.bidgoli@nokia.com)
- Summary: 本文主要介绍了PCEP协议中的路径计算元素通信协议（PCEP）扩展，用于在SR（Segment Routing）政策中信号候选路径。这些扩展使得可以使用PCEP来设置和管理SR网络中的流量工程（Traffic Engineering）路径，以及将流量引导到特定的SR政策上。 该文档更新了《5.8.2节，允许在使用路径设置类型1（Segment Routing）或3（SRv6）的LSP建立过程中省略前期的PCRequest和PCReply消息，这样可以减少PCEP消息的交换，简化实现。 此外，还定义了一些新的TLV（Type-Length-Value），例如SRPolicyCapability TLV、SRPolicyCandidatePathProtocolOrigin TLV等，这些TLV可以在PCEP对象中携带，用于标识不同类型的SR政策。 总的来说，本文为SR政策提供了更灵活的通信机制，并简化了其实施过程，有助于提升网络效率。
- Diff: 是关于在PCEP协议上支持段路由政策候选路径的新版本英文标准文档。主要内容包括： 1. 引言：定义了PCEP协议扩展的概念和作用。 2. 命名空间：定义了SR Policy标识符、SR Policy候选路径标识符和SR Policy候选路径属性等概念。 3. SR Policy协会：详细描述了如何通过SR Policy候选路径建立关联以及这些关联与SR Policy的关系。 4. 其他机制：阐述了在不使用PCEP协议的情况下，通过建立SR Policy候选路径关联来简化实施的方法。 5. 新能力：说明了SR Policy能力TLV可以用于学习PCEP支持的SR Policy特性。 6. 确认状态：讨论了更新到RFC 8231文件以允许无状态创建SR Label Switched Path（LSP）的功能。 7. 实施状态：总结了Cisco和Juniper两个厂商对这一改进的支持情况。 8. 安全考虑：讨论了新的能力和安全性的影响。 9. 参考文献：列出了所有参考文献，包括规范性引用部分和信息参考部分。 总的来说，新版本文档的主要区别在于引入了新的PCEP协议能力TLV、支持了SR Policy候选路径的无状态操作、增加了其他工作机制，使得整个文档结构更加清晰和实用。
SEC
scim
- Title: System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements
- Authors: Paulo Jorge Correia(paucorre@cisco.com), Pamela Dingle(pamela.dingle@microsoft.com)
- Summary: 本文主要介绍了SCIM系统的核心概念、架构和应用场景。SCIM是一个标准的身份管理协议，旨在简化跨域身份管理和资源管理。它通过定义数据模型、操作角色和触发机制，使组织能够有效地管理资源对象和其属性。文中详细描述了SCIM的组件结构、工作流程以及应用案例，为开发者提供了对SCIM框架的理解和使用指南。
uta
- Title: TLS/DTLS 1.3 Profiles for the Internet of Things
- Authors: Hannes Tschofenig(Hannes.Tschofenig@gmx.net), Thomas Fossati(thomas.fossati@linaro.org), Michael Richardson(mcr+ietf@sandelman.ca)
- Summary: 本文为一篇关于增强物联网设备通信安全性的规范性文档。它提出了一套新的TLS/DTLS 1.3协议，旨在满足资源受限的物联网设备的需求，同时保持关键的安全性和完整性保障。 核心优势在于：简化握手流程，减少加密算法复杂度；采用预共享密钥（PSK）来替代传统证书管理；支持零延迟数据传输等。 文稿还讨论了在物联网环境中可能遇到的问题，并提供了相应的解决方案和建议。例如，对于使用零延迟数据的情况，提出了特定的安全规定和操作策略。此外，还指出了与现有协议兼容性的问题，以及如何通过适当调整配置来解决这些问题。 总结来说，本文提供了一个全面的框架，指导开发者如何实现更高效、更安全的物联网设备通信。这对于构建可信赖、可靠且高性能的物联网网络至关重要。
- Diff: 这篇新的英文标准文档更新了之前的TLS/DTLS 1.3规范，以适应物联网设备资源受限的特点。主要的变化有： 1. 原有的re-negotiation和rekeying机制不再提供前向保密性，而是引入了post-handshake认证消息来代替。 2. 没有支持静态RSA和Diffie-Hellman密钥交换方式，所有的公钥基于关键交换都提供了前向保密性。 3. 允许使用预共享密钥（PSK）进行安全通信，并且PSK可以和先前版本的TLS/DTLS互操作。 4. 提供了证书和数字签名，支持ECDSA签名算法，并建议使用e-cdh、secp256r1和X25519。 5. 引入了ServerNameIndication扩展，用于保护DNS解析。 6. 提出了Keep-Alive机制，减少了网络拥塞的风险。 7. 讨论了ACKs的概念，提出了合理的ACK策略。 8. 对于连接建立阶段，使用压缩技术减少数据量。 9. 支持各种加密协议，如TLS、DTLS、SSL等。 10. 提供了随机数生成器，防止内存溢出。 11. 重新定义了服务器名称指示扩展，限制了最大有效时间。 12. 强调了安全性考虑，例如零时延数据。 13. 强化了对量子计算的考虑，提出了开放问题。 14. 在证书配置方面进行了更新，为不同的实体类型提供了指导。 总的来说，新版规范更加注重满足物联网设备的特殊需求，优化了协议设计，使设备能够高效地运行在有限的硬件资源下。
WIT
aipref
- Title: Vocabulary for Expressing Content Preferences for AI Training
- Authors: Thom Vaughan(thom@commoncrawl.org)
- Summary: 这篇文稿提出了一种表达对人工智能训练内容偏好（AIPREF）的词汇，旨在帮助出版商管理其内容在人工智能训练中的使用。文稿讨论了AIPREF的各个元素，包括允许训练、目的、时间限制、内容特定粒度、内容类型、保留期限和偏好的持久性等，并强调了这些元素的优先级顺序。此外，还介绍了如何在HTTP头部、robots排除协议、元标记和嵌入式元数据等方面实现AIPREF的使用。文稿总结指出，虽然AIPREF不涉及网络安全性或客户端认证机制，但应由AI模型开发者负责，而由内容发布者自行决定如何处理和实施AIPREF偏好。
Unknown
Unknown
- Title: IRTF Code of Conduct
- Authors: Colin Perkins(csp@csperkins.org)
- Summary: 本文是关于互联网研究任务组织(IRTF)的代码规范，旨在为参与者提供一个安全和公平的环境。它强调了尊重、诚实、透明和公正的原则，并规定了在会议、讨论、研讨会、工作坊和其他活动中应该遵守的行为准则。此外，还对科研伦理、包容性语言、参与度和访问性等问题进行了详细阐述。最后，提到了一些相关的参考文献。
- Diff: 该标准文稿的主要区别在于： 1. 更加注重开放和包容性：新的代码规范强调了研究应该在一种鼓励多样性的环境中进行，并且应该有广泛的参与。 2. 强调诚信、公正和尊重：参与者必须对他人尊重并以公平的方式行事。 3. 研究伦理更加详细地考虑了涉及人类的研究。 4. 使用语言更友好，尽量使用广泛可理解的语言，避免过于专业的术语。 5. 对于网络安全性进行了更多的讨论。 6. 加入了一些关于网络安全方面的建议。 总的来说，新版文档更加关注研究过程中的道德和安全问题，同时也更加强调了研究的开放性和包容性。