]>
Commit | Line | Data |
---|---|---|
996ac2dc | 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. |