Ipsec Task Offload Roadmap

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 http://www.microsoft.com/whdc/. Contents 1 Introduction...... 3 1.1 Glossary of Terms...... 3 1.2 Overview of the IPsec Protocol...... 4 1.3 IPsec Deployment Scenarios...... 6 1.3.1 Windows Server 2003 and Windows XP Scenarios...... 6 1.3.2 Windows Vista Scenarios...... 6 1.4 Recommended Reading...... 7 2 NDIS 5.1 IPsec Task Offload Requirements...... 7 2.1 Required Features...... 7 2.1.1 Capability Advertisement...... 7 2.1.2 State Storage: Adding State or Initiate Offload...... 9 2.1.3 State Storage: Removing State or Terminate Offload...... 11 2.1.4 Timing Conditions during State Transition...... 11 2.1.5 Interpreting NDIS Packet Out of Band Data for NDIS 5.1 Task Offload...... 11 2.1.6 Additional Packet Processing Requirements...... 12 2.2 Other Features...... 12 2.3 Unsupported Capabilities...... 13 2.4 Guidance on Implementing NDIS 5.1 IPsec Task Offload Optional Features....13 3 Future IPsec Task Offload...... 13 3.1 Windows Vista Support for NDIS 5.1 IPsec Task Offload...... 13 3.2 NDIS 5.1 IPsec Offload Functionality within NDIS 6.0...... 14 3.3 Support for Teaming IPsec Offload Cards with NDIS 6.0...... 14 3.4 Future Extensions to IPsec Task Offload...... 15 3.4.1 IPv6 Task Offload Support...... 15 3.4.2 Support for New Cryptographic Algorithms...... 15 IPsec Task Offload Roadmap - 2

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.

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.

WinHEC 2005 Version – May 2, 2005 IPsec Task Offload Roadmap - 3

1 Introduction 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 IPsec in 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 to IPsec 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 which IPsec Task Offload capabilities map to specific IPsec scenarios. The paper concludes with forward looking statements on where Microsoft expects to evolve IPsec Task Offload. This paper is focused on the following goals:  Present a simplified overview of NDIS 5.1 IPsec Task Offload that 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.1 IPsec Task Offload hardware.

1.1 Glossary 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 authenticated or 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.2 Overview 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 IPsec protocol intercepts locally sent or forwarded packets transparently within 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 include Diffie 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 for authentication 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. Typically authentication is a lot cheaper than encryption, however even just authentication can be a very significant overhead when compared to the packet processing cost when IPsec is 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 IPsec Task Offload interface. Currently it is supported on NDIS 5.1. A few important aspects of the IPsec Task Offload include:  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.3 IPsec Deployment Scenarios

1.3.1 Windows 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.2 Windows Vista Scenarios In the next release of Microsoft Windows Vista™, IPsec comes with several feature enhancements to enable the following new IPsec deployment scenarios:  Domain Isolation using user 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 Windows Vista 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" machine is prevented 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.4 Recommended Reading  Security Architecture for the Internet Protocol, S. Kent, R. Atkins, Internet Engineering Task Force RFC 2401, November 1998, http://www.ietf.org/rfc/rfc2401.txt?number=2401  IP Authentication Header, S. Kent, R. Atkins, Internet Engineering Task Force RFC 2402 November 1998, http://www.ietf.org/rfc/rfc2402.txt?number=2402  IP Encapsulating Security Payload (ESP), S. Kent, R. Atkins, RFC 2406, November 1998, http://www.ietf.org/rfc/rfc2406.txt?number=2406  UDP Encapsulation of IPsec ESP Packets, A. Huttunen et al, Internet Engineering Task Force RFC 3948, January 2005, http://www.ietf.org/rfc/rfc3948.txt?number=3948

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

2.1 Required Features

