IPsec Task Offload Roadmap - 1

IPsec Task Offload Roadmap

WinHEC 2005 Version –May 2, 2005

Abstract

The purpose of this paper is to help educate Microsoft partners on Microsoft® Windows® support for Internet Security Protocol (IPsec) Offload. The paper starts by briefly defining the markets that Microsoft Windows IPsec is focused on. It follows with an overview of the existing IPsec Task Offload support on Windows, including recommendations for what types of IPsec offload are the most important to implement.The paper concludes with forward-looking statements on where Microsoft expects to take IPsec Task Offload.

This information applies for the following operating systems:
Microsoft Windows Vista™
Microsoft Windows XP Professional x64 Edition
Microsoft Windows Server™ 2003 Service Pack 1
Microsoft Windows XP
Microsoft Windows 2000

The current version of this paper is maintained on the Web at

Contents

1Introduction

1.1Glossary of Terms

1.2Overview of the IPsec Protocol

1.3IPsec Deployment Scenarios

1.3.1Windows Server 2003 and Windows XP Scenarios

1.3.2Windows Vista Scenarios

1.4Recommended Reading

2NDIS 5.1 IPsec Task Offload Requirements

2.1Required Features

2.1.1Capability Advertisement

2.1.2State Storage: Adding State or Initiate Offload

2.1.3State Storage: Removing State or Terminate Offload

2.1.4Timing Conditions during State Transition

2.1.5Interpreting NDIS Packet Out of Band Data for NDIS 5.1 Task Offload

2.1.6Additional Packet Processing Requirements

2.2Other Features

2.3Unsupported Capabilities

2.4Guidance on Implementing NDIS 5.1 IPsec Task Offload Optional Features

3Future IPsec Task Offload

3.1Windows Vista Support for NDIS 5.1 IPsec Task Offload

3.2NDIS 5.1 IPsec Offload Functionality within NDIS 6.0

3.3Support for Teaming IPsec Offload Cards with NDIS 6.0

3.4Future Extensions to IPsec Task Offload

3.4.1IPv6 Task Offload Support

3.4.2Support for New Cryptographic Algorithms

Disclaimer

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2005 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

1Introduction

Microsoft expects deployment of the Internet Security Protocol (IPsec) to significantly increase in the coming years. However, there is a concern that the additional CPU load, due to IPsec processing, might inhibit deployment. Under some workloads, deployment of IPsecin software can lead to degradation of server capacity. Thus there is a potential need for IPsec offload. The purpose of this paper is to help partners to understand the Microsoft® Windows® approach toIPsec offload, referred to as IPsec Task Offload. The introduction provides a brief overview of IPsec and important IPsec deployment scenarios. The next section provides an overview of the existing capabilities on Windows (including Windows 2000, Windows XP, and Microsoft Windows Server™ 2003), implemented within the Network Device Interface Specification (NDIS), version 5.1.It provides recommendations to IHVs for whichIPsecTask Offloadcapabilities map to specific IPsec scenarios.The paper concludes with forward looking statements on where Microsoft expects to evolveIPsec Task Offload.

This paper is focused on the following goals:

  • Present a simplified overview of NDIS 5.1IPsecTask Offloadthat is focused on hardware requirements and capabilities. The text supplements the IPsec Task Offload information in the Windows Driver Development Kit (DDK), emphasizing the conceptual framework of IPsec Task Offload rather than the interface definitions. Please see the DDK for detailed interface definitions.
  • Focus hardware developers on specific IPsec offload capabilities that align with Microsoft's vision for IPsec deployment. The expectation is that this will aid the IHV in prioritizing specific IPsec offload capabilities by mapping specific technology features to specific deployment scenarios.
  • Provide a road map for how Microsoft expects to evolve NDIS 5.1IPsecTask Offload hardware.

1.1Glossary of Terms

Internet Protocol Security Protocol Suite (IPsec)

