Pre-draft: SEAL as an IPv6 extension header (was: Fragmentation-related Security issues)

["Templin, Fred L" <[e-mail]>]

Please see below for a pre-draft for using the Subnetwork
Encapsulation and Adaptation Layer (SEAL) as an IPv6 extension
header. This extension header can be used by the source to
defeat off-path spoofing of ICMPv6 error messages. When the
source and destination share a secret symmetric key used for
calculating the integrity check vector, the extension header
also provides the destination with data origin authentication
and anti-replay.

Please send any comments to the list,

Fred
[e-mail]

--- cut here ---




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


                     The SEAL IPv6 Extension Header
                       draft-templin-sealopt.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
   (inserted by the source) that covers the leading 128 bytes of the
   payload beginning with the SEAL header itself.  The source can
   thereafter use the digital signature to verify that any ICMPv6
   mesages 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 13, 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 13, 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 Extension Header  . . . . . . . . . . . . . . . . . . 3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
































Templin                   Expires July 13, 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.  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 (inserted by the
   source) that covers the leading 128 bytes of the payload beginning
   with the SEAL header itself.  The source can thereafter use the
   digital signature to verify that any ICMPv6 mesages received actually
   came from a router on the path.


2.  SEAL IPv6 Extension Header

   The SEAL IPv6 extension header is formatted as follows:

       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)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Identification                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Integrity Check Vector (ICV)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Reserved                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: SEAL IPv6 Extension Header Format

   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 2.

   SEAL Header (16)
      a 16-bit field that controls the operation of SEAL.  Format TBD.





Templin                   Expires July 13, 2012                 [Page 3]

Internet-Draft                    SEAL                      January 2012


   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.

   Integrity Check Vector (ICV) (32)
      a 32-bit header integrity check value.  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 integrity check.

   The IPv6 source inserts a SEAL extension header whenever it wants to
   ensure that any resulting ICMPv6 error messages [RFC4443] 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 ICV
   value is correct based on a secret hashing algorithm of its choosing.
   The source should choose a hashing algorithm that would make it
   virtually impossible 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
   wre delivered by an on-path router and not an off-path attacker.  The
   header may also be used fro 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

   [I-D.templin-intarea-seal]
              Templin, F., "The Subnetwork Encapsulation and Adaptation



Templin                   Expires July 13, 2012                 [Page 4]

Internet-Draft                    SEAL                      January 2012


              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.


Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: [e-mail]


























Templin                   Expires July 13, 2012                 [Page 5]