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

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

Hi Gorry,

After reading your email, I went back and read carefully the security draft and
your extension formats for ULE/GSE draft. I think this is a very good point
raised and we should be careful in our wordings in the security requirements
draft.

Let us consider the different extension headers:

- Bridging header: RFC4236 states on page 18 that
?A bridged SNDU is a Mandatory Extension Header of Type 1.  It MUST be the final
(or only) extension header specified in the header chain of an SNDU.?

Hence it will always follow after the SECURITY Header ? so no problem for this
one.

- PDU-Concat header: This is interesting as it aims to combine several small
PDU?s into one SNDU for transmission in order to reduce the MAC overheads (due
to the headers). If these PDU?s all belong to the same Security Association
(SA) i.e. same session, then only a single SECURITY header would be required,
but things would get complicated when PDU?s of different sessions are
concatenated together. This is because the different sessions may have
different security requirements and will use different SA and hence different
security keys/security algorithms. But then using separate SECURIY Header for
each of these small PDU would increase the overhead. We could though combine
all the PDU of the same SA together and use a single SECURITY header for them.

- TS Concat header: This is used to transfer the PSI/SI tables and should use a
different SA from the one used for data.  This may get complex, where the
different TS packets have different SA and hence will require their own
SECURITY header. So in this case we have something like this
ULE base header->TS concat header-> SEC header 1->TS packet 1->SEC header 2-> TS
Packet 2-> CRC
For such a case we may need that the SECURITY header is not directly after the
ULE base header. But then the TS-concat header is not secured.

- Timestamp Header: I am not very sure if security is even required for this
one. If someone even reads the timestamp I do not think it would count as a
passive attack as it really does not give much information. And modification of
the timestamp should not hamper the ULE processing. So it may be put before the
SECURITY Header. If someone feels that they require security for the timestamp
header also then they could put it after the SECURIY header. Choosing an SA to
secure this timestamp header is another problem.

Regards
Prashant


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


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