A set of protocols used to authenticate and encrypt IP packets using cryptographic techniques. The suite is standardized within the Internet Engineering Task Force (IETF).

Authentication Header (AH)

An IPsec protocol implemented by adding an extension header to IP packets which includes a keyed hash over the packet. It is used to provide data origin authentication and data integrity checks.

Encapsulating Security Payload (ESP)

An IPsec protocol implemented by adding an extension header and a trailer to each IP packet. ESP enables data integrity verification, origin authentication and data privacy.

Offload Target

The combination of miniport driver, intermediate driver(s) and hardware Network Interface Card (NIC) that is presented to the host stack as a single miniport device capable of offloading some functions from the host stack.

Clear text

An Internet Protocol (IP)datagram whose payload is "in the clear" (meaning the payload is not authenticatedor encrypted).

Cryptographic text

An IP datagram that includes an authentication hash which can be used to verify the payload integrity and/or encrypt the payload. In the context of IPsec this is a packet with an AH and/or an ESP header.

Security Association (SA)

The state associated with IPsec for data flow in one direction (simplex). An SA is used to describe IPsec state used to encapsulate the payload using either ESP or AH encapsulation.

CAPI

Microsoft Cryptographic API.

CBC

Cipher Block Chaining.

Internet Key Exchange (IKE)

A secure key negotiation protocol.

1.2Overview of the IPsec Protocol

The IPsec suite of protocols is designed to provide interoperable, high quality cryptographically-based security for IPv4 and IPv6. The security services offered by the protocols currently present in this suite include access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. The security is offered at the IP layer in the network stack thereby providing the means to enforce security on all IP based network traffic on the host.

IPsec uses two traffic security protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP).Cryptographic key management procedures and protocols are used to provide these security services. The implementation of these traffic security protocols is part of the host network stack on the Windows operating system platform, including Windows 2000, Windows XP, and Windows Server 2003.

The IPsec security suit also incorporates a security policy database which describes the traffic to be protected and the algorithms to be used to negotiate keys and protect traffic. Additionally it contains one or more keying modules which provide the capability to generate keys using specified algorithms and standardized key generation exchanges over the network. A common keying protocol is the Internet Key Exchange protocol, or IKE.

Application of IPsec security is transparent to applications because the IPsecprotocol intercepts locallysent or forwarded packets transparentlywithin the host stack.The host stack matches the packet against its policy database and then as needed negotiates session keys and uses them to protect the traffic using the AH and/or ESP extension headers. Similarly on the receive side the protocol de-encapsulates the incoming AH/ESP traffic and delivers clear text to the application’s socket.

The following diagram illustrates the interacting software and hardware components. The diagram also includes for reference the CAPI Cryptographic interface. While the CAPI interface is not discussed in this white paper, it is included here to contrast another form of cryptographic offload offered on Windows. While CAPI offload can be used to offload any cryptographic processing from the host stack, because the CAPI interface is a general purpose interface rather than an interface designed to send networking packets, additional overhead is incurred to actually send the packet. Specifically the buffer in general must cross the I/O bus three times when the CAPI interface is used for networking verses once for IPsec offload. For example, on transmit, this occurs once to move the buffer to the CAPI hardware to perform the cryptographic function, once to move the processed buffer back to host memory so that the network stack can format the buffer for data transmission, and once to actually send the datagram to the NIC. With IPsec offload, the CAPI interface is not called. Instead the buffer is formatted for transmission (for example, add an IPsec header, IP header, Data Link Layer header), and then given to the offload target through the IPsec offload NDIS interface to enable the offload target to perform the cryptographic processing and data transmission.

Figure 1: Windows Architecture for IPsec

IPsec leverages a variety of cryptographic algorithms for these operations; examples includeDiffie Hellman, SHA1, MD5, DES, 3DES, AES, and so on. Cryptographic operations are invoked first during the key generation process.Once the initial keys are available, cryptographic operations are used on each packet forauthentication or for authentication and encryption.Key generation cryptography repeats whenever keys need to be re-established to maintain their security strengths.

