Internet DRAFT - draft-templin-sealopt
draft-templin-sealopt
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational January 13, 2012
Expires: July 16, 2012
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 16, 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
Templin Expires July 16, 2012 [Page 1]
Internet-Draft SEAL January 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SEAL IPv6 Destination Option . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Templin Expires July 16, 2012 [Page 2]
Internet-Draft SEAL January 2012
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SEAL IPv6 Destination Option Format - Short Form
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
Templin Expires July 16, 2012 [Page 3]
Internet-Draft SEAL January 2012
the signature.
The long form is formatted as shown in Figure 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len=8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SEAL IPv6 Destination Option Format - Long Form
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
Templin Expires July 16, 2012 [Page 4]
Internet-Draft SEAL January 2012
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
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-42 (work in
progress), December 2011.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[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.
6.2. Informative References
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
Templin Expires July 16, 2012 [Page 5]
Internet-Draft SEAL January 2012
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires July 16, 2012 [Page 6]
