[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

See in-line.

Prashant Pillai wrote:


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.


I agree, Sec header could be at front.


- 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). 
>
I'd supposed that each "PDU" in a PDU-Concat COULD have an extension header (my co-author may have hsd different intentions) - the current rules say all MUST have the same TYPE.
It does not say for instance if this TYPE, could be a BRIDGING header. (In other words the this does not have to be the last header of the Chain). Now, one could argue otherwise.... and if someone thinks that is better let us know !!!. 


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. 
>
Yes - which could be a dis-incentive to want to do this, but there could still be cases where this was useful....? 


We could though combine
all the PDU of the same SA together and use a single SECURITY header for them.
Yes, and use a PDU-Concat header for this group? - i.e. Sec header at outside is OK. 


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

>
That was not what I had in mind... My suggestion was that we view TS-Concat as like a final EtherType, rather as in Bridging. So you could NOT put a series of "sec headers" in the middle of the payload.
So, if I were trying to offer different SA to different PIDs WITHIN a stream carried via TS-Concat, I'd use one TS-Concat SNDU for each SA. 


- 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.
On this we seem to have the same view, which was my reason for questioning what we should do. It seems that there could be value in monitoring the Jitter of streams that were encrypted.
Should we be able to do this without decrypting... or do we need to have an SA to be able to do this?
If it were simple, I would go for flexibility and allow TS on teh outside (we may find other headers we wisjh to put there --- e.g. time-slicing which we'd like to have wider visibility... but if it is the ONLY known exception to a rule, the execption may not be justified. 

Thoughts?


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