| 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
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.
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 (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.
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.
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
The long form is formatted as shown in
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.
The IANA is instructed to allocate an IPv6 extension header for SEAL.
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.
TBD.
| [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. |
| [RFC1701] | Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. |