End of WGLC: draft-ietf-ipdvb-arch-01.txt

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

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipdvb-arch-01.txt>

The WGLC for the above ID ended at midnight on 29th October 2004. A 
summary of the issues raised is provided below.

Gorry Fairhurst
(IPDVB WG CHAIR)

--------------

Comments were received from:
George Gross
Rod Walsh
Haitham Cruickshank

All authors have also reviewed this version of the ID:
M.J. Montpetit
Gorry Fairhurst
Horst D. Clausen
Bernhard Collini-Nocker
Hilmar Linder

--------------

* Section 8: Security Considerations

* Section 8.1 - Link Encryption
- Should the IPDVB architecture require at least ONE security service?

Current text:
   "MPE supports optional link encryption using a pair of bits within
    the MPE protocol header to indicate the use of encryption.  To
    support optional link level encryption, it is recommended that a new
    encapsulation also supports optional encryption of the SNDU payload.
    Furthermore, it may be desirable to encrypt/authenticate some/all of
    the SNDU headers.  The method of encryption and the way in which
    keys are exchanged is beyond the scope of the ULE Specification.
    However, the specification must provide appropriate code points to
    allow such encryption to be implemented at the link layer."

* The IPDVB arch document should identify its requirements on
these security services: point-to-point encryption between head-end and
individual subscriber, source authentication when binding IP addresses 
and MAC addresses, mutual authentication between the subscriber terminal 
and head-end, etc.

* Optional MPE/ULE layer encryption (which encapsulates the IP packets),
requires any hacker to have the encryption key to see any user data in 
these SNDUs.

* IPDVB can assume that some networks are totally insecure and some are 
totally secure.

* There is a case to be made for an industry-wide IPDVB security service:
- superior security, due to peer review by the IETF community,
- inter-operability, fostering economies of scale like that seen for 802
wireless.

*  The way things stand at the moment in this document, an IPDVB vendor 
does not have to implement any security standards. They can produce 
products that only transmit cleartext and still they can assert that 
they are IETF IPDVB "standards compliant". Further, any two vendors that 
do implement a DVB security service are unlikely to inter-operate, since 
none was mandated as a must implement.

This could be a DVB link-layer service or it could a MSEC layer-3 
overlay. The former option makes this group's work dependent on another 
SDO. The latter option could be advanced by this working group in 
cooperation with MSEC...

* We need to debate whether this is the right forum and right time in 
this forum.

* These can not be solved in the framework without some length of work 
and strong DVB liaison even at this stage (as the related DVB work is in 
progress) so it could be best to move towards modifing the I-D to 
accomodate furture security work.

* Encourage the WG to look into these security aspects more.

* It may be better to keep focused and wait for the DVB IP security 
solution dust to settle.

* List of references enumerating the relevant security services, 
assuming they are in the public domain.

* Need for a standards track IPDVB security protocol document?

- This issue needs to be resolved.

---------------

* Scope of AR:

* I get the impression that it is an intentional limitation of the AR 
that it applies only to the current TS (as you would expect cf ARP). 
This is a sensible limitation but it's worth stating explicitly. (i.e. 
that address resolution for other TSes, e.g. for moving TS and mobility 
optimisation, is not in scope).

- I think the WG would could work with any of these issues, if there is 
expertise and with appropriate collaboration (or inputs from other 
standards bodies).

---------------

* Editorial NiTs

(see also http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00817.html)

* the "Change Notice:" should be described in a annex including a note 
to the RFC Editor that they are not to be included in the RFC

* "D-TV" of figure 1 should be "terrestrial" to be in line with 
"satelite" and "cable" (all 3 can deliver D-TV and more).

* "Data-cast" is correctly spelt "Datacast" and is more commonly known 
as "IP Datacast" in this context (other-than-IP packetisation over 
broacast also gets labelled datacast from time to time)

* 5.4 AR Authentication
"Servers should perform authorisation issue before they allow a L2 
address to be used." - remove "issue".

------------------

Gorry Fairhurst
(IPDVB WG Chair)