[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Open Shortest Path First IGP                                    P. Jakma
Working Group                                       DCS, Uni. of Glasgow
Internet-Draft                                                 M. Bhatia
Updates: 2328 (if approved)                               Alcatel-Lucent
Intended status: Standards Track                        October 13, 2010
Expires: April 16, 2011


         Stronger, Automatic Integrity Checks for OSPF Packets
                     draft-jakma-ospf-integrity-00

Abstract

   This document describes an extension to OSPFv2 and OSPFv3 to allow a
   stronger integrity check to be applied to the protocol packets, than
   the default OSPF checksum, which is known to be weak.

   The extension allows OSPF speakers to negotiate the use of a CRC
   integrity check, as a new psuedo-authentication type.

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 April 16, 2011.

Copyright Notice

   Copyright (c) 2010 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



Jakma & Bhatia           Expires April 16, 2011                 [Page 1]


Internet-Draft            OSPF Integrity Checks             October 2010


   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.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Stronger Checksum mechanism for OSPFv2  . . . . . . . . . . . . 3
     3.1.  Null Authentication Data  . . . . . . . . . . . . . . . . . 4
   4.  Stronger Checksum mechanism for OSPFv3  . . . . . . . . . . . . 4
     4.1.  EC-Bit in Options Field . . . . . . . . . . . . . . . . . . 4
     4.2.  Extended Checksum Data Block  . . . . . . . . . . . . . . . 5
   5.  Generation  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Verification  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Stronger Integrity Algorithm Types  . . . . . . . . . . . . . . 7
     7.1.  CRC32 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.2.  MD5-Digest  . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8


























Jakma & Bhatia           Expires April 16, 2011                 [Page 2]


Internet-Draft            OSPF Integrity Checks             October 2010


1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Introduction

   The integrity of Open Shortest Path First versions 2
   (OSPFv2)[RFC2328] and 3 (OSPFv3)[RFC5340] packets is protected either
   through the standard internet protocol checksum, or through some
   cryptographic integrity scheme within OSPF, or, more rarely, through
   IPSec.  This provides a check against errors that can not be caught
   by the link-layer integrity checks, e.g. errors in lower layers of
   the software stack or in hardware of the host.

   The internet protocol checksum is known to have
   weaknesses[partridge].  In particular it can not detect re-ordered
   words and certain patterns of bit flips.  If stronger integrity
   checks are desired, the only option is to use cryptographic HMACs,
   either with MD5 (all conforming [RFC2328] implementations) or, if
   supported, the stronger algorithms specified by [RFC5709].  There are
   some disadvantages though to using the existing support for
   cryptographic HMACs purely for integrity checking.  The algorithms
   require more computation, which may be noticable on less powerful
   and/or energy-sensitive platforms.  Additionally, the need to
   configure key material is an additional administrative burden.

   This documents extends OSPF to allow for the automatic and backward
   compatible use of stronger integrity checks.  Backward compatibility
   implies the default null authentication type must be used and
   extended.


3.  Stronger Checksum mechanism for OSPFv2

   The null authentication mode of OSPFv2 is extended to make use of the
   authentication data field of the OSPFv2 packet header.  Where
   previously this field was ignored for null authentication, now an
   OPTIONAL "Null Authentication Data" structure is recognised there.

   Implementations MUST provide a means to disable this extension, in
   case there are non-conforming RFC2328 implementations.
   Implementations MAY wish to generate a CRC32 checksum by default via
   this extension, and SHOULD attempt to verify any received, regardless
   of whether they generate the same or not.




Jakma & Bhatia           Expires April 16, 2011                 [Page 3]


Internet-Draft            OSPF Integrity Checks             October 2010


3.1.  Null Authentication Data

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Checksum Type        |      0xA5     |  Data Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Ignored                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 1: Null Authentication Data

   The authentication data field in the standard OSPFv2 packet header is
   redefined as shown above, when null authentication is used.  The new
   field definitions are as follows:

   Checksum Type:
       This field indicates the new checksum algorithm that the routers
       must use and is described in detail in the later sections.
   Magic:
       This field is set to 0xA5.  This magic, in combination with the
       OSPF and IP packet lengths, signals the use of this extension.
   Data Length:
       The length in 4-octet words of the extended checksum data block
       appended to the OSPFv2 packet.


4.  Stronger Checksum mechanism for OSPFv3

   OSPFv3 uses IPSec for protection and does not carry any
   authentication information in its headers.  Thus it is not possible
   to overload the Null Authentication type as was done in case of
   OSPFv2.

4.1.  EC-Bit in Options Field

   A new EC-bit (EC stands for Extended Checksum) is introduced into the
   OSPFv3 Options field.  Routers MUST set the EC-bit in all OSPFv3
   packets to indicate that the packet is carrying the new extended
   checksum data.

          0                   1                         2
           0 1 2 3 4 5 6 7 8 9 0 1 2 3  4  5 6 7  8  9  0  1  2  3
           +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+--+--+--+--+--+
           | | | | | | | | | | | | | |EC|L|AF|*|*|DC| R| N|MC| E|V6|
           +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+--+--+--+--+--+




Jakma & Bhatia           Expires April 16, 2011                 [Page 4]


Internet-Draft            OSPF Integrity Checks             October 2010


                      Figure 2: OSPFv3 Options Field

4.2.  Extended Checksum Data Block

   The data block for carrying extended checksum in OSPFv3 is formatted
   as described below.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Checksum Type       |      0xA5     |   Data Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~              Extended Checksum Data Block                     ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 3: OSPFv3 Options Field

   The Checksum Type is of two octets and indicates the new checksum
   algorithm that the routers must use.  This is described in detail in
   the later sections.  The next field is a reserved magic field set to
   0xA5.  The Data length field is of two octets and carries the size of
   the entire extended checksum data block that has been appended to the
   OSPFv3 payload, specified in units of 4-octet words.  The Extended
   Checksum Data Block carries the checksum data that the recievers will
   use to verify the integrity of the OSPFv3 protocol payload.


5.  Generation

   The same steps are followed as for D.4.1 of [RFC2328].  Additionally,
   a 2nd integrity check algorithm is also computed over the packet
   data, with at least the same amount of zero padding, to produce an
   "extended checksum", which is appended to the OSPFv2 packet.  Its is
   size accounted for in the Null Authentication Data "data length"
   field and in the IP length, but not in the OSPFv2 packet header, in a
   similar fashion to the standard OSPFv2 cryptographic authentication
   mechanism.

   The "Checksum Type" and "Data Length" fields are set to the
   appropriate values for the 2nd integrity check algorithm.

   In case of OSPFv3 the entire extended checksum block is appended to
   the OSPFv3 packet, with its size accounted for in the IPv6 payload
   length, but not in the OSPFv3 packet header.




Jakma & Bhatia           Expires April 16, 2011                 [Page 5]


Internet-Draft            OSPF Integrity Checks             October 2010


   Implementations MUST append the extended checksum data, that is
   carried as part of the OSPF protocol payload, before the link local
   signaling (LLS) [RFC5613] block (if it exists).

     +---------------------+ --              --  +---------------------+
     | IP Header           | ^               ^   | IPv6 Header         |
     | Length = HL+X+Y+Z   | | Header Length |   | Length = HL+X+Y+Z   |
     |                     | v               v   |                     |
     +---------------------+ --              --  +---------------------+
     | OSPF Header         | ^               ^   | OSPFv3 Header       |
     | Length = X          | |               |   | Length = X          |
     |                     | |               |   |                     |
     | NULL Authentication | |               |   |                     |
     | Length = Y          | |               |   |                     |
     |.....................| | X             | X |.....................|
     |                     | |               |   |                     |
     | OSPFv2 Data         | |               |   | OSPFv3 Data         |
     |                     | v               v   |                     |
     +---------------------+ --              --  +---------------------+
     |                     | ^               ^   |                     |
     | Extended Checksum   | | Y             | Y |  Extended Checksum  |
     |                     | v               v   |                     |
     +---------------------+ --              --  +---------------------+
     |                     | ^               ^   |                     |
     |  LLS Data           | | Z             | Z |  LLS Data           |
     |                     | v               v   |                     |
     +---------------------+ --              --  +---------------------+
    `

          Figure 4: Extended Checksum Block in OSPFv2 and OSPFv3


6.  Verification

   The packet data is padded out, as required by [RFC2328].

   In case of OSPFv2, the Null Authentication Data "0xA5" magic field is
   examined.  If it does not match, then verification proceeds as per
   D.5.1 of [RFC2328].  If it matches, then the IP length in the header
   MUST be verified.  An incoming packet will only contain a valid
   extended checksum if the length in the IP header = length in OSPF
   header + "data length" in the NULL Authentication header + data
   length in the LLS [RFC5613] block (if it exists).  Implementations
   can trivially determine if an LLS block is being carried by
   inspecting the "L" bit in the OSPF Options field in the HELLOs and
   DDs.  Implementations MUST proceed with regular checksum if these
   numbers dont match.  If they do then the IP checksum field of the
   OSPF header MUST be ignored.  Instead the stronger integrity



Jakma & Bhatia           Expires April 16, 2011                 [Page 6]


Internet-Draft            OSPF Integrity Checks             October 2010


   algorithm specified by the "Checksum Type" field is used, and
   verified against the corresponding checksum.  The packet MUST be
   discarded if the computed checksum does not match with what's carried
   in the OSPF packet.

   In case of OSPFv3, the presence of the EC-bit in the OSPFv3 Options
   field will indicate that a new checksum algorithm is being used.
   Routers MUST parse the packet till the end of the OSPFv3 payload till
   it reaches the start of the extended checksum data block.  The
   processing that follows next is similar to the way its done for
   OSPFv2 as explained earlier.


7.  Stronger Integrity Algorithm Types

7.1.  CRC32

   The CRC32 algorithm, as used with IEEE 802.3 and defined by [hammond]
   is used to calculate its 4-byte digest.  The length set in the Null
   Authentication Data thus will be 1.

7.2.  MD5-Digest

   The MD5 algorithm, as per 5ref17 of [RFC2328] is used in plain digest
   mode (i.e. solely over the data, unlike the HMAC mode used by
   cryptographic authentication) to calculate its 8-byte digest.  The
   length set in the Null Authentication Data thus will be 2.


8.  IANA Considerations

   OSPFv2 Null Authentication Checksum Types are maintained by the IANA.
   Extensions to OSPFv2 that require a new Checksum Type must be
   reviewed by a designated expert from the routing area.

   This document assigns OSPF Null Authentication Checksum Types 1 and
   2, for CRC32 and MD5-Digest respectively.

   IANA is also requested to allocate EC-bit in the OSPFv3 "Options
   Registry"


9.  Security Considerations

   This extension does not raise any new security concerns.  It only is
   used where operators have chosen not to configure cryptographic
   security mechanisms.




Jakma & Bhatia           Expires April 16, 2011                 [Page 7]


Internet-Draft            OSPF Integrity Checks             October 2010


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

   [RFC5709]  Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
              Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
              Authentication", RFC 5709, October 2009.

   [hammond]  Hammond, J., Brown, J., and S. Lui, "Development of a
              Transmission Error Model and an Error Control Model",
              Technical Report Georgia Institute of Technology,
              May 1975, <http://handle.dtic.mil/100.2/ADA013939>.

10.2.  Informative References

   [RFC5613]  Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
              Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.

   [partridge]
              Stone, J., Greenwald, M., Partridge, C., and J. Hughes,
              "Performance of checksums and CRC's over real data", IEEE/
              ACM Trans. Netw. vol 6, num 5, pages 529-543, 1998,
              <http://dx.doi.org/10.1109/90.731187>.


Authors' Addresses

   Paul Jakma
   School of Computing Science, University of Glasgow
   Lilybank Gardens
   Glasgow  G12 8QQ
   Scotland

   Email: paulj@dcs.gla.ac.uk









Jakma & Bhatia           Expires April 16, 2011                 [Page 8]


Internet-Draft            OSPF Integrity Checks             October 2010


   Manav Bhatia
   Alcatel-Lucent
   Bangalore,
   India

   Phone:
   Email: manav.bhatia@alcatel-lucent.com












































Jakma & Bhatia           Expires April 16, 2011                 [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/