Fwd: DVB GBS & IETF IPDVB Liaison

[Gorry Fairhurst]

I am pleased to have received the following comments from DVB via the 
GBS Chair.

These comments concern two ipdvb WG documents that are approaching WGLC 
(and a related draft).  The comments are provided as inputs to this 
working group, and I would encourage people with interest, particularly 
in Security, to discuss the issues that are raised to allow the 
generation of a final draft-ietf-ipdvb-sec-req-04.txt.

Best wishes,

Gorry Fairhurst
(ipdvb WG Chair)

----

GBS comments as supplied:

- general comments

     The good news is that we have only very few comments and these
     are on very specific issues. This means that we came to
     conclusions most similar to yours and we're hence probably all
     on the right track.

- draft-ietf-ipdvb-ule-ext-04.txt
   "Extension Formats for Unidirectional Lightweight Encapsulation
   (ULE) and the Generic Stream Encapsulation (GSE)"

     This appears rather to be an introductory document so we don't
     have any security related comments on this one.

- draft-ietf-ipdvb-sec-req-03.txt
   "Security requirements for the Unidirectional Lightweight
   Encapsulation (ULE) protocol"

     This document basically lists the same threat scenarios that we
     GBS is considering. So we have nothing to add in this respect.

     However we have come to the conclusion that some of these
     threats might also require mechanisms at the layer below the IP
     encapsulation which we did not see in your document? As GBS is
     building on top of a baseband layer which is currently under
     development, we of course still have the option of imposing
     security requirements on that layer (as opposed to the MPEG-2 TS
     which you are building upon)

     In section 5.2, when talking about the distribution of IP
     streams across PIDs, we think that the 1st and 2nd disadvantage
     do not apply in the generality in which they appear to be
     stated. In the text above the disadvantages, you correctly say
     that _typically_ the IP streams share a PID which implies that
     they don't necessarily do so. This aspect is dropped and shared
     PID is always assumed when talking about the disadvantages.

- draft-cruickshank-ipdvb-sec-03.txt
   "Security Extension for Unidirectional Lightweight Encapsulation
   Protocol"

     "Receiver NPA address hiding (mandatory)":
     draft-ietf-ipdvb-sec-req-03.txt seemed to suggest it were
     optional? We would prefer to have it optional.

     The PDU type does not seem to be encrypted?

     We would suggest opening up for optionally using encrypted MAC
     addresses instead of temporary ones.


We truly hope to have been helpful with our review and
comments. Should you in turn have any further comments or questions,
please don't hesitate to contact me.

Please feel free to distribute the comments to all ipdvb members as
you deem appropriate.

Thanks a lot and cheers,

   --alexander