2.1.1 Capability 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 is shown below. typedef struct _NDIS_TASK_IPSEC { struct { ULONG AH_ESP_COMBINED; ULONG TRANSPORT_TUNNEL_COMBINED; ULONG V4_OPTIONS; ULONG RESERVED; } Supported;

struct { ULONG MD5:1; ULONG SHA_1:1; ULONG Transport:1; ULONG Tunnel:1; ULONG Send:1; ULONG Receive:1; } V4AH;

struct { ULONG DES:1; ULONG RESERVED:1; ULONG TRIPLE_DES:1; ULONG NULL_ESP:1; ULONG Transport:1; ULONG Tunnel:1; ULONG Send:1; ULONG Receive: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. a. 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 supports ESP 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 for any valid combination of IPv4 options for cryptographic 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).

For NDIS 5.1, the miniport must support set operations using OID_TCP_TASK_OFFLOAD with the NDIS_TASK_IPSEC data structure. This allows the host stack to enable a specific subset of the offload target's capabilities. To disable IPsec Task Offload, the host stack can either not set the OID_TCP_TASK_OFFLOAD with the NDIS_TASK_IPSEC data structure, or perform a set operation with all capabilities turned off. Similarly the host stack can change the currently used offload capabilities by performing a set operation which enables or disables the appropriate bits in the NDIS_TASK_IPSEC structure.

2.1.2 State Storage: Adding State or Initiate Offload IPsec NDIS 5.1 Task Offload requires transfer of a portion of the security association (SA) state to the offload target. Since this state is constant and does not change from packet to packet there is no need to keep the offload target and the host stack synchronized with respect to the offloaded state. The offload target must be willing to store the following information on the offload target for each offloaded SA. A single offloaded SA can represent up to two extension headers (AH and ESP) that the offload target must apply cryptographic processing. Additionally the ESP header can require both integrity and privacy. The host stack will not offload an SA to the offload target unless the target can support the required operations

WinHEC 2005 Version – May 2, 2005 IPsec Task Offload Roadmap - 10 and the direction as per its capability advertisement. The following represents the SA state that IPsec adds to the offload target using OID_TCP_TASK_IPSEC_ADD_SA. typedef struct _OFFLOAD_IPSEC_ADD_SA { IPAddr SrcAddr; IPMask SrcMask; IPAddr DestAddr; IPMask DestMask; ULONG Protocol; USHORT SrcPort; USHORT DestPort; IPAddr SrcTunnelAddr; IPAddr DestTunnelAddr; USHORT Flags; SHORT NumSAs; OFFLOAD_SECURITY_ASSOCIATION SecAssoc[OFFLOAD_MAX_SAS]; NDIS_HANDLE OffloadHandle; ULONG KeyLen; UCHAR KeyMat[1]; } OFFLOAD_IPSEC_ADD_SA, *POFFLOAD_IPSEC_ADD_SA; Information about this structure is as follows: 1. SrcAddr, SrcMask, DestMask, Protocol, SrcPort, DestPort , SrcTunnelAddr and DestTunnelAddr are added purely for diagnostic purposes and are actually not used by the offload target in packet processing or host stack interaction. 2. The Flags field identifies the SA as inbound or outbound. Inbound and outbound SAs are separately offloaded, although typically both traffic directions have an SA. 3. NumSAs identifies the number of extension headers required (ESP and/or AH). It represents the size of array SecAssoc. 4. SecAssoc is an array of up to two elements. The information about each extension header is ordered in the sequence that the offload target must perform the operations on the packets. Hence if AH and ESP is specified, outbound operation zero is ESP and operation one is AH whereas inbound operation zero is AH and operation one is ESP. The structure used for elements of this array is: typedef struct _OFFLOAD_SECURITY_ASSOCIATION { OFFLOAD_OPERATION_E Operation; SPI_TYPE SPI; OFFLOAD_ALGO_INFO IntegrityAlgo; OFFLOAD_ALGO_INFO ConfAlgo; OFFLOAD_ALGO_INFO Reserved; } OFFLOAD_SECURITY_ASSOCIATION, *POFFLOAD_SECURITY_ASSOCIATION;

a) Operation is either AUTHENTICATE representing AH or ENCRYPT representing ESP. However ESP can required both integrity and confidentiality operations. b) SPI represents the SPI on the extension header in question. For outbound traffic this parameter is not used. For inbound SAs, the offload target must use the combination of SPI and destination IP address to find the correct security association. c) IntegrityAlgo and ConfAlgo fields identify the algorithm to use and its key length.

typedef struct _OFFLOAD_ALGO_INFO { ULONG algoIdentifier; ULONG algoKeylen; ULONG Reserved; } OFFLOAD_ALGO_INFO, *POFFLOAD_ALGO_INFO;

For AH we identify only the IntegrityAlgo info and just set the algorithm identifier for ConfAlgo to OFFLOAD_IPSEC_CONF_NONE. For ESP we can do either integrity or confidentiality or both. If integrity is not in use with ESP the IntegrityAlgo identifier is set to OFFLOAD_IPSEC_INTEGRITY_NONE. 4. Offload handle is the output parameter representing the handle that was allocated by the offload target to represent the offloaded state. The host stack will use this to indicate to an offload target during send processing which offloaded SA should be used. Similarly this is the handle the host stack will reference to remove state from the offload target. 5. Keylen represents the total length of the KeyMat array which is in fact the sum of individual key lengths in the OFFLOAD_ALGO_INFO structures. 6. KeyMat has the concatenated keys at the end of the structure. The keys are concatenated in the order of their extension headers as specified in the SecAssoc structure. When both confidentiality and integrity are in use with ESP, the confidentiality key precedes the integrity key.

