Question on draft-ietf-ipdvb-sec-req-02.txt

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

After working on the ULE extensions draft, I have a question about header
placement when security headers are involved. This arises in:

http://tools.ietf.org/id/draft-ietf-ipdvb-sec-req-02.txt

The annexe (on page 23) states:

  " There could be other extension
    headers (either mandatory or optional) but these will always be
    placed after the security extension header. In this way all
    extension headers (if any) follow the security extension header."

I can see that imposing rules can constrain the design and simplify
implementation, but this also reduces flexibility. The draft currently
allows:

+-----------+------+-------------------------------+------+
| ULE       |SEC   |     Protocol Data Unit        |      |
|Base Header|Header|                               |CRC-32|
+-----------+------+-------------------------------+------+

And

+-----------+------+------+------------------------+------+
| ULE       |SEC   |Ext   |    Protocol Data Unit  |      |
|Base Header|Header|Header|                        |CRC-32|
+-----------+------+------+------------------------+------+

Where Ext Header could for example be:
    Bridging Header
    TS-Concat
    PDU-Concat
    TimeStamp

To help see what is best - especially as we progress the ULE extension
header spec., I would therefore like to understand what may be the
disadvantages of the above rule, for instance this draft currently does NOT
allow the following :

+-----------+------+------+------------------------+------+
| ULE       |Bridge|SEC   |    Protocol Data Unit  |      |
|Base Header|Header|Header|                        |CRC-32|
+-----------+------+------+------------------------+------+

Or

+-----------+------+------+------------------------+------+
| ULE       |TStamp|SEC   |    Protocol Data Unit  |      |
|Base Header|Header|Header|                        |CRC-32|
+-----------+------+------+------------------------+------+

This rule would also prevent using the SEC header on each PDU that forms the
payload of a PDU-Concat.

Do we NEED to have this constraint? What is the benefit v. complexity of
also allowing the above set of placements?

Gorry