ospfd/OSPF-ALIGNMENT.txt

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