2.1.3 State Storage: Removing State or Terminate Offload The host stack can send an OID_TCP_TASK_IPSEC_DELETE_SA to the offload target requesting the termination of offload on the specified SA. The host stack identifies the offloaded SA by means of the offload handle that was returned in the OFFLOAD_IPSEC_ADD_SA structure. typedef struct _OFFLOAD_IPSEC_DELETE_SA { ULONG OffloadHandle; } OFFLOAD_IPSEC_DELETE_SA, *POFFLOAD_IPSEC_DELETE_SA;

2.1.4 Timing Conditions during State Transition The host stack does not need any synchronization with the offload target in terms of the state that’s offloaded since it is all constant state (unchanging). This in turn simplifies timing conditions since the host stack will not offload send packets on an SA until offload completes. Once the NIC has initialized the SA state, it may start to offload receive processing on an offloaded SA before the host stack receives the offload complete indication from the offload target. The host stack can initiate and terminate offload but there is no semantic for upload since the host stack does not need to copy back state from the offload target. If the offload target chooses, it can skip processing any specific receive packet and instead pass it to the host stack (for example, if it is an IP fragment). The host stack will transparently handle it in software. However, as noted previously, if the host stack asks the offload target to process a send packet, the offload target must honor the request. The host stack guarantees that it will not request send packet processing which is incompatible with the capabilities that the NIC previously advertised and the host stack enabled. The offload target must be able to lookup security associations on inbound and outbound packets in the following manner:  For outbound traffic, the offload target can use the offload handle(s) associated with a packet by the host stack to lookup the outbound SA(s) (for example, transport and tunnel SA) to be applied to the packet. This capability is required only if the offload target does send side offload.  For inbound traffic, the offload target can parse incoming packets to locate the ESP and/or AH headers and use the SPI along with the destination IP address to lookup the inbound SA to be applied to the packet. If the offload target supports transport over tunnel for inbound traffic, it must be

able to parse the packet to locate the inner set of transport headers and lookup their corresponding offloaded SA. This capability is required only if the offload target does receive side offload.  It is highly recommended that an offload target should be inbound/outbound symmetric with respect to its advertised capabilities because Windows will typically negotiate symmetric SAs. From a deployment perspective, this also makes it easier for a network administrator to deploy an IPsec NDIS 5.1 offload NIC.

2.1.5 Interpreting NDIS Packet Out of Band Data for NDIS 5.1 Task Offload The following is the IPsec out of band data associated with each NDIS packet on sends and receives. The Transmit structure is valid for outbound packets and is set by the host stack. The Receive structure is valid for inbound packets and is set by the offload target. typedef struct _NDIS_IPSEC_PACKET_INFO { union { struct { NDIS_HANDLE OffloadHandle; NDIS_HANDLE NextOffloadHandle; } Transmit;

struct { ULONG SA_DELETE_REQ:1; ULONG CRYPTOGRAPHIC_DONE:1; ULONG NEXT_CRYPTOGRAPHIC_DONE:1; ULONG CryptoStatus; } Receive; }; } NDIS_IPSEC_PACKET_INFO, *PNDIS_IPSEC_PACKET_INFO;

For outbound traffic, the OffloadHandle field refers to the offload target’s handle to an offloaded transport mode SA. If NextOffloadHandle is valid, it refers to the offload target’s handle for an offloaded tunnel mode SA to be applied to the packet. If the offload target supports transport over tunnel offload and if both the SAs are offloaded then both member variables can be set. For inbound traffic, the offload target must indicate CRYPTOGRAPHIC_DONE to IPsec on a packet for which it has applied an offloaded SA. NEXT_CRYPTOGRAPHIC_DONE is set only if the offload target performed both tunnel and transport mode processing on the same packet. Note that this aspect differs on send versus receives. On sends NextOffloadHandle is always set to offload a tunnel SA irrespective of whether we do transport over tunnel or not. However for inbound the NEXT_CRYPTOGRAPHIC_DONE flag is set only when transport over tunnel is done. Thus NEXT_CRYPTOGRAPHIC_DONE is looked at by IPsec only for de-tunneled packets.

