Protocol Action: 'DNS Terminology' to Best Current Practice (draft-ietf-dnsop-terminology-bis-14.txt)
The IESG has approved the following document: - 'DNS Terminology' (draft-ietf-dnsop-terminology-bis-14.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ Technical Summary The domain name system (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719, and thus will obsolete RFC 7719. It will also update RFC 2308. Working Group Summary This document has proceeded through the WG remarkably smoothly. The editors have done an enormous amount of work, as have the reviewers. The editors were open with the WG in taking input and mostly incorporating it. A terminology document for a 30yo protocol covered by dozens of existing documents and used by millions of hosts and billions of users every day is a particularly thankless task and it's been done very well. It was written expressly to obsolete 7719, which was Informational and tackled only those definitions that were unambiguous; this document extends them in an attempt to resolve some such ambiguities to recommend "best practice". Document Quality The document attempts to describe both the standard and practice for a protocol that's been in use for 30 years and dozens of implementations. Attention in the WG came from both operators and implementers. Personnel Suzanne Woolf is the Document Shepherd. Warren Kumari is RAD!
WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme)
The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) --- Current status: Active WG Chairs: David Waltermire Tero Kivinen Assigned Area Director: Eric Rescorla Security Area Directors: Eric Rescorla Benjamin Kaduk Mailing list: Address: ip...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Group page: https://datatracker.ietf.org/group/ipsecme/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar or better quantum resistant properties to those of IKEv1. Split-DNS is a common configuration for VPN deployments in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys than conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address
Results of IETF-conflict review for draft-melnikov-email-over-pmul-08
The IESG has completed a review of draft-melnikov-email-over-pmul-08 consistent with RFC5742. The IESG has no problem with the publication of 'Multicast Email (MULE) over Allied Communications Publication (ACP) 142' as an Informational RFC. The IESG has concluded that there is no conflict between this document and IETF work. The IESG would also like the Independent Submissions Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-melnikov-email-over-pmul/ A URL of the reviewed Internet Draft is: https://datatracker.ietf.org/doc/draft-melnikov-email-over-pmul/ The process for such documents is described at https://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Protocol Action: 'L2L3 VPN Multicast MIB' to Proposed Standard (draft-ietf-bess-l2l3-vpn-mcast-mib-16.txt)
The IESG has approved the following document: - 'L2L3 VPN Multicast MIB' (draft-ietf-bess-l2l3-vpn-mcast-mib-16.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes two MIB modules which will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast. Working Group Summary There is good consensus from the WG, and there is no controversy. Document Quality The Document has been thoroughly reviewed by MIB Doctor Glenn Mansfield and all of his comments were addressed. Personnel Document Shepherd: Mach Chen Responsible Area Director: Martin Vigoureux
Protocol Action: 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY' to Proposed Standard (draft-ietf-dnsop-refuse-any-07.txt)
The IESG has approved the following document: - 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY' (draft-ietf-dnsop-refuse-any-07.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ Technical Summary The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance or other reasons. This document provides specific behaviorial guidance for DNS servers and/or clients. Working Group Summary There was some initial issues reaching consensus during WGLC, but the authors worked out the specific issues with the working group and the final version met with strong consensus. Document Quality The document is clear and well written. It contains an Implementation section discussing implementation experience, and is deployed in the Internet. Personnel Document Shepherd is Tim Wicinski and Warren "Ace" Kumari is RAD!
Protocol Action: 'BGP/MPLS Layer 3 VPN Multicast Management Information Base' to Proposed Standard (draft-ietf-bess-mvpn-mib-12.txt)
The IESG has approved the following document: - 'BGP/MPLS Layer 3 VPN Multicast Management Information Base' (draft-ietf-bess-mvpn-mib-12.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multicast communication over IP Virtual Private Networks (VPNs) supported by MultiProtocol Label Switching/Border Gateway Protcol (MPLS/BGP) on a Provider Edge router. Working Group Summary There is good consensus from the WG, and there is no controversy. Document Quality The Document has been thoroughly reviewed by MIB Doctor Glenn Mansfield and all of his comments were addressed. Personnel Document Shepherd: Mach Chen Responsible Area Director: Martin Vigoureux
Document Action: 'P-Charge-Info - A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)' to Informational RFC (draft-york-p-charge-info-08.txt)
The IESG has approved the following document: - 'P-Charge-Info - A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)' (draft-york-p-charge-info-08.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-york-p-charge-info/ Technical Summary The P-Charge-Info header field is a SIP header field that carries the identity/number used by the network for billing purposes. This information is separate from the Caller ID, which is carried in the P-Asserted-Identity or From header fields. Certain network configurations have found it useful to carry the billing identity separately, especially when it differs from the identify of the caller, for instance, when keeping track of billing information for an enterprise rather than the enterprise's various phone numbers. Working Group Summary This draft was originally discussed back in 2008 in the SIPPING working group and received a lot of feedback from participants, but was not adopted. At the time, the SIP change process (originally documented in RFC 3427) was being updated and the working group was shutting down (mailing list closed in 2011). There were no calls for adoption or for consensus on the SIPPING mailing list. This document shepherd's read of the archives is that participants were for the most part neutral about this draft, but willing to provide feedback. In general, SIPPING participants frowned upon new P- header fields, and that was reflected in the updated SIP change process (RFC 5727). This draft was also discussed briefly in the DISPATCH working group, but was not dispatched. A former RAI AD suggested that the authors should pursue AD-sponsorship of the draft. Document Quality This header field has been deployed in multiple networks since 2007. The Acknowledgements section of this document thanks the multiple people who have provided feedback over the years on this draft. As per the SIP change process (RFC 5727), this draft was reviewed by the Designated Expert for SIP Header Fields, Adam Roach, in February 2018. His feedback was incorporated in the -03 version. Personnel Document Shepherd: Jean Mahoney Responsible Area Director: Ben Campbell
Early Bird Registration Ends Today!
IETF 103 Bangkok, Thailand November 3-9, 2018 IETF 103 Information: https://www.ietf.org/how/meetings/103/ Early Bird Deadline The early bird deadline for registration is today, Monday, September 17th. Be sure to register and pay before the deadline passes! Register online at: https://ietf.org/meeting/register.html NOTE: If you have started the registration process but not completed payment, your registration record will be deleted at UTC 23:59 on September 17. After September 17 at UTC 23:59 you will be required to re-enter your data and the registration fee will be $875 USD until the next registration deadline on October 22, at which the registration fee will become $1,000 USD. If you have any questions or need assistance, please do not hesitate to contact: ietf-regist...@ietf.org
