* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ipsecme Status Pages

IP Security Maintenance and Extensions (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2008-Jul-08 —  

2018-05-29 charter

IP Security Maintenance and Extensions (ipsecme)


 Current Status: Active

     David Waltermire <david.waltermire@nist.gov>
     Tero Kivinen <kivinen@iki.fi>

 Security Area Directors:
     Benjamin Kaduk <kaduk@mit.edu>
     Eric Rescorla <ekr@rtfm.com>

 Security Area Advisor:
     Eric Rescorla <ekr@rtfm.com>

 Mailing Lists:
     General Discussion: ipsec@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/ipsec
     Archive:            https://mailarchive.ietf.org/arch/browse/ipsec/

Description of Working Group:

  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

  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

  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.

Goals and Milestones:
  Done     - IETF Last Call on DDoS protection
  Done     - IETF Last Call on Curve25519 and Curve448 for IKEv2
  Done     - IETF Last Call on cryptographic algorithms for IKEv2
  Done     - IETF Last Call on cryptographic algorithms for ESP / AH
  Done     - IETF Last Call on TCP Encapsulation of IKE and IPsec
  Done     - IETF Last Call on Using EdDSA in the IKEv2
  Jun 2018 - IETF Last Call on Split-DNS Configuration for IKEv2
  Jun 2018 - IETF Last Call on Implicit IV in IPsec
  Aug 2018 - IETF Last Call on partially quantum resistant IKEv2

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/ipsecme/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -