Fwd: DVB GBS & IETF IPDVB Liaison

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

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