Application of these cryptographic algorithms can be a significant cost in terms of CPU cycles.Typicallyauthentication is a lot cheaper than encryption, however even just authentication can be a very significant overhead when compared to thepacket processing cost when IPsecis not used.Because of this, beginning with Windows 2000, the host stack supports an NDIS interface which allows offload targets to perform cryptographic processing on AH and ESP packets for both inbound and outbound traffic.This NDIS interface is known as the IPsecTask Offload interface. Currently it is supported on NDIS 5.1.

A few important aspects of the IPsecTask Offloadinclude:

  • On the send path the NIC performs cryptography on the packet and puts it on the wire. For receive, the NIC performs the cryptographic functions and delivers the packet to the host.
  • It does not provide cryptographic offload for keying module operations - keying module operations can be sped up separately by supporting CAPI offload.

1.3IPsec Deployment Scenarios

1.3.1Windows Server 2003 and Windows XP Scenarios

IPsec deployment scenarios for Windows Server 2003 and Windows XP can be broadly categorized as:

  • Domain Isolation using machine credentials.
  • Firewall Integration with IPsec to allow security group bypass capability.

Domain Isolation can be achieved by using the Microsoft Active Directory®directory service as a solution to control network communication and encourage machine domain membership. As shown in the figure above, the managed machines can authenticate using domain credentials and can freely access all network resources. An unmanaged PC is not allowed to connect to any of the managed machines because they do not have valid domain credentials. However managed machines can communicate with non-domain joined machines.

When the host firewall is turned on, authenticated traffic can bypass the firewall through a feature called security group bypass. This traffic is authenticated using IPsec machine credentials.

1.3.2Windows VistaScenarios

In the next release of Microsoft Windows Vista™, IPsec comes with several feature enhancements to enable the following new IPsec deployment scenarios:

  • Domain Isolation usinguser credentials
  • Network Access Protection
  • Host firewall integration to allow application level authorization

In Windows Server 2003 or Windows XP, Domain Isolation used Active Directory for domain credentials and only allowed for machine credentials. The WindowsVista enhancements allow domain credentials to be either machine or user credentials.

Network Access Protection is similar to Domain Isolation except that network segmentation is achieved using health certificates. Hence only "healthy" machines can talk to each other and access network resources. A "non-healthy" machineisprevented from communicating with most network resources except for network resources required to get the machine "healthy."

Firewall integration with IPsec allows application level authorization such that authenticated and encrypted traffic can be filtered based on application based policies. Here application authorization leverages IPsec for filtering based on peer machine identity , user identity or path/health indicators.

1.4Recommended Reading

  • Security Architecture for the Internet Protocol, S. Kent, R. Atkins, Internet Engineering Task Force RFC 2401, November 1998,
  • IP Authentication Header, S. Kent, R. Atkins, Internet Engineering Task Force RFC 2402 November 1998,
  • IP Encapsulating Security Payload (ESP), S. Kent, R. Atkins, RFC 2406, November 1998,
  • UDP Encapsulation of IPsecESP Packets, A. Huttunen et al, Internet Engineering Task Force RFC 3948, January 2005,

2NDIS 5.1IPsecTask Offload Requirements

This section covers required functionality for anIPsec NDIS 5.1Task Offloaddevicefor Windows Server 2003, Windows XP, and Windows 2000.This sectionprovides a summary of the mandatory requirements that the offload NIC must meet in order to do any part of IPsec NDIS 5.1Task Offload - for the full set of requirements and details of the interface, please refer to the DDK. Note that IPsec NDIS 5.1Task Offload is defined for Internet Protocol version 4 (IPv4) traffic only.

2.1Required Features

2.1.1Capability Advertisement

