RFC 9118 on Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates
A new Request for Comments is now available in online RFC libraries. RFC 9118 Title: Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates Author: R. Housley Status: Standards Track Stream: IETF Date: August 2021 Mailbox:hous...@vigilsec.com Pages: 12 Updates:RFC 8226 I-D Tag:draft-ietf-stir-enhance-rfc8226-05.txt URL:https://www.rfc-editor.org/info/rfc9118 DOI:10.17487/RFC9118 RFC 8226 specifies the use of certificates for Secure Telephone Identity Credentials; these certificates are often called "Secure Telephone Identity Revisited (STIR) Certificates". RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document updates RFC 8226; it provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT. This document is a product of the Secure Telephone Identity Revisited Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9117 on Revised Validation Procedure for BGP Flow Specifications
A new Request for Comments is now available in online RFC libraries. RFC 9117 Title: Revised Validation Procedure for BGP Flow Specifications Author: J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. Mohapatra Status: Standards Track Stream: IETF Date: August 2021 Mailbox:ju1...@att.com, jalca...@cisco.com, c...@cisco.com, djsm...@cisco.com, mprad...@yahoo.com Pages: 12 Updates:RFC 8955 I-D Tag:draft-ietf-idr-bgp-flowspec-oid-15.txt URL:https://www.rfc-editor.org/info/rfc9117 DOI:10.17487/RFC9117 This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications as specified in RFC 8955 requires that the originator of the Flow Specification match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an Internal Border Gateway Protocol (iBGP) received route, the originator is typically a border router within the same autonomous system (AS). The objective is to allow only BGP speakers within the data forwarding path to originate BGP Flow Specifications. Sometimes it is desirable to originate the BGP Flow Specification from any place within the autonomous system itself, for example, from a centralized BGP route controller. However, the validation procedure described in RFC 8955 will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises the AS_PATH validation rules so Flow Specifications received from an External Border Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP route server. This document updates the validation procedure in RFC 8955. This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9107 on BGP Optimal Route Reflection (BGP ORR)
A new Request for Comments is now available in online RFC libraries.
RFC 9107
Title: BGP Optimal Route Reflection (BGP ORR)
Author: R. Raszuk, Ed.,
B. Decraene, Ed.,
C. Cassar,
E. Åman,
K. Wang
Status: Standards Track
Stream: IETF
Date: August 2021
Mailbox:rob...@raszuk.net,
bruno.decra...@orange.com,
cassar.christ...@gmail.com,
erik.a...@aman.se,
kfw...@juniper.net
Pages: 9
Updates/Obsoletes/SeeAlso: None
I-D Tag:draft-ietf-idr-bgp-optimal-route-reflection-28.txt
URL:https://www.rfc-editor.org/info/rfc9107
DOI:10.17487/RFC9107
This document defines an extension to BGP route reflectors. On route
reflectors, BGP route selection is modified in order to choose the
best route from the standpoint of their clients, rather than from the
standpoint of the route reflectors themselves. Depending on the
scaling and precision requirements, route selection can be specific
for one client, common for a set of clients, or common for all
clients of a route reflector. This solution is particularly
applicable in deployments using centralized route reflectors, where
choosing the best route based on the route reflector's IGP location
is suboptimal. This facilitates, for example, a "best exit point"
policy ("hot potato routing").
The solution relies upon all route reflectors learning all paths that
are eligible for consideration. BGP route selection is performed in
the route reflectors based on the IGP cost from configured locations
in the link-state IGP.
This document is a product of the Inter-Domain Routing Working Group of the
IETF.
This is now a Proposed Standard.
STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol. Distribution of this
memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
https://www.ietf.org/mailman/listinfo/ietf-announce
https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
The RFC Editor Team
Association Management Solutions, LLC
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9109 on Network Time Protocol Version 4: Port Randomization
A new Request for Comments is now available in online RFC libraries. RFC 9109 Title: Network Time Protocol Version 4: Port Randomization Author: F. Gont, G. Gont, M. Lichvar Status: Standards Track Stream: IETF Date: August 2021 Mailbox:fg...@si6networks.com, gg...@si6networks.com, mlich...@redhat.com Pages: 9 Updates:RFC 5905 I-D Tag:draft-ietf-ntp-port-randomization-08.txt URL:https://www.rfc-editor.org/info/rfc9109 DOI:10.17487/RFC9109 The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port. However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required. This document is a product of the Network Time Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9103 on DNS Zone Transfer over TLS
A new Request for Comments is now available in online RFC libraries. RFC 9103 Title: DNS Zone Transfer over TLS Author: W. Toorop, S. Dickinson, S. Sahib, P. Aras, A. Mankin Status: Standards Track Stream: IETF Date: August 2021 Mailbox:wil...@nlnetlabs.nl, s...@sinodun.com, shivankaulsa...@gmail.com, pa...@salesforce.com, allison.man...@gmail.com Pages: 32 Updates:RFC 1995, RFC 5936, RFC 7766 I-D Tag:draft-ietf-dprive-xfr-over-tls-12.txt URL:https://www.rfc-editor.org/info/rfc9103 DOI:10.17487/RFC9103 DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with respect to the recommended number of connections between a client and server for each transport. This document is a product of the DNS PRIVate Exchange Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9051 on Internet Message Access Protocol (IMAP) - Version 4rev2
A new Request for Comments is now available in online RFC libraries. RFC 9051 Title: Internet Message Access Protocol (IMAP) - Version 4rev2 Author: A. Melnikov, Ed., B. Leiba, Ed. Status: Standards Track Stream: IETF Date: August 2021 Mailbox:alexey.melni...@isode.com, barryle...@computer.org Pages: 163 Obsoletes: RFC 3501 I-D Tag:draft-ietf-extra-imap4rev2-30.txt URL:https://www.rfc-editor.org/info/rfc9051 DOI:10.17487/RFC9051 The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. This document is a product of the Email mailstore and eXtensions To Revise or Amend Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9043 on FFV1 Video Coding Format Versions 0, 1, and 3
A new Request for Comments is now available in online RFC libraries. RFC 9043 Title: FFV1 Video Coding Format Versions 0, 1, and 3 Author: M. Niedermayer, D. Rice, J. Martinez Status: Informational Stream: IETF Date: August 2021 Mailbox:mich...@niedermayer.cc, d...@dericed.com, jer...@mediaarea.net Pages: 51 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-cellar-ffv1-20.txt URL:https://www.rfc-editor.org/info/rfc9043 DOI:10.17487/RFC9043 This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. This document is a product of the Codec Encoding for LossLess Archiving and Realtime transmission Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF 111 post-meeting survey results
Thank you to all you that took part in the post-meeting survey for IETF 111. The results have now been published [1] as an interactive dashboard For commentary and analysis, see the blog post [2]. Please feel free to contact me directly if you have any questions or further feedback. [1] https://ql.tc/CjdH5Q [2] https://www.ietf.org/blog/ietf-111-post-meeting-survey/ -- Jay Daley IETF Executive Director exec-direc...@ietf.org ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (SenML Data Value Content-Format Indication) to Proposed Standard
The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'SenML Data Value Content-Format Indication' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-09-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to simplify processing of the data values, this document proposes to specify a new SenML field for indicating the Content-Format of the data. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
SECOND Last Call: (HTTP Semantics) to Internet Standard
The IESG has received a request from the HTTP WG (httpbis) to consider the following document: - 'HTTP Semantics' as Internet Standard This second Last Call is specifically on the intended RFC status change, which was incorrectly set to Proposed Standard on the previous Last Call. The IESG plans to make a decision in the next few weeks, and solicits final comments on the intended RFC status change from Proposed Standard to Internet Standard. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-09-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-httpbis-semantics/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7405: Case-Sensitive String Support in ABNF (Proposed Standard - Internet Engineering Task Force (IETF)) rfc8446: The Transport Layer Security (TLS) Protocol Version 1.3 (Proposed Standard - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (HTTP/1.1) to Internet Standard
The IESG has received a request from the HTTP WG (httpbis) to consider the following document: - 'HTTP/1.1' as Internet Standard This second Last Call is specifically on the intended RFC status change, which was incorrectly set to Proposed Standard on the previous Last Call. The IESG plans to make a decision in the next few weeks, and solicits final comments on the intended RFC status change from Proposed Standard to Internet Standard. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-09-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-httpbis-messaging/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7405: Case-Sensitive String Support in ABNF (Proposed Standard - Internet Engineering Task Force (IETF)) rfc8446: The Transport Layer Security (TLS) Protocol Version 1.3 (Proposed Standard - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (HTTP Caching) to Internet Standard
The IESG has received a request from the HTTP WG (httpbis) to consider the following document: - 'HTTP Caching' as Internet Standard This second Last Call is specifically on the intended RFC status change, which was incorrectly set to Proposed Standard on the previous Last Call. The IESG plans to make a decision in the next few weeks, and solicits final comments on the intended RFC status change from Proposed Standard to Internet Standard. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-09-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7405: Case-Sensitive String Support in ABNF (Proposed Standard - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Host Identity Protocol (hip)
The Host Identity Protocol (hip) WG in the Internet Area has concluded. The IESG contact persons are Erik Kline and Éric Vyncke. With all HIP milestones accomplished and no remaining work item, as the current responsible AD for HIP and in agreement with the current chairs (Gonzalo Camarillo) and the WG itself, I am closing the HIP WG. The mailing list will be kept active as it is usually the case. 27 RFCs have been published during the 17 years of lifetime of this WG! Thank you and congratulations to all participants, past and active chairs, past ADs for the hard work done. Regards -éric ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (S/MIME signature verification extension to JMAP) to Proposed Standard
The IESG has received a request from the JSON Mail Access Protocol WG (jmap) to consider the following document: - 'S/MIME signature verification extension to JMAP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-09-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an extension to JMAP for returning S/MIME signature verification status. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
