【每日文稿】2024-12-17
今日共有7篇文稿更新，涉及4个area里的6个WG
ART
satp
- Title: Secure Asset Transfer (SAT) Interoperability Architecture
- Authors: Thomas Hardjono(hardjono@mit.edu), Martin Hargreaves(martin.hargreaves@quant.network), Ned Smith(ned.smith@intel.com), Venkatraman Ramakrishna(vramakr2@in.ibm.com)
- Summary: 本文提出了一种基于网关的资产转移互操作性架构，该架构允许两个网络或系统之间的数字资产进行直接转移。文稿讨论了设计原则、假设和原理，提出了资产转移协议的概念，并定义了相关术语。 在设计阶段，文档提到了几个关键概念：透明的网络资源、外部化的价值、以及各网络内部资源的不可见性等。在实施阶段，文档指出了不同的资产转移场景，包括数据转移和资产交换（换）。此外，文档还强调了门限确认（锁）、最终确认（签）等关键步骤的重要性。 总的来说，本文为构建一个支持资产安全、可靠、高效的资产转移机制提供了理论基础。它强调了对网络结构、通信标准和消息格式的理解和应用，以实现资产网络之间的高效协作。
- Diff: 新版本的英文标准文稿讨论了基于网关的资产转移互操作性架构，旨在定义支持资产转移协议所需的网络门禁服务端口（Gateway）的功能和行为准则。 相较于旧版文档，主要有以下区别： 1. 网络资源不透明化：在新的文档中，强调了网络内部资源的透明化原则，允许外部实体访问这些资源需要经过特定授权。 2. 价值外置化：设计考虑了资产转移协议的效率、安全性及可靠性独立于经济价值变化的原则。 3. 保护传输状态：确保资产状态在转接过程中不受改变，从而实现不可见性和持久性。 4. 安全通信：明确强调了安全通道建立的重要性，以及后续恢复阶段的安全协议选择。 5. 完整性与活耐性：保证资产转移协议达成ACID属性，即非阻塞状态，在必要时能够终止并完成转移流程。 总的来说，新版本的架构更侧重于保障资产在转移过程中的完整性、可验证性和安全性，同时也在技术细节上进行了更深入的研究和改进。
INT
dhc
- Title: DHCPv4 over DHCPv6 with Relay Agent Support
- Authors: Claudio Porfiri(claudio.porfiri@ericsson.com), Suresh Krishnan(suresh.krishnan@gmail.com), Jari Arkko(jari.arkko@ericsson.com), Mirja Kühlewind(ietf@kuehlewind.net)
- Summary: (DHCp)4o6是基于DHCp4和DHCp6的运输机制。这个文档提出了一种可以在不改变客户端的情况下部署DHCp4o6的方法。这种方法允许在代理服务器上实现DHCp4o6的功能，而不是让客户端实现这些功能。 该文稿总结了以下关键点： 1. DHCPv4 over DHCPv6 (4o6)是一种承载DHCp4消息的运输机制，用于IPv4网络与IPv6网络之间的地址和DHCPv4特定配置参数的动态配置。 2. DHCP Relay Agent（或RA）是一种概念，在所有协议中，包括BOOTP、DHCPv4和DHCPv6，但其细节在不同协议中有所不同。 3. Lightweight DHCPv6 Relay Agent（或LDRA）是一个对原DHCp6 Relay Agent机制的扩展，支持层2设备执行代理角色[RFC6221]。 4. DHCPv4 over DHCPv6 Relay Agent（或4o6RA）是4o6 Relay Agent的一个部分，它实现了DHCp4o6的所有功能。 5. 4o6RA将DHCPv4请求封装为DHCPv4响应，并通过DHCPv6 Relay Agent转发给原始的IPv4客户端。4o6RA使用DHCPv6 Relay Agent的信息来识别接口，从而可以保留拓扑信息。 6. 在使用4o6RA时，需要确保所有的DHCPv4广播和单播消息都路由到4o6RA，以防止4o6RA的引入破坏拓扑路径。 总结：本文详细介绍了如何在不更改客户端的情况下部署DHCp4o6，以及如何通过DHCp Relay Agent来处理DHCp4o6的传输过程。同时，还讨论了可能的安全考虑，如4o6RA是否影响到原有的拓扑信息等。最后，提到了相关的IANA注册事项，但未列出具体的信息。总的来说，本文提供了在现有DHCp标准下部署DHCp4o6的一种可行方案。
RTG
idr
- Title: Interconnecting domains with IBGP
- Authors: Krzysztof Grzegorz Szarkowicz(kszarkowicz@gmail.com), Moshiko Nayman(mnayman@juniper.net), Israel Means(israel.means@att.com)
- Summary: 这篇文档主要提出了一个可以使用内部边界网关协议(Internal Border Gateway Protocol, IBGP)替代外部边界网关协议(Border Gateway Protocol, EBGP)来构建三层虚拟私有网络(Layer 3 Virtual Private Network, L3VPN)架构的概念。这种新的架构允许不同自治系统(Autonomous System, AS)之间的L3VPN架构，如Option 10A、Option 10B和Option 10C，被应用于多个不同的自治系统之间，而无需改变AS号。 具体来说，如果将同一个AS中的ASBR（Autonomous System Boundary Router）配置为路由反射器(Router Reflector)，那么它就可以用来接收并转发来自其他AS的L3VPN服务标签，同时修改这些标签以避免生成环路。此外，该架构还可以通过使用多跳内部边界网关协议(Multi-hop Internal Border Gateway Protocol, MH-IBGP)来进一步简化设计，同时保持路由信息的有效性。 总的来说，本文提出了一种可以使用IBGP代替EBGP构建跨多个AS的L3VPN架构的方法，并讨论了相关的安全性考虑和可能的IANA注册问题。该文稿旨在提供一种更灵活且易于实现的跨域L3VPN解决方案。
- Diff: 新的版本放松了BGP/MPLS IP虚拟私有网络(VPNs)和BGP路由反射(BGP Route Reflection):一种全网内部BGP(IBGP)允许构建跨域L3VPN(三层虚拟私有网络)架构的建议。 主要内容包括： 1. 相比于旧版，新版本引入了三种跨域L3VPN选项：Option 10A、Option 10B 和 Option 10C。 2. 从原有的Option 10A、Option 10B和Option 10C架构，将BGP Peerings改为IBGP(Peerings)来代替EBGP(Peerings)，从而使得跨域L3VPN架构得以实现。 3. 对于跨域L3VPN Option 10A和Option 10C，新增了DBR(Routing Edge Device, 地址转换器)的功能，并且DBR在收到跨域L3VPN的NLRIs时需要改变NEXT_HOP属性，以避免出现环路问题。 4. 新版本还调整了Option 10B和Option 10C架构，使之更加适应多点接入的场景，如小规模区域或几个PE节点组成的小规模区域等。 总的来说，新版本的标准化文档提供了更灵活、可扩展的跨域L3VPN架构，为运营商提供了一种全新的跨域互联方案，同时保留了跨域L3VPN架构的优点，例如节省流量、提高安全性等。
lsr
- Title: Extensions to OSPF for Advertising Prefix Administrative Tags
- Authors: Acee Lindem(acee.ietf@gmail.com), Peter Psenak(ppsenak@cisco.com), Yingzhen Qu(yingzhen.ietf@gmail.com)
- Summary: 本文提出了一种新的管理标签（administrative tag）子类型，用于在链路状态路由协议(OSPF)中标识和分配路径信息。这些标签可以用于控制路由转发、选择优先级等应用，提供更多的可选功能。该标准定义了如何使用OSPF v2和v3版本中的特殊子类型来指定多个不同类型的标签，并规定了这些子类型的应用范围。此外，它还讨论了管理和操作这些子类型的可能性以及其可能的安全性和部署限制。本文为网络管理人员提供了配置和管理链路状态路由信息的机制，允许他们根据需要自定义OSPF的管理员标签。
- Diff: 该文档是关于扩展到OSPf以广告前缀管理标签（administrative tags）的RFC文档的一部分。主要内容有： 1. 为OSPFv2和OSPFv3定义了一个新的前缀管理标签子TLV。 2. 提供了与特定类型（如外部区域、不那么stubby区域等）的前缀相关的前缀管理标签。 3. 通过配置接口、区域范围等方式可以实现对不同类型的前缀进行管理。 4. 在BGP-LS协议中引入了前缀管理标签，用于路由重分布、优选选择以及一些其他应用。 总的来说，该文档在原有基础上进行了扩展和丰富，增加了对更广泛前缀管理场景的支持，并进一步明确了前缀管理标签的应用领域和使用方式。
spring
- Title: SRv6 for Inter-Layer Network Programming
- Authors: Liuyan Han(hanliuyan@chinamobile.com), Jie Dong(jie.dong@huawei.com), Minxue Wang(wangminxue@chinamobile.com), Ran Chen(chen.ran@zte.com.cn), Zongpeng Du(duzongpeng@foxmail.com)
- Summary: 本文主要讨论了网络编程的概念，特别是Segment Routing over IPv6 (SRv6)，以及其在层间网络编程中的应用。文稿提出了一种新的SRv6端点行为（End.IL），它能够用于控制IP和光缆之间的路径，并提供服务级别的流量工程。这种行为允许使用SRv6 SID列表来构建不同SLA要求的服务之间的端到端路径。 总结而言，本文展示了如何将SRv6与传统的层内和层间网络编程技术相结合，以实现网络规划、服务部署和SLA保证。这种方法不仅提高了效率，而且简化了规划和部署过程，为运营商提供了灵活高效地集成IP网络和光缆的能力。
- Diff: 以上新版本的英文标准文稿定义了两种新的SRv6行为：END.XU和END.BXC。这两种行为都可以用于引导IP网络中的节点将数据包发送到底层连接或通道上。其中END.XU端点行为允许通过底层链接或通道来发送数据包，而END.BXC端点行为则可以将数据包转发到特定的底层隧道（如L1链路）上。这两种行为都为实现跨层网络编程提供了新的可能，并且在不同场景下都有适用性。 相比于旧版本，新版本的主要区别在于： 1. 新增了END.XU和END.BXC两种新的SRv6端点行为。 2. 提供了一种新的网络操作模型，即通过指定特定类型的业务需求来选择使用哪种端点行为。 3. 定义了如何使用不同的信息源（如IGP、BGP、PCEP等）来发布和管理这些端点行为。 总的来说，新版本增加了更多的灵活性，使得网络管理员可以根据具体的需求选择合适的端点行为，从而更好地支持跨层网络编程。
IRTF
cfrg
- Title: Galois Counter Mode with Secure Short Tags (GCM-SST)
- Authors: Matt Campagna(campagna@amazon.com), Alexander Maximov(alexander.maximov@ericsson.com), John Preuß Mattsson(john.mattsson@gmail.com)
- Summary: 是针对加密算法的一种新定义。它使用了多项式移位函数（POLYVAL）来提高软件实现效率，并且在每个操作上都使用了一个额外的子密钥Q，从而提供了近似理想的安全性。这种新的模式可以用于任何类型的加密算法，而不仅仅是128位块密码。与GCM相比，它的安全性得到了增强，尤其是在短标签的情况下。由于它减少了多成功伪造的可能性，因此被广泛应用于音频数据传输等场景。
- Diff: 本文提供了新的加密算法Galois Counter Mode with Secure Short Tags（GCM-SST），它是一种与Advanced Encryption Standard（AES）和Rijndael同构的AEAD协议。相比于GCM，GCM-SST在短标签的情况下可以提供更理想的伪造概率，并且其安全性水平也更高。 具体来说： 1. 引入了一个额外的子密钥Q来增强安全性和有效性。 2. 对于每个nonce进行单独的H和Q密钥生成。 3. 使用AES-GCM-SIV中的POLYVAL函数替代GHASH，以提高软件实现效率。 4. 支持多种长度的输入输出参数。 此外，GCM-SST还注册了使用AES和Rijndael的多个实例，这些实例都表现出良好的安全特性。总之，GCM-SST为未播加密协议添加了一种新的安全框架，具有更好的性能、更少的开销和更短的认证标签。
Unknown
Unknown
- Title: Unsigned X.509 Certificates
- Authors: David Benjamin(davidben@google.com)
- Summary: 本文档定义了一个X.509证书结构，该结构仅包含主体信息，而无需验证其签名。这是在某些情况下使用的一种解决方案，例如某些应用需要存储主体信息而不是证书中的签名人信息。然而，这种类型的证书不提供任何安全性价值，并且不会被接收者检查。此外，如果主体是一个实体而非CA，则计算X.509签名可能会引起跨协议攻击。 尽管存在一些缺点，如增加证书大小、可能引发单个密钥用于多个用途的风险以及对未指定使用场景的非X.509密钥的无效签名算法的依赖，但是本文档提供了构造此类证书的方法和处理方法，以确保它们的安全性并避免潜在的风险。本文档还定义了如何处理这些无签名证书，以及提出了建议和标准做法来确保安全性和一致性。
- Diff: 该文档定义了一个用于在某些情况下不验证X.509证书签名的预留X.509签名算法。旧版文档没有定义此OID，并且没有提供关于构造、消费和安全考虑方面的详细说明。新版文档提供了关于构造、消费和安全考虑的详细说明，并指出了使用这种特殊格式的潜在风险，如自签名可能会被用来进行跨协议攻击等。此外，它还定义了ID-Unsigned OID，表示可以作为未使用的X.509凭证的标识符，从而为需要特定信息但不需要验证签名的应用程序提供了一种解决方案。 总之，新版文档对X.509认证过程进行了更详细的规范，增加了安全性考虑，同时提供了新的功能。