I also sent a response to Prashat's later reply. Gorry Michael Noisternig wrote:
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.txtSorry, 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.
>True, if the headers relate to the payload. This also helps ensure integrity (avoiding security pitfalls arising from inconsistent information at various levels).
Less clear to me if they relate to the service (as in TimeStamp).
- 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.
> Correct.
- Forcing the SEC header to be the first in the extension header chain may also prevent from doing mistakes in security configuration.
True.
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."
Whoops - True. (That eliminates that option!)
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.
Right the current ULE EXT Spec is not clear on this.
+-----------+------+-------------------------------+------+ | 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 thedisadvantages of the above rule, for instance this draft currently does NOTallow 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 thepayload 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? GorryRegards, Michael