今日共有7篇文稿更新,涉及4个area里的4个WG

INT

6man

1. draft-templin-6man-parcels2-19

  • Title: IPv6 Parcels and Advanced Jumbos (AJs)
  • Authors: Fred Templin(fltemplin@acm.org)
  • Summary: 这篇文稿讨论了IPv6协议中的一个新概念——“IPv6包裹”和“高级跳跃(Jumbo)”服务,以及这些技术对网络性能、效率和完整性带来的好处。主要观点如下: 1. IPv6包裹允许在单个包中包含多个段,从而提供并行处理数据的优点。 2. 这些包裹提供了改进的性能、效率和完整性的关键元素,并鼓励更大的最大传输单元(MTU),以支持延迟容忍网络(DTN)的大小要求。 3. 高级跳跃(Jumbo)服务为在所有大小的单个段上可靠地发送和接收段提供了重要的服务。 4. 这些技术促进了未来创新在应用、运输协议、操作系统、网络设备和数据链路层方面的发展。
  • Diff: 本文是关于IPv6协议的一个最新版本的英文标准文档,提供了新的包类型IPv6 Parcel和Advanced Jumbos(AJs)的概念,并阐述了它们在改善性能、效率和完整性方面的作用。 与旧版相比,该文档的主要区别在于: 1. IPv6 Parcel允许单个IPv6包包含多个运输层协议数据单元,而不是作为一个单独的包发送。 2. AJs提供了一个比基本jumbogram更强大的服务,当传输所有大小范围内的单个段时非常有用。 3. 考虑到了延迟容忍网络(DTN)的特性,以支持空中/陆地/海洋/空间移动应用等场景。 4. 这些服务将促进未来创新,包括运输协议、操作系统、网络设备以及数据链路的改进,以提高互联网互连性能。

RTG

tvr

1. draft-ietf-tvr-alto-exposure-00

  • Title: Using ALTO for exposing Time-Variant Routing information
  • Authors: Luis M. Contreras(luismiguel.contrerasmurillo@telefonica.com)
  • Summary: 本文讨论了时间变通路由(Time-Variant Routing,简称TVR)的概念,并提出了利用网络拓扑暴露时间变通信息的方法。主要介绍了ALTO作为时间变通信息的曝光机制,以及它如何通过暴露未来的时间变通事件来预测并估计这些变化对网络的影响。文稿还讨论了如何使用ALTO作为时间变通信息的外在解决方案,并评估了其与时间变通需求的一致性。 总结:本文讨论了时间变通路由的概念和特点,提出了ALTO作为时间变通信息的曝光机制,并探讨了它的应用场景和适用条件。文稿还分析了ALTO与其他时间变通解决方案之间的关系,提出了实施建议,但同时也指出了需要解决的一些问题,如数据模型的细化、广告传播的安全性和用户隐私保护等。总的来说,文稿为实现时间和变通路由提供了技术方案,但也存在一些挑战需要克服。

SEC

oauth

1. draft-ietf-oauth-browser-based-apps-21

  • Title: OAuth 2.0 for Browser-Based Applications
  • Authors: Aaron Parecki(aaron@parecki.com), David Waite(david@alkaline-solutions.com), Philippe De Ryck(philippe@pragmaticwebsecurity.com)
  • Summary: 本文讨论了如何在浏览器上安全地使用OAuth 2.0。它分析了恶意JavaScript对这些应用的影响,以及不同的架构模式如何应对这些威胁。 主要观点如下: 1. 恶意JavaScript可以执行各种攻击,如跨站点脚本(XSS)、远程代码注入等。 2. 使用托管的后端来处理OAuth责任会提供更强的安全性,但可能需要更复杂的部署和操作。 3. 如果一个应用程序具有托管的后端,并且能够与资源服务器进行代理请求,那么就无法防止一些攻击,如单个执行令牌窃取、持久令牌窃取和新令牌获取。 4. 基于后端的应用程序比浏览器应用程序更容易受到攻击,因为它们暴露了更多的令牌给恶意代码。 文稿建议开发者选择合适的架构模式,以确保他们的应用程序是安全的。
  • Diff: 这个新的英语标准文档主要关注的是浏览器基础应用在使用OAuth进行访问权限控制时面临的威胁、攻击后果以及最佳实践。 该文档首先概述了当前浏览器基础应用面临的威胁和攻击后果,并对如何安全地实施这些应用进行了分析。然后详细讨论了三种主要的应用架构模式:前端后端(BFF)、基于后端的前端(BFF)和直接客户端模式。每种模式都有其特定的安全性和复杂性考虑。 最后,文档讨论了用于浏览器存储的令牌的几种方式,包括cookies、服务工作线程、Web工件和内存中的临时存储等。并分析了这些技术的安全属性。 与旧版相比,本新版增加了对恶意JavaScript行为的更多讨论,强调了恶意JavaScript能够获取并窃取用户凭据,执行各种操作的能力,比如劫持网页、修改页面内容或发送请求到后端系统。同时,也指出了恶意JavaScript代码无法隔离在应用程序之外,且可以绕过常规防御措施。 此外,新版还讨论了OAuth授权码流中使用的PKCE机制防止授权码注入攻击,以及更新了对于第一级公共域应用的处理方式。由于文档没有直接提到旧版的内容,因此我们可以认为它们的主要区别在于增加了关于恶意JavaScript行为的讨论,强化了安全策略,以及更详细地介绍了不同架构模式的特点。