In response to a query of OID_TCP_TASK_OFFLOAD the offload target must advertise its supported IPsec offload capabilities using an NDIS_TASK_IPSEC structure. This structure isshown below.

typedefstruct_NDIS_TASK_IPSEC
{
struct
{
ULONGAH_ESP_COMBINED;
ULONGTRANSPORT_TUNNEL_COMBINED;
ULONGV4_OPTIONS;
ULONGRESERVED;
}Supported;
struct
{
ULONGMD5:1;
ULONGSHA_1:1;
ULONGTransport:1;
ULONGTunnel:1;
ULONGSend:1;
ULONGReceive:1;
}V4AH;
struct
{
ULONGDES:1;
ULONGRESERVED:1;
ULONGTRIPLE_DES:1;
ULONGNULL_ESP:1;
ULONGTransport:1;
ULONGTunnel:1;
ULONGSend:1;
ULONGReceive:1;
}V4ESP;
}NDIS_TASK_IPSEC,*PNDIS_TASK_IPSEC;

The offload target sets this structure as follows:

1.V4AH structure: This structure represents the AH capabilities that the NIC supports. Additionally the cryptographic integrity algorithms selected here apply to both the AH and the ESP headers. These fields are set as follows:

a)MD5 and/or SHA_1 are set if the offload target has hardware acceleration for these algorithms for either AH or ESP header.

  1. In order to advertise ESP only authentication the offload target can set both send and receive to zero or both transport and tunnel to zero in V4AH and just set the appropriate integrity algorithms it supports.

b)Transport and Tunnel flags are set appropriately by the offload target depending on whether it supports transport and/or tunnel mode SAs that require AH.

c)Send and Receive flags are set appropriately by the offload target depending on whether it can do send or receive path offload (or both) for AH.

d)If the offload target indicates it supports any of the cryptographic integrity algorithms (SHA_1 or MD5), and if it does ESP as well it must support the same algorithms for ESP.

e)It’s highly recommended to support SHA1 integrity capabilities with ESP over transport mode.

2.V4ESP structure:This structure represents the ESP capabilities that the NIC supports. If ESP is supported, the authentication algorithms supported are specified in the V4AH structure. These fields are set as follows:

a)DES and TRIPLE_DES are set if the offload target has hardware acceleration for these privacy algorithms for the ESP header. NULL-ESP represents the capability to do ESP authentication only using the integrity algorithms mentioned previously under V4AH.

b)Transport and Tunnel flags are set appropriately by the offload target depending on whether it supportsESP transport and/or tunnel mode SAs.

c)Send and Receive flags are set appropriately by the offload target depending on whether it supports send or receive path offload (or both) for ESP.

d)The offload target must be capable of combining any supported integrity algorithm with any supported confidentiality algorithm

e)It’s highly recommended that the offload NIC support ESP NULL and ESP triple DES over transport mode. And that the offload target be able to combine this with the SHA1 integrity algorithm.

3.Supported structure. This structure provides additional capability advertisement for the offload target:

a)AH_ESP_COMBINED is set by the offload target if it can combine AH and ESP processing on the same packet.

b)TRANSPORT_TUNNEL_COMBINED is set by the offload target if it can combine transport and tunnel mode processing on the same packet.

c)V4_OPTIONS is set by the offload target if it can support sends and receives of packets containing IPv4 options. On the receive this is not a hard guarantee that the offload target will offload process of all incoming IPv4 packets with options over offloaded SAs. If the offload target can not support a specific datagram, it can simply forward the datagram to the host stack for processing. For the send side the offload target must be able to guarantee that it will correctly offload send packets forany valid combination of IPv4 options forcryptographic processing.

d)Reserved represents the bit wise OR of the UDP ESP encapsulation types supported by the offload target.If the offload target does not set this we assume that it can not offload UDP ESP SAs. It’s recommended that the offload target support UDP encapsulated transport (IPSEC_TPT_UDPESP_ENCAPTYPE_OTHER).