The SEAL IPv6 Destination Option
draft-templin-sealopt-01.txt

Abstract

The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a mid-layer header designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the inner payload corresponds to an ordinary transport layer payload. However, SEAL can also provide benefit when used as an IPv6 destination option that contains a digital signature inserted by the source. The source can thereafter use the signature to verify that any ICMPv6 messages received actually came from a router on the path, while destinations that share a secret key with the source can verify the signature to ensure data origin authentication.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 14, 2012.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. SEAL IPv6 Destination Option
• 3. IANA Considerations
• 4. Security Considerations
• 5. Acknowledgments
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

1. Introduction

The Subnetwork Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal] provides a mid-layer encapsulation designed for the encapsulation of an inner network layer packet within outer network layer headers, i.e., in a very similar manner as for GRE [RFC1701] and IPsec AH [RFC4302]. SEAL also supports a transport mode of operation, where the encapsulated payload corresponds to an ordinary transport layer protocol payload.

However, SEAL can also provide benefit when used as an IPv6 destination option [RFC2460] that contains a digital signature inserted by the source. The source can thereafter use the signature to verify that any ICMPv6 messages [RFC4443] received actually came from a router on the path, while destinations that share a secret key with the source can verify the signature to ensure data origin authentication.

2. SEAL IPv6 Destination Option

The SEAL IPv6 destination option can be inserted in either a "short form" or a "long form". In short form, the option includes a digital signature. In long form the option also includes an Identification value useful for anti-replay sequencing. The short form is formatted as shown in Figure 1:

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  Option Type  | Opt Data Len=4|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Signature                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Type (8)

an 8-bit field that encodes the destination option code for SEAL, with the value '00' in the high-order two bits.

Option Data Length (8)

an 8-bit length of the option data field measured in octets. Set to 4 in short format, and set to 8 in long format.

Digital Signature (32)

a 32-bit digital signature. When a cryptographic signature is used, covers the leading 128 bytes of the packet beginning with the destination option header (or up to the end of the packet). The value 128 is chosen so that at least the IPv6 extension headers and the leading portion of the inner packet are covered by the signature.

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  Option Type  | Opt Data Len=8|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Signature                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Identification                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The long form is formatted as shown in Figure 2

Identification (32)

a 32-bit per-packet identification field. Set to a monotonically-incrementing 32-bit value for each packet transmitted, beginning with 0.

The IPv6 source inserts a SEAL destination option when it needs to ensure that any resulting ICMPv6 error messages came from a router on the path and not from an off-path attacker. When the source receives an ICMPv6 error message, it verifies that the signature is correct. When a cryptographic signature is used, the source calculates the signature over the leading 128 bytes of the packet based on a secret hashing algorithm of its choosing. The source should choose a hashing algorithm that would make it extremely difficult for an off-path attacker to guess.

The destination may or may not recognize the SEAL destination option. If the destination does not recognize the option, it skips the option and processes the next option. If the destination recognizes the option (and if the option contains a cryptographic signature), the destination may either verify or ignore the signature according to its configuration. If the destination is configured to verify the signature, then it should accept the packet if the signature is correct and discard the packet if the signature is incorrect.

3. IANA Considerations

The IANA is instructed to allocate an IPv6 destination option for SEAL, with the value '00' in the high-order two bits.

4. Security Considerations

The source can use the SEAL destination option to verify that ICMPv6 messages were delivered by an on-path router and not an off-path attacker. The signature may also be useful for other authenticating purposes, e.g., if the destination shares a secret key with the source. The packet identification field may also be useful for anti-replay sequencing.

5. Acknowledgments

This work was motivated by recent discussions on the 6man mailing list, and build on earlier investigations with SEAL. Sreenatha Setty provided valuable comments that helped clarify aspects of the document.

6. References

6.1. Normative References

6.2. Informative References

Author's Address