IRTF

cfrg

1. draft-mattsson-cfrg-aes-gcm-sst-14

  • Title: Galois Counter Mode with Strong Secure Tags (GCM-SST)
  • Authors: Matt Campagna(campagna@amazon.com), Alexander Maximov(alexander.maximov@ericsson.com), John Preuß Mattsson(john.mattsson@gmail.com)
  • Summary: 本文主要讨论了Galois Counter Mode with Strong Secure Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD)算法。GCM-SST是一种基于Galois Counter Mode(GCM)的安全标签协议,它可以在不依赖于特定密钥长度的情况下提供接近理想的认证强度。 GCM-SST引入了一个新的子密钥Q,以及H和Q,使得在每个非空密钥下生成的密钥对的数量限制为2^32次,以避免多次成功伪造的可能性。同时,通过使用POLYVAL函数,可以减少软件实现上的计算复杂度,使其在小端机架构上更快。此外,GCM-SST还允许更短的验证消息,如96位或112位,但需要更多的计算量来确保其完整性。 GCM-SST设计用于单向安全协议,如TLS、QUIC、SRTP和PDCP,其中其认证标签的行为类似于理想MAC,包括重置攻击的抵抗性。与Poly1305和GCM相比,GCM-SST可以提供更好的完整性,并且具有更低的开销。它的性能类似于GCM,但额外的AES调用被补偿了。
  • Diff: 上述新版本的英文标准文稿定义了Galois Counter Mode with Strong Secure Tags(GCM-SST)安全认证加密协议(AEAD),它可以与任何流密码生成器结合使用,而不是仅限于128位块密码。它有以下特点: 1. 使用一个额外的子密钥Q,用于每对非空密钥组合。 2. 每个密钥限制在特定的标签长度上。 3. 使用AES-GCM-SIV中的POLYVAL函数替换GHASH来更高效地实现软件实现。 4. 针对各种应用的十二个安全认证协议实例。 总体而言,GCM-SST改进了性能和安全性,特别是对于小标签的情况,其安全性得到了显著提高。然而,它的安全性可能没有达到理想状态,因此仍然需要更多的研究和实验以确定最佳参数。

Unknown

Unknown

1. draft-chen-ati-adaptive-ipv4-address-space-17

  • Title: Adaptive IPv4 Address Space
  • Authors: Abraham Chen(aychen@avinta.com), Ramamurthy R. Ati(rama_ati@outlook.com), Abhay Karandikar(director@iitk.ac.in), David Crowe(david.crowe@cnp-wireless.com)
  • Summary: 本文讨论了在现有IPv4地址不足的情况下,通过一种新的扩展机制——EzIP(Easy IPv4),来解决IPv4地址问题。EzIP是一种新型的IPv4地址扩展技术,它利用现有的IPv4协议中的Option机制来传输扩展信息,使得IPv4地址能够扩展到更多的子网和设备上。EzIP采用了类似于传统的交换机中使用“分段”技术的方式来处理这种扩展需求,将一个公共IPv4地址分割成多个可扩展的子地址,从而实现更大的地址池。 EzIP的优点在于其可以在不影响当前互联网系统架构的前提下,提供更广泛的互联服务,同时支持直接和私有网络之间的连接,并且具有较高的安全性。此外,EzIP可以作为软件或硬件增强来部署,也可以安装在边缘路由器或私有网络路由网关之间,使它可以无缝引入到现有的网络环境中。 总体来说,EzIP方案提供了满足IPv4地址需求的有效解决方案,可以有效缓解IPv4地址短缺的问题,为未来IPv6的发展预留空间。
  • Diff: 该文档提出了一个名为EzIP的方案,通过使用IPv4协议中的现有选项机制来解决互联网地址短缺问题。EzIP利用了一个保留的网络地址块240/4,所有现有的核心路由器、边缘路由器和私有网络路由(住宅)网关(RG)以及终端主机如PC和物联网设备都不得使用。在Option机制下,将保留的IPv4公有地址池扩展到多倍数量的子地址,并将其分配给每个公共地址以扩大可用性。这样做的目的是缓解IPv4地址短缺的问题,以便满足预计在未来几年内爆发式增长的物联网(IoT)需求。 与旧版本的英文标准文稿相比,新的文档在内容上有以下几点重要区别: 1. 新文档详细介绍了EzIP的编号计划、与NAT之间的比较分析、系统架构、IP头中的选项字节等技术细节。 2. 提出了几种方式来扩大公网IPv4地址池,同时增强了网络操作的功能。 3. 在实施步骤和部署车辆方面提供了实验性的证据,显示了EzIP在实现中的可能性。 4. 讨论了可能影响EzIP实施的各种因素,包括网络过渡考虑、增强特定商业RG的方法等等。 5. 分析了EzIP如何简化IPv6的成熟过程,使其能够提供所需的服务水平等级以支持长期通用服务。 6. 将EzIP部署分为两个阶段:第一阶段扩展CG-NAT功能以允许使用240/4网络块;第二阶段全球覆盖范围使用选项字节机制在IP头部。 总的来说,新版文档提供了更详细的EzIP设计信息和技术细节,使读者可以更好地理解其工作原理和潜在优势。


