ospfd/OSPF-ALIGNMENT.txt

   1 $Id: OSPF-ALIGNMENT.txt,v 1.1 2004/11/17 17:59:52 gdt Exp $
   2
   3 Greg Troxel <gdt@ir.bbn.com>
   4 2004-11-17
   5
   6 The OSPF specification (RFC2328) and the OSPF Opaque LSA specification
   7 (RFC2370) are ambiguous about LSAs whose data section is not an
   8 integral multiple of 4 octets.  This note examines the issue and
   9 proposes clarifications to ensure interoperability.
  10
  11 RFC2328 does not specify that LSA lengths be a multiple of 4.
  12 It does not require that LSAs in update packets be aligned.
  13 However, all structures defined by RFC2328 are multiples of 4, and
  14 thus update packets with those structures must be aligned.
  15 LSA length is defined in Appendix A.4 as
  16
  17     length
  18         The length in bytes of the LSA.  This includes the 20 byte LSA
  19         header.
  20
  21 RFC2370 defines Opaque LSAs, which are intended to contain arbitrary
  22 data:
  23
  24    This memo defines enhancements to the OSPF protocol to support a new
  25    class of link-state advertisements (LSA) called Opaque LSAs.  Opaque
  26    LSAs provide a generalized mechanism to allow for the future
  27    extensibility of OSPF. Opaque LSAs consist of a standard LSA header
  28    followed by application-specific information.  The information field
  29    may be used directly by OSPF or by other applications.  Standard OSPF
  30    link-state database flooding mechanisms are used to distribute Opaque
  31    LSAs to all or some limited portion of the OSPF topology.
  32
  33
  34 Later, 2370 says:
  35
  36    Opaque LSAs contain some number of octets (of application-specific
  37    data) padded to 32-bit alignment.
  38
  39 This can be interpreted in several ways:
  40
  41 A) The payload may be any number of octets, and the length field
  42 reflects the payload length (e.g. length 23 for 3 octets of payload),
  43 but there are padding octets following the LSA in packets, so that the
  44 next LSA starts on a 4-octet boundary.  (This approach is common in
  45 the BSD user/kernel interface.)
  46
  47 B) The payload must be a multiple of 4 octets, so that the length is a
  48 multiple of 4 octets.  This corresponds to an implementation that
  49 treats an Opaque LSA publish request that is not a multiple of 4
  50 octets as an error.
  51
  52 C) The payload can be any number of octets, but padding is added and
  53 included in the length field.  This interpretation corresponds to an
  54 OSPF implementation that accepts a publish request for an Opaque LSA
  55 that is not a multiple of 4 octets.  This interpretation is
  56 nonsensical, because it claims to represent arbitrary lengths, but
  57 does not actually do so --- the receiver cannot distinguish padding
  58 from supplied data.
  59
  60 D) Accept according to A, and transmit according to B.
  61
  62 Option A arguably violates RFC 2328, which doesn't say anything about
  63 adding padding (A.3.5 shows a diagram of adjacent LSAs which are shown
  64 as all multiples of 4).  This option is thus likely to lead to a lack
  65 of interoperability.
  66
  67 Option B restricts what data can be represented as an Opaque LSA, but
  68 probably not in a serious way.  It is likely to lead to
  69 interoperability in that the complex case of non-multiple-of-4 lengths
  70 will not arise.
  71
  72 However, an implementation that follows A and emits an LSA with
  73 payload length not a multiple of 4 will not interoperate with an
  74 Option B implementation.
  75
  76 Given that all known and documented uses of Opaque LSAs seem to be
  77 multiples of 4 octets, we choose Option B as the clarification.
  78
  79 CLARIFYING TEXT
  80
  81 In RFC2328:
  82
  83 In section A.4, add a second sentence about length:
  84
  85     length
  86         The length in bytes of the LSA.  This includes the 20 byte LSA
  87         header.  The length must be an integral multiple of 4 bytes.
  88
  89 Add to the list in Section 13:
  90
  91     Verify that the length of the LSA is a multiple of 4 bytes.  If
  92     not, discard the entire Link State Update Packet.
  93
  94 In RFC2380:
  95
  96 Change text:
  97
  98    Opaque LSAs contain some number of octets (of application-specific
  99    data) padded to 32-bit alignment.
 100
 101 to:
 102
 103    Opaque LSAs contain some a number of octets (of
 104    application-specific data).  The number of octets must be a
 105    multiple of four.
 106
 107
 108 HOW THIS ISSUE AROSE
 109
 110 At BBN, we use Opaque LSAs to exchange data among routers; the format
 111 of the data is naturally aligned to 4 bytes, and thus does not raise
 112 this issue.  We created a test program to publish Opaque data via IPC
 113 to the OSPF daemon (quagga), and this program accepts strings on the
 114 command line to publish.  We then used this test program to publish
 115 software version strings.  Quagga's ospfd then crashed on a
 116 NetBSD/sparc64 machine with an alignment fault, because the odd-length
 117 LSAs were marshalled into a link-state update packet with no padding.
 118 While this behavior was a clear violation of RFC2380, it was not clear
 119 how to remedy the problem.