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

[Prashant Pillai <P.Pillai@Bradford.ac.uk>]

Hi Michael

see in-line

Quoting 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.
>

I agree with these points fully.


> Is there really a need of putting other extension headers in front of
> the SEC header? What is a use case?

I think headers like the timestamp header or maybe others that may come in the
future, may be more beneficial to be put int the front.

There are two main issues that arise:
- There may be headers that do not require any security.
- Would we concatenate PDU's or TS packets that would use different SA's in a
single SNDU? I prefer not to. I prefer to only concatenate PDU's or TS packets
that use the same SA and then use the SECURITY header outside and the
PDU-concat or TS-concat inside.

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

can be done.
>
> 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."

YES

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

Regards
Prashant

==========================================================
Prashant Pillai (BSc, MSc, MIET, MIEEE)
Research Assistant
School of Engineering, Design & Technology (EDT2)
University of Bradford
Bradford, West Yorkshire BD7 1DP.
Tel: +44(0)1274 233720
Email: p.pillai@bradford.ac.uk
==========================================================
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to misuse@bradford.ac.uk
------------------------------------------------------------