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

From: Michael Noisternig <[email-masked]>
Date: Wed, 06 Jun 2007 16:06:20 +0200

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.

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

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

---

From: Prashant Pillai <[email-masked]>
Date: Thu, 07 Jun 2007 10:42:58 +0100

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

> implementation, but this also reduces flexibility. The draft currently

==========================================================
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: [email-masked]
==========================================================
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to [email-masked]
------------------------------------------------------------

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 07 Jun 2007 11:31:22 +0100

Responding with my thoughts to this in-line (all as an author NOT a WG 
Chair).

I also sent a response to Prashat's later reply.

Gorry

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

> and the SEC header and upon receiving the following data bytes.
Correct.

> may also prevent from doing mistakes in security configuration.
True.

>    the final (or only) extension header specified in the header chain of
Whoops - True. (That eliminates that option!)

> possible to stick an individual extension header to each PDU within the 
Right the current ULE EXT Spec is not clear on this.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 07 Jun 2007 11:33:16 +0100

See in-line.

> Hence it will always follow after the SECURITY Header – so no problem for this
I agree, Sec header could be at front.

> 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
> 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
Yes, and use a PDU-Concat header for this group? - i.e. Sec header at 
outside is OK.

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

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

---

From: Prashant Pillai <[email-masked]>
Date: Thu, 07 Jun 2007 12:48:15 +0100

Hi Michael

see in-line

> may also prevent from doing mistakes in security configuration.

I agree with these points fully.

> 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

can be done.
>     the final (or only) extension header specified in the header chain of

YES

Regards
Prashant

---

From: Prashant Pillai <[email-masked]>
Date: Thu, 07 Jun 2007 16:59:37 +0100

Hi Gorry

See inline

---snip---

> Yes, and use a PDU-Concat header for this group? - i.e. Sec header at

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.

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

> monitoring the Jitter of streams that were encrypted.

Definitely

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

Regards
Prashant