Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational January 10, 2012
Expires: July 11, 2012

The SEAL IPv6 Extension Header
draft-templin-sealopt-00.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 extension header. Namely, the SEAL header when used as an extension header contains a digital signature or nonce inserted by the source. The source can thereafter use the digital signature/nonce to verify that any ICMPv6 messages received actually came from a router on the path.

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 11, 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

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. SEAL also supports a transport mode of operation, where the encapsulated payload corresponds to an ordinary transport layer protocol payload. It is in essence a close analogy of the GRE encapsulation format [RFC1701].

However, SEAL can also provide benefit when used as an IPv6 extension header [RFC2460]. Namely, the SEAL header when used as an IPv6 extension header contains a digital signature or nonce inserted by the source. The source can thereafter use the digital signature/nonce to verify that any ICMPv6 messages [RFC4443] received actually came from a router on the path.

2. SEAL IPv6 Extension Header

The SEAL IPv6 extension header can be inserted in either a "short form" or a "long form". In short form, the header includes a signature/nonce chosen by the source. In long form the header also includes an Identification value used for anti-replay sequencing. The short form is formatted as shown in Figure 1:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |Hdr Ext Len = 1|    SEAL Header (format TBD)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Signature / Nonce                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: SEAL IPv6 Extension Header Format - Short Form

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |Hdr Ext Len = 2|    SEAL Header (format TBD)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Signature/Nonce                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Identification                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Reserved                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: SEAL IPv6 Extension Header Format - Long Form

Figure 2

Next Header (8)
an 8-bit field that encodes the next header Internet Protocol number the same as for the IPv4 protocol and IPv6 next header fields.
Next Header Length (8)
an 8-bit length of the extension header measured in 8-byte words. Set to 1 in short format, and set to 2 in long format.
SEAL Header (16)

a 16-bit field that controls the operation of SEAL. Format TBD.
Signature/Nonce

a 32-bit signature or nonce. When used as a digital signature, covers the leading 128 bytes of the packet beginning with the SEAL extension header (or up to the end of the packet). The value 128 is chosen so that at least the SEAL header as well as the inner packet network and transport layer headers are covered by the signature.

The long form is formatted as shown in

Identification (32)

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

a 32-bit reserved field.

The IPv6 source inserts a SEAL extension header 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/nonce value is correct. When a signature is used, the source calculates the signature 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.

3. IANA Considerations

The IANA is instructed to allocate an IPv6 extension header for SEAL.

4. Security Considerations

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

5. Acknowledgments

TBD.

6. References

6.1. Normative References

[RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[I-D.templin-intarea-seal] Templin, F, "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Internet-Draft draft-templin-intarea-seal-39, November 2011.
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

6.2. Informative References

[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.

Author's Address

Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA EMail: fltemplin@acm.org