2.1.6 Additional Packet Processing Requirements  The offload target must be able to locate the offset into the packet to start cryptographic processing (the exact location depends on the specific operation to perform and the algorithm in use). It should be able to determine how much to encrypt/decrypt or hash. If it supports integrity calculation offload then for sends it must insert the hash in the appropriate AH or ESP fields of the outgoing packet. Similarly for inbound traffic it should be able to validate the hash by hashing over the packet and comparing the result with the computed hash.  If the offload target supports outbound ESP offload for DES or triple DES, the offload target must be able to generate initialization vectors on a per outbound packet basis as required by the DES and triple DES algorithms.

2.2 Other Features The previously described capability advertisement allows the offload target to select the forms of offload it supports. Hence as described earlier the offload target can: 1. For each IPsec extension header type (such as AH and ESP), choose:  Whether it supports processing that header type inbound only or outbound only or both.  Whether it supports transport mode for that header type.  Whether it supports tunnel mode for that header type.  Supported cryptographic algorithms for that header type. 2. In addition, there are other capabilities to advertise:  The offload target can apply AH and ESP processing to the same packet.  It can apply transport and tunnel processing to the same packet.  It can process packets that have IPv4 options.  It can support UDP ESP offload for a specific UDP ESP encapsulation type

2.3 Unsupported Capabilities IPsec NDIS 5.1 Task Offload does not expect an offload target to do any of the following:  Offload process IP fragments on the send or on the receive paths. Hence on the send if a packet is to be fragmented by the host stack, then the stack will not ask the offload target to offload the cryptographic processing on that packet and will instead perform the operation in software.  Offload process IP version 6 (IPv6) packets. The stack will not offload IPv6 SAs over the NDIS 5.1 IPsec Task Offload interface because it does not support IPv6 IPsec offload.  IPsec offload integration with LSO or send checksum offload. For sends, the host stack will not ask the NDIS 5.1 offload target to combine send checksum or large send offload (LSO) with IPsec offload. For the receive side, the offload target perform can IPsec offload and receive side checksum offload if it is capable. It just needs to set the appropriate OOB information on the received packets when it indicates them to the host stack.

2.4 Guidance on Implementing NDIS 5.1 IPsec Task Offload Optional Features IPsec NDIS 5.1 does not specify a minimum set of options that the offload target must support. And in fact there are many options which are largely not used in the field or are used infrequently. Given the complexity of implementing IPsec offload, it seems appropriate to provide guidance on which of the optional features most closely matches expected deployment scenarios for Windows. This guidance is also aligned with our Windows Vista support for IPsec NDIS 5.1 Task Offload as described in the following section. Features that are a high priority are:  Transport mode support for ESP NULL with SHA1 authentication.  Transport mode support for ESP triple DES with SHA1 authentication.  Transport mode support for UDP ESP (UDP encapsulated transport).  Support symmetric capabilities for send and receive options - regardless of the options supported.  Support transport mode UDP ESP offload. Additionally, if more features are implemented, the following recommendations may be leveraged:  Support authentication algorithms symmetrically for AH and ESP if AH offload is supported.

The following features are lower priority in terms of Windows deployment scenarios. IHVs may implement them depending upon the markets they intend to address with their offload target:  Transport mode support for DES and MD5 with ESP.  Transport mode support for SHA1 and MD5 with AH. Note that support for AH introduces complexities in terms of parsing IPv4 options. If an offload card supports just ESP offload it can indicate support for IPv4 Options without realizing significant additional design complexity.  Support for IPv4 options. The following features are deprecated on Windows Vista NDIS 5.1 and IHVs should build these into their hardware for Windows Server 2003 at their own discretion:  Support for some or all options in tunnel mode.  Support for transport over tunnel offload. 3 Future IPsec Task Offload

3.1 Windows Vista Support for NDIS 5.1 IPsec Task Offload It is planned that the Windows Vista release will support binary compatibility for NDIS 5.1 IPsec Task Offload miniport drivers. This means that an existing NDIS 5.1 miniport driver binary will continue to work as is on Windows Vista. However, it is expected that the Windows Vista IPsec host stack will not support tunnel mode task offload and transport over tunnel mode task offload. Thus support on Windows Vista may utilize a subset of the total capabilities of the NDIS 5.1 offload target.

