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

[Michael Noisternig <mnoist@cosy.sbg.ac.at>]

Gorry Fairhurst wrote:
> 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

Sorry, I still haven't read the new document, though I hope to get to it 
soon. I want to comment on below question, though.

> 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:

Yes, I also view it as a tradeoff between simplicity/efficiency and 
flexibility.

Restricting the SEC header's position to be right after the base header 
has the following rationale:
- If you want security, you likely want all the data to be secured 
(encrypted/authenticated). You probably, as a receiver, don't want to 
parse extension headers, and then at the SEC header find out that 
someone/something has mangled your data.
- A receiver device may be able to start verifying a SNDU's authenticity 
and decrypt its data "on-the-fly" as soon as it has got the base header 
and the SEC header and upon receiving the following data bytes.
- Forcing the SEC header to be the first in the extension header chain 
may also prevent from doing mistakes in security configuration.

Is there really a need of putting other extension headers in front of 
the SEC header? What is a use case? And is it only about keeping some 
extension header in the clear? If yes, another solution may be to define 
(via security policy) that the first x bytes following the SEC headers 
remain unencrypted. This solution would keep us the ability to verify 
the whole SNDU's authenticity.

Regarding the position of the bridging header in front of the SEC header 
(see below), this is prohibited by the ULE RFC 3426, section 5.2:
  "It MUST be
   the final (or only) extension header specified in the header chain of
   an SNDU."

Regarding PDU-concat, I do not quite understand. AFAIK, it is not 
possible to stick an individual extension header to each PDU within the 
concat group.

> +-----------+------+-------------------------------+------+
> | 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 

Regards,
Michael