Last Call: draft-ietf-dane-use-cases-04.txt (Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)) to Informational RFC
The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)' draft-ietf-dane-use-cases-04.txt as an Informational RFC 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 i...@ietf.org mailing lists by 2011-07-19. 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 Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Traditionally, this authentication has been based on PKIX trust hierarchies, rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dane-use-cases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dane-use-cases/ 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
Document Action: 'Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)' to Informational RFC (draft-kanno-tls-camellia-03.txt)
The IESG has approved the following document: - 'Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)' (draft-kanno-tls-camellia-03.txt) as an 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 Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-kanno-tls-camellia/ Technical Summary This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to additional support the Camellia encryption algorithm as a block cipher. Working Group Summary This is individual submission. Document Quality The TLS-WG was consulted for input. Technical as well as editorial comments were addressed. Personnel Satoru Kanno (kanno.sat...@po.ntts.co.jp) is the document shepherd. Sean Turner (turn...@ieca.com) is the Responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Home Networks (homenet)
A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, July 12, 2011. Home Networks (homenet) --- Current Status: Proposed Working Group Last Edit: Thursday, June 30th, 2011 Chairs: TBD Internet Area Directors: Ralph Droms rdroms.i...@gmail.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: Jari Arkko jari.ar...@piuha.net Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: f...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small �residential home� networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols
WG Review: Recharter of Protocol Independent Multicast (pim)
A modified charter has been submitted for the Protocol Independent Multicast (pim) working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, July 12, 2011. Protocol Independent Multicast (pim) --- Current Status: Active Working Group Last updated: 2011-07-01 Chairs: Mike McBride mmcbr...@cisco.com Stig Venaas s...@venaas.com Routing Area Directors: Stewart Bryant stbry...@cisco.com Adrian Farrel adr...@olddog.co.uk Routing Area Advisor: Adrian Farrel adr...@olddog.co.uk Mailing Lists: General Discussion: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pim/ Archive: http://www.ietf.org/mail-archive/web/pim/ Description of Working Group The Protocol Independent Multicast (PIM) Working Group has completed the standardization of PIM with RFC 4601. The WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These PIM extensions will involve reliability, resiliency, scalability, management, and security. If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs and/or L3VPNs requires extensions to PIM, then such extensions will be developed within the PIM WG. Additional work on the PIM-BIDIR and BSR drafts may also be necessary by the WG as these drafts progress through Standards Track. The working group has produced MIB modules for PIM in RFC 5060 and RFC 5240. The working group currently has no plans to do further work on management for PIM. If proposals are brought forward to update or extend the existing MIB modules or to develop YANG modules, the working group will be rechartered. The PIM WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable pim, pim join attributes and pim authentication. The working group primarily works on extensions to PIM, but may take on work related to IGMP/MLD. There is a significant number of errata that need to be addressed in order to advance RFC4601 to Draft Standard. The PIM WG will correct the errata, as necessary, and update RFC4601. The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required. Goals and Milestones: Done Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items. Done Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard. Done Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC Done Submit PIM-SM Applicability Statements Done Submit PIMv2 MIB to IESG for consideration as proposed standard. Done Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts. Done Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards. Done Submit PIMv2 MIB to IESG for consideration as draft standard. Done Ratify new WG charter and milestones Done Submit the BSR spec as a Proposed Standard to the IESG Done Submit the BSR MIB as a Proposed Standard to the IESG Done Submit a generic TLV PIM Join Attribute PS draft to the IESG Done Submit RPF Vector (use of PIM Join Attribute) as PS to the IESG Done Submit a way to authenticate PIM link local messages as PS to the IESG Done Submit an Informational PIM last hop threats document to the IESG Aug 2011 First WG version of udated RFC 4601 Aug 2011 Submit a more reliable PIM solution (refresh reduction) to the IESG Nov 2011 Submit a population count extension to PIM to the IESG Dec 2011 Submit update of RFC 4601 to IESG for advancement to Draft Standard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6274 on Security Assessment of the Internet Protocol Version 4
A new Request for Comments is now available in online RFC libraries. RFC 6274 Title: Security Assessment of the Internet Protocol Version 4 Author: F. Gont Status: Informational Stream: IETF Date: July 2011 Mailbox:ferna...@gont.com.ar Pages: 75 Characters: 179909 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-opsec-ip-security-07.txt URL:http://www.rfc-editor.org/rfc/rfc6274.txt This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Operational Security Capabilities for IP Network Infrastructure 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 http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. 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
Last Call: draft-ietf-mboned-mtrace-v2-08.txt (Mtrace Version 2: Traceroute Facility for IP Multicast) to Proposed Standard
The IESG has received a request from the MBONE Deployment WG (mboned) to consider the following document: - 'Mtrace Version 2: Traceroute Facility for IP Multicast' draft-ietf-mboned-mtrace-v2-08.txt as a 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 i...@ietf.org mailing lists by 2011-07-19. 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 describes the IP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how management applications can use the router functionality. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/ 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
Last Call: draft-ietf-msec-gdoi-update-09.txt (The Group Domain of Interpretation) to Proposed Standard
The IESG has received a request from the Multicast Security WG (msec) to consider the following document: - 'The Group Domain of Interpretation' draft-ietf-msec-gdoi-update-09.txt as a 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 i...@ietf.org mailing lists by 2011-07-19. 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 describes an updated version of the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. DOWNREFs This specification contains three normative references to obsoleted RFCs: RFC 2407, RFC 2408, and RFC 2409. This specification contains three normative references to informational RFCs: RFC 2627, RFC 3447, and RFC 5093. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ 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