2. draft-fregly-research-agenda-for-pqc-dnssec-02

  • Title: Research Agenda for a Post-Quantum DNSSEC
  • Authors: Andrew Fregly(afregly@verisign.com), Roland van Rijswijk-Deij(r.m.vanrijswijk@utwente.nl), Moritz Müller(moritz.muller@sidn.nl), Peter Thomassen(peter@desec.io), Caspar Schutijser(caspar.schutijser@sidn.nl), Taejoong Chung(tijay@vt.edu)
  • Summary: 本文提出了一项研究议程,旨在支持对量子数字签名算法(QPSK)影响的多方面研究。本文讨论了目前选定的NIST QPSK数字签名算法的特点,这些特点将给DNSSEC带来挑战。此外,文稿还提出了几种可能应对这些问题的方法。 首先,较小的方法试图找到降低QPSK签名大小的方法。然而,由于NIST未来可能选择一个具有小签名和合理处理需求的QPSK签名算法,这种方法需要长期评估和实施前广泛采用。另一种方法是定义减少大小影响的其他方法,例如在不同类型的设备上进行算法协商。此外,文稿建议使用不同的传输方式来分发密钥和签名,如推式协议、会话层协议等。 研究活动包括但不限于: 1. 解析设备类型和特征:设备种类、角色(代理、解析器、权威名称服务器)、算法、环境约束等。 2. 分类和识别解码软件:根据更新可能性和速度的影响因素。 3. 区域内的流量分析:解析器到解析器、解析器到权威名称服务器之间的数据流;查询响应时间。 4. 解析域名级别(根域、顶级域、下一级别)的数据流分析:解析域中的RRs数量、频率、更新次数等。 5. 区域内DNSSEC相关RR的数量分析。 6. 取决于转换策略的数据发送比例分析。 目标是为未来点提供关于如何适应QPSK算法的DNSSEC生态系统的信息。
  • Diff: 这个新的文档补充了对过去标准文档中的概念的扩展,定义了一个研究议程以支持针对未来量子数字签名算法(PQC)生态系统的多边研究和选择协议变更、基础设施变更相关变化的研究。它提出了几种可能的新方法来减少PQC数字签名算法在DNSSEC中的影响,包括更小的签名大小、使用不同的方式最小化现有算法的影响等。该议程还提出了一些问题,例如如何分析和理解这些影响,并为后续工作提供了指导。 总的来说,与旧版相比,这一新版的主要区别在于增加了对多边合作研究的需求,将讨论从仅限于特定领域扩大到整个生态系统;提出了多种可能的方法来处理由PQC算法带来的影响;并提出了具体的实施步骤和标准制定过程中的考虑因素。


3. draft-deepakarumugham-pcrp-spec-00

  • Title: PCRP Webhook Specification
  • Authors: Deepak Arumugham(deepak12f@gmail.com)
  • Summary: 本文提出了一种新的Webhook事件标准——PCRP(Ping、Challenge、Resolve、Product),用于标准化Webhook事件流程。它定义了四个关键阶段:ping,挑战,解决和产品,并提供了详细的结构描述。每个阶段都有明确的目的,确保了通信的一致性和可靠性,简化了开发者的任务,解决了当前实施中存在的问题,如不一致性、缺乏定义等。此外,本文还讨论了其安全性考虑和IANA注册事项。 总之,本文提出了一个全面且有组织的Webhook事件标准,旨在提供一种统一的API接口,使开发者能够更轻松地集成到他们的系统中,并有效防止恶意行为。