3.2 NDIS 5.1 IPsec Offload Functionality within NDIS 6.0 For Windows Vista, the IPsec NDIS 5.1 functionality is mapped to the new NDIS 6.0 interface. Thus both an NDIS 5.1 IPsec Task Offload miniport and an NDIS 6.0 IPsec Task Offload miniport with NDIS 5.1 features are supported. If an IPsec offload miniport is compiled for NDIS 6.0 (exposing the same IPsec feature set, but changing from transferring data using NDIS_PACKETS to NET_BUFFER_LIST, among other things), it inherits some of the capabilities introduced in the overall NDIS 6.0 architecture. The following list details the design changes being made in this regard:  NDIS 6.0 IPsec Task Offload does use a set capability operation after capability advertisement. If the host stack is configured or for other reasons chooses not to leverage a certain capability on the offload target it will simply not make a request for that type of offload. For example, if the system administrator disables DES in the IPsec user interface, the host stack will not offload any SAs that require the DES operation. Also it will terminate offload on all such offloaded SAs.  The miniport will be able to change its advertised capabilities at run-time and the host stack will respond to the new capabilities with initiate and terminate offloads as appropriate.  Offload capability must be supported symmetrically on send and receive side. Unless the miniport advertises the same capabilities for send and receive, the host stack will not offload an SA using the capability.  Tunnel mode offload will not be supported on NDIS 6.0 IPsec Task Offload. Thus even if the miniport advertises the capability, it will not be used.  UDP ESP offload does not require parser entry offload. The only encapsulation type is the port 4500 UDP encapsulated transport type and will be on by default if the offload card supports UDP ESP offload. Note: From an API perspective NDIS 6.0 IPsec Task Offload is a new API with new structures that the offload target’s miniport driver must work with if it is an NDIS 6.0 miniport exposing NDIS 5.1 IPsec task offload capabilities.

3.3 Support for Teaming IPsec Offload Cards with NDIS 6.0 Teaming miniport drivers can be developed to combine together several NDIS 6.0 IPsec Task Offload cards into a single virtual NIC for the host stack. Such a teaming miniport will work in the following manner: 1. It would report to the host stack the set of common capabilities that all offload cards that it teams support. 2. IPsec Task Offload requests are stateful. When a teaming miniport directs an offload request to a specific offload card it must make sure all subsequent per packet send offload requests that reference the IPsec offload handle returned by the offload card are directed to it. As such it needs to maintain a mapping of offload handles to specific offload cards. 3. The teaming miniport must similarly direct delete SA requests referencing the offload handle to the same offload card. 4. The teaming miniport must provide some kind of a collision avoidance scheme which prevents offload handles returned from different offload cards from colliding. It may have to maintain some kind of internal mapping table to achieve this (meaning it would translate a teaming miniport offload handle to a offload NIC identifier and an offload handle which that NIC understands). 5. As offload cards are added and removed, potentially changing the advertised capabilities of the teamed offload target, the teaming miniport would use the new NDIS 6.0 capability to force a renegotiation of offload capabilities. After the renegotiation, the host stack would respond with appropriate initiate and terminate offload requests to remove SAs that require capabilities no longer supported and add SAs which require capabilities which are now supported. 6. If an offload card fails, the teaming miniport must request the host stack to terminate offload on each SA that is offloaded to that specific offload card.

Note that the above analysis does not address receive processing. The key issue is how to ensure that the algorithm for interface selection for SA offload matches the interface that is expected to receive the incoming datagrams. The specification of this algorithm is left to IHV innovation.

3.4 Future Extensions to IPsec Task Offload This section outlines future thinking for new capabilities to include in IPsec Task Offload. It is presented here to help provide IHVs with guidance for future implementations.

3.4.1 IPv6 Task Offload Support At a future time IPsec Task Offload is expected to add IPv6 IPsec offload support. Hence in the capability advertisement the offload target will indicate support for various algorithms with IPv6 and will also indicate whether it can handle parsing of extension headers. If an offload target indicates support for IPv6 IPsec Task Offload, then the host stack can offload IPv6 SAs over the offload target.

3.4.2 Support for New Cryptographic Algorithms NDIS 6.0 IPsec Task Offload is expected to add support for the following algorithms:  AES 128 bit CBC encryption (RFC 3602)  AES 192 bit CBC encryption (RFC 3602)  AES 256 bit CBC encryption (RFC 3602) In addition the following algorithms are currently IETF Internet Drafts (available at www.ietf.org) and are under consideration for inclusion in the offload capability advertisement.  SHA 256 authentication (draft-ietf-ipsec-ciph-sha-256-01.txt)  SHA 384 authentication ("Specifications for the Secure Hash Standard," Draft FIPS 180-2, May 2001. http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf. "Descriptions of SHA-256, SHA-384, and SHA-512." http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf.)

AES CCM authentication and encryption (draft-ietf-ipsec-ciph-aes-ccm-05.txt)

WinHEC 2005 Version – May 2, 2005