Subject: alignment/padding rules for Opaque LSAs

From: Greg Troxel <[email-masked]>
Date: Thu, 4 Nov 2004 14:31:06 -0500

I'm one of the maintainers of quagga (http://www.quagga.net), which
includes an OSPF implementation.  At BBN we are using Opaque LSAs for
various things, including publishing software version strings, and
thus we have arbitrary length OLSA payloads.  We encountered alignment
faults with quagga's ospf running under NetBSD/sparc64, and the code
was clearly wrong.  I read the RFCs to try to determine the rules, and
find them ambiguous.  I googled and found very little, so I'm writing
to ask for the group's opinion, and to suggest that the clarification
be included in the next rev of the documents.

The central question is about Opaque LSA payloads that are not
multiples of four octets.  Are they allowed, and if so how are they
handled?

RFC2328 in describing LSAs says:

    length
        The length in bytes of the LSA.  This includes the 20 byte LSA
        header.

All the LSAs are aligned, so what's allowed and how/whether to pad is
a non-issue.

RFC2370, describing opaque LSA data formats, says:

    Opaque LSAs contain some number of octets (of application-specific
    data) padded to 32-bit alignment.

This does not read straightforwardly as 'data in opaque lsas must be
multiple of 4', so I interpret this saying the number of octets of
"application-specific data" may be any value >=0 (up until MTU issues
arise - I'm not worried about that part).

One way to read 'padded' here as saying that the chunk of data that is
the Opaque LSA consists of the LSA header, the opaque data, and then
from 0 to 3 octets of padding, and that the length field covers the
header and the data but not the padding.

Another interpretation is to say that the data is first padded, and
then the length field includes the header, the "original data", and
the pad.  In this second case, there is no way to tell what was
original data and what was pad (since there is no mandatory pad count
field at the end like in IPsec ESP), unless there are internal length
fields in the application-specific data.

While not a wire-protocol issue, a further complication is correct
behavior for on-router interfaces to Opaque LSA publication.  If the
length must be a multiple of 4 (the second way above), should
requests to publish opaque data that is not a multiple of 4 be
rejected as erroneous, or rounded up with padding added?

In reading several descriptions of Opaque LSA contents (TE, graceful
restart), it seems that the TLVs used are internally padded to 4
anyway, so this issue doesn't arise.

    Greg

---

From: Acee Lindem <[email-masked]>
Date: Fri, 5 Nov 2004 11:42:30 -0500

----- Original Message -----
From: "Greg Troxel" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 04, 2004 2:31 PM
Subject: alignment/padding rules for Opaque LSAs

> multiples of four octets.  Are they allowed, and if so how are they

Hi Greg,

TLVs in OSPF opaque LSAs were first introduced for MPLS Traffic
Engineering. From RFC 3630:

2.3.2.  TLV Header

   The LSA payload consists of one or more nested Type/Length/Value
   (TLV) triplets for extensibility.  The format of each TLV is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value...                           |
      .                                                               .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length field defines the length of the value portion in octets
   (thus a TLV with no value portion would have a length of zero).  The
   TLV is padded to four-octet alignment; padding is not included in the
   length field (so a three octet value would have a length of three,
   but the total size of the TLV would be eight octets).  Nested TLVs
   are also 32-bit aligned.  Unrecognized types are ignored.

So far, this description has been sufficient for interoperable
implementations. However, we have had some confusion with
individual TLVs and whether trailing 0's are part of the value (and
included in the length) or padding (and not included).

Hope this helps,
Acee

---

From: Greg Troxel <[email-masked]>
Date: Fri, 5 Nov 2004 12:06:40 -0500

implementations.

Thanks.  I think this is about how to make TLVs be aligned.  The TLV
alignment rules avoid the issue of Opaque LSAs whose payload is not a
multiple of 4.  I'm concerned with the case when e.g. someone wants to
publish a 15-octet value as the Opaque LSA contents.

--
        Greg Troxel <[email-masked]>

---

From: Acee Lindem <[email-masked]>
Date: Fri, 5 Nov 2004 12:20:43 -0500

----- Original Message -----
From: "Greg Troxel" <[email-masked]>
To: "Acee Lindem" <[email-masked]>
Cc: "Mailing List" <[email-masked]>
Sent: Friday, November 05, 2004 12:06 PM
Subject: Re: alignment/padding rules for Opaque LSAs

> publish a 15-octet value as the Opaque LSA contents.

The TLV length field would be 15 but the length of the TLV and it
would be padded to a 4 octet boundary (1 byte of padding).

---

From: Greg Troxel <[email-masked]>
Date: Fri, 5 Nov 2004 13:15:06 -0500

I'm talking about opaque LSA contents which are not TLVs - just
arbitrary data, used for purposes other than the published standards
that use TLVs.  So the contents are truly opaque - no type field, and
no length.

---

From: Sanjai Narain <[email-masked]>
Date: Fri, 5 Nov 2004 12:24:50 -0500

