[IPsec] 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: Yoav Nir Tero Kivinen Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: ipsec@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. 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 family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. Some systems support security labels (aka security context) as one of the selectors of the SPD. This labe
[IPsec] 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: ipsec@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 famil
[IPsec] 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: Kathleen Moriarty Security Area Directors: Stephen Farrell Kathleen Moriarty Mailing list: Address: ipsec@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), 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 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: IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol. IKEv2 utilizes a number of cryptographic algorithms in order to provide security services. To support interoperability a number of mandatory-to-implement (MTI) algorithms are defined in RFC4307 for IKEv2 and in RFC7321 for ESP/AH. There is interest in updating the MTIs in RFC4307 and RFC7321 based on new algorithms, changes to the understood security strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 and RFC7321 proposing updates to the MTI algorithms used by IKEv2 and IPsec to address these changes. There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange and EdDSA for authentication in the IKEv2 protocol. The group will extend the IKEv2 protocol to support key agreement using these curves and their related functions. 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 IKEv2 to have similar quantum resistant properties than IKEv1 had. There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE and ESP packets need to be transmitted over TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP. The group will also provide guidance on how to detect when IKE cannot be negotiated over UDP, and TCP should be used as a fallback 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 form of 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. This charter will expire in December 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Oct 2016 - IETF Last Call on DDoS protection Oct 2016 - IETF Last Call on Curve25519 and Curve448 for IKEv2 Nov 2016 - IETF Last Call on cryptographic algorithms for IKEv2 Nov 2016 - IETF Last Call on cryptographic algorithms for ESP / AH Dec 2016 - IETF Last Call on TCP Encapsulation of IKE and IPsec Jan 2017 - IETF Last Call on Using EdDSA in the IKEv2 Feb 2017 - IETF Last Call on Split-DNS Configuration for IKEv2 Feb 2017 - IETF Last Call on Implicit IV in IPsec Jun 2017 - IETF Last Call on partially quantum resistant IKEv2 _
[IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme)
The IP Security Maintenance and Extensions (ipsecme) working group 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: Paul Hoffman Yaron Sheffer Assigned Area Director: Kathleen Moriarty Mailing list Address: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Charter: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), 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 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: IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol. There is interest in adapting the IKE protocol for opportunistic use cases, by allowing one or both endpoints of the exchange to remain unauthenticated. The group will extend the protocol to support these use cases. This charter will expire in December 2015 (a year from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Done - IETF Last Call on large scale VPN use cases and requirements Done - IETF last call on IKE fragmentation solution Done - IETF last call on new mandatory-to-implement algorithms Aug 2015 - IETF Last Call on DDoS protection Dec 2015 - IETF Last Call on null authentication ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme)
The IP Security Maintenance and Extensions (ipsecme) working group 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 Working Group Chairs: Paul Hoffman Yaron Sheffer Assigned Area Director: Sean Turner Mailing list Address: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Charter of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 5996), 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 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: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and helping publish Informational documents describing current vendor proprietary solutions. Recently discovered incorrect behavior of ISPs poses a challenge to IKE, whose UDP messages (especially #3 and #4) sometimes get fragmented at the IP level and then dropped by these ISPs. There is interest in solving this issue by allowing transport of IKE over TCP; this is currently implemented by some vendors. The group will standardize such a solution, using draft-nir-ipsecme-ike-tcp as a starting point. The WG will review and possibly revise the list of mandatory-to- implement algorithms for ESP and AH based on five years of experience with newer algorithms and cryptographic modes. This work will be based on draft-mcgrew-ipsec-me-esp-ah-reqts. The WG will update the way IKEv2 uses public keys that are trusted out-of-band (that is, not through a common PKIX trust anchor). This work will be based on draft-kivinen-ipsecme-oob-pubkey. The WG will revise the IKEv2 specification with a small number of mandatory tests required for the secure operation of IKEv2 when using elliptic curve cryptography. This work will be based on draft-sheffer-ipsecme-dh-checks. This charter will expire in January 2015 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Done - WG last call on IPv6 configuration payloads Done - WG last call on IPsec roadmap Done - WG last call on session resumption Done - WG last call on redirect Done - WG last call on IKEv2bis Done - WG last call on ESP NULL traffic visibility Done - WG last call on HA requirements Done - WG last call on quick crash discovery Done - WG last call on EAP-only authentication Nov 2012 - IETF Last Call on large scale VPN use cases and requirements Feb 2013 - IETF Last Call on IKE over TCP Feb 2013 - IETF LC new MITM algorithms Apr 2013 - IETF LC out-of-band public key draft Jun 2013 - IETF Last Call on large scale VPN protocol ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme)
The IP Security Maintenance and Extensions (ipsecme) working group 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 Working Group Chairs: Paul Hoffman Yaron Sheffer Assigned Area Director: Sean Turner Mailing list Address: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Charter of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 5996), 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 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: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and helping publish Informational documents describing current vendor proprietary solutions. Recently discovered incorrect behavior of ISPs poses a challenge to IKE, whose UDP messages (especially #3 and #4) sometimes get fragmented at the IP level and then dropped by these ISPs. There is interest in solving this issue by allowing transport of IKE over TCP; this is currently implemented by some vendors. The group will standardize such a solution, using draft-nir-ipsecme-ike-tcp as a starting point. The WG will review and possibly revise the list of mandatory-to- implement algorithms for ESP and AH based on five years of experience with newer algorithms and cryptographic modes. This work will be based on draft-mcgrew-ipsec-me-esp-ah-reqts. The WG will update the way IKEv2 uses public keys that are trusted out-of-band (that is, not through a common PKIX trust anchor). This work will be based on draft-kivinen-ipsecme-oob-pubkey. This charter will expire in November 2015 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Done - WG last call on IPv6 configuration payloads Done - WG last call on IPsec roadmap Done - WG last call on session resumption Done - WG last call on redirect Done - WG last call on IKEv2bis Done - WG last call on ESP NULL traffic visibility Done - WG last call on HA requirements Done - WG last call on quick crash discovery Done - WG last call on EAP-only authentication Nov 2012 - IETF Last Call on large scale VPN use cases and requirements Feb 2013 - IETF Last Call on IKE over TCP Jun 2013 - IETF Last Call on large scale VPN protocol ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme)
The IP Security Maintenance and Extensions (ipsecme) working group 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 Working Group Chairs: Paul Hoffman Yaron Sheffer Assigned Area Director: Sean Turner Mailing list Address: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Charter of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 5996), 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 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: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and helping publish Informational documents describing current vendor proprietary solutions. Recently discovered incorrect behavior of ISPs poses a challenge to IKE, whose UDP messages (especially #3 and #4) sometimes get fragmented at the IP level and then dropped by these ISPs. There is interest in solving this issue by allowing transport of IKE over TCP; this is currently implemented by some vendors. The group will standardize such a solution, using draft-nir-ipsecme-ike-tcp as a starting point. This charter will expire in August 2014 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Done - WG last call on IPv6 configuration payloads Done - WG last call on IPsec roadmap Done - WG last call on session resumption Done - WG last call on redirect Done - WG last call on IKEv2bis Done - WG last call on ESP NULL traffic visibility Done - WG last call on HA requirements Done - WG last call on quick crash discovery Done - WG last call on EAP-only authentication Nov 2012 - IETF Last Call on large scale VPN use cases and requirements Feb 2013 - IETF Last Call on IKE over TCP Jun 2013 - IETF Last Call on large scale VPN protocol ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
