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

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

Hi Gorry

See inline

Quoting Gorry Fairhurst <gorry@erg.abdn.ac.uk>:

> See in-line.
>
---snip---

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

I think that solves it. If security is used then we only concatenate the PDU's
of the same SA only. If security is not used, any PDU to the receiver may be
concatenated. So in this case SECURITY Header is outside.

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

Then the SECURITY header would be outside to secure the TS-Concat header and the
TS packets.

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

Definitely

> Should we be able to do this without decrypting... or do we need to have
> an SA to be able to do this?

If we do not secure it then there may not be any value left in the information
as it might as well have been modified. So I prefer to actually have security
for it and have an SA defined for it. It could use the SA defined for the
control plane data. So any control plane data like the PSI/SI tables, or this
timestamp header or other future Similar headers (???) may use this SA.

Or maybe just define a simple SA for the timestamp header which has no
encryption rules?maybe only to provide some data integrity.

> 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


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