Hi, can you please let me know what is the maximum number of separate OSPF
processes that typical routers support? Thanks. -- Sanjai

---

From: Acee Lindem <[email-masked]>
Date: Fri, 5 Nov 2004 13:57:41 -0500

----- Original Message -----
From: "Greg Troxel" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 05, 2004 1:15 PM
Subject: Re: alignment/padding rules for Opaque LSAs

> that use TLVs.  So the contents are truly opaque - no type field, and

Greg,

Ok - now I understand and the other implementations are correct. You
need to pad the value to 32 bit alignment. From RFC 2370:

A.2 The Opaque LSA

   Opaque LSAs are Type 9, 10 and 11 link-state advertisements.  These
   advertisements may be used directly by OSPF or indirectly by some
   application wishing to distribute information throughout the OSPF
   domain.  The function of the Opaque LSA option is to provide for
   future extensibility of OSPF.

   Opaque LSAs contain some number of octets (of application-specific
   data) padded to 32-bit alignment.  Like any other LSA, the Opaque LSA
   uses the link-state database distribution mechanism for flooding this
   information throughout the topology.  However, the Opaque LSA has a
   flooding scope associated with it so that the scope of flooding may
   be link-local (type 9), area-local (type 10) or the entire OSPF
   routing domain (type 11).  Section 3 of this document describes the
   flooding procedures for the Opaque LSA.
It doesn't say whether or not the length should include the padding. However, I'd say that it should and the application should be
responsiblefor passing the real length (or somehow delimiting it). Hope this doesn't cause you too much pain,Acee

Coltun                      Standards Track

---

From: Greg Troxel <[email-masked]>
Date: Fri, 5 Nov 2004 14:11:09 -0500

It doesn't say whether or not the length should include the padding.
  However, I'd say that it should and the application should be
  responsible for passing the real length (or somehow delimiting it).

So this is essentially saying (departing from wire format to
on-machine API) that if a user says "publish this 15 octet value",
then that should be either rejected as an error or converted into
"publish 16 octects, the 15 given followed by a 0".  This of course
requires Opaque users to only use aligned structures (such as the TLV
rules), or to be able to extract lengths (e.g., null terminated
strings).  This implies a rule that it is an error for a value that is
not a multiple of 4 to ever appear on the wire in an LSA length field.

The alternative is to allow odd lengths for payloads and in the length
field, and require implementations to add and ignore padding when
packing/unpacking LSAs into/from LS update packets.  This is more
flexible (since it allows representation of odd-length payloads), but
more complicated and perhaps more likely to cause trouble with
existing implementations.

I would be interested to hear from other implementors - what does your
implementation do when receiving a LS update packet with an Opaque LSA
with length field 25 (indicating 20 header and 5 payload).  Treat this
a format error?  Expect the next LSA to start 28 octets after the
lenth-25 one?  25 octets later (quagga currently does this, and that's
clearly wrong)?

Do intra- or inter-process APIs permit odd-length payloads, or reject
them?

Regardless of the outcome, I'd say this is not clear from reading the
specs and a clarification will be in order.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 5 Nov 2004 14:38:35 -0500

----- Original Message -----
From: "Greg Troxel" <[email-masked]>
To: "Acee Lindem" <[email-masked]>
Cc: "Mailing List" <[email-masked]>
Sent: Friday, November 05, 2004 2:11 PM
Subject: Re: alignment/padding rules for Opaque LSAs

Greg,

While it would have been clearer if the length rules had been stated
explicitly here is my rationale for saying that the LSA length MUST include
the padding. RFC 2328 doesn't deal with this issue since all the described
LSAs are 32 bit aligned. RFC 2370 describes all the changes necessary
to support opaque LSAs. Hence, the absence of a section describing the
handling of alignment issues implies that the length must include both
the opaque value and padding.  This is also in the true spirit of opaqueness.

---

From: Paul Jakma <[email-masked]>
Date: Mon, 15 Nov 2004 02:14:19 +0000

Hi Acee,

> included in the length) or padding (and not included).

What about standard LSAs? Ie RFC2328? It is very careful to specify
structures that always result in 4byte aligned packets (to my memory
at least), however alignment is not mentioned at all (except for
checksums). In order to ensure our ospf implementation is robust can
we assume some kind of minimum alignment? For 2328 defined structures
we can in practice, however as it leaves the door open for other RFCs
to potentially define unaligned structures... (though none that i am
aware of do..).

Also, is it safe to assume that the OSPF packet length and the LSA
header length fields will always include any padding that may have
been included? (I'd presume so.. it would be a "layering" violation
of sorts if it did not).

Might it be an idea to issue some kind of document to clarify
alignment issues and (possibly) mandate that any future additions to
OSPF always ensure that LSAs be aligned to some minimum boundary?

> Acee

regards,
--
Paul Jakma      [email-masked]   [email-masked]  Key ID: 64A2FF6A
Fortune:
I hold it, that a little rebellion, now and then, is a good thing...
                -- Thomas Jefferson