Last Modified: 2005-06-27
| Done | Draft of a WG Architecture ID describing usage of MPEG-2 transport for IP transmission. | |
| Done | Draft of a WG ID on the new Encapsulation. | |
| Done | Submit Architecture to IESG | |
| Done | Draft of a WG ID on the AR Framework, specifying mechanisms to perform address resolution. | |
| Done | Submit Encapsulation to IESG | |
| Feb 05 | Draft of a WG ID or the AR Protocol, defining a protocol to perform IP address resolution. | |
| Oct 05 | Submit AR Framework to IESG | |
| Dec 05 | Submit AR Protocol to IESG | |
| Dec 05 | Progress the Encapsulation RFC along the IETF standards track |
|
Minutes of IP over Digital Video Broadcast WG (ipdvb)
===================================================== CHAIR: Gorry Fairhurst <gorry@erg.abdn.ac.uk> Minutes reported by Jörg Ott <jo@netlab.hut.fi>. The IPDVB WG met once at the 63rd IETF (3 August 2005, 1030-1230). The meeting was chaired by Gorry Fairhurst. The proposed agenda was accepted, no additions were made. A tentatively scheduled presentation from Fraunhofer Gesellschaft (draft-miloucheva-udlr-mipv6-00.txt ) was cancelled, because no presenter was available. Document Status --------------- The chair reported on the document status: Two documents are in the RFC Editor queue: draft-ietf-ipdvb-ule-06 (for Proposed Standard) and draft-ietf-ipdvb-arch-04 (for Informational). No other documents are in the IETF process beyond discussion in the WG. There is one active WG draft, draft-ietf-ipdvb-ar-00.txt which had superseded draft-fair-ipdvb-ar-03.txt. Further drafts to be discussed at the meeting include draft-stiemerling-ipdvb-config-01.txt draft-cruickshank-ipdvb-sec-00.txt, draft-cantillo-ipdvb-s2encaps-00.txt, and draft-bormann-rohc-over-802-01.txt. On the ROHC draft, Carsten Bormann noted that only one minor problem still remains to be solved for the Ethernet case: to get a number assigned. Then one can define a protocol to negotiate the context. A future draft could potentially address both ULE and Ethernet, and for ULE this could piggyback on whatever config approach IPDVB will take. The present draft -01 will remain active. Volunteers are required to progress the address resolution protocol and perhaps to to revive draft-montpetit-ipdvb-config-00.txt, expired. Gorry reviewed the WG milestones noting a new WG draft on AR process, but that there was currently no WG document for address resolution protocol (was supposed to be available as -00 in Feb 2005). The deadline has been postponed with agreement from the Area Director. Uni-directional Lightweight Encapsulation ----------------------------------------- draft-ietf-ipdvb-ule-06.txt Gorry Fairhurst present a brief update on the ULE spec. Revision -05 was submitted to the IESG. Revision -06, that was published recently, has the comments of the IESG review folded in. Refer to the slides for a detailed list of changes. Gorry pointed out a substantial change regarding the IANA registration procedures. He also noted the new document title, which had changed from "Ultra-Lightweight Encapsulation" to "Uni-directional Lightweight Encapsulation". A comment was made that ULE should also applicable to DVB-RCS and is thus not limited to uni-directional communications. There were suggestions on finding a better expansion of the letter "U" in the spec's title, but this is not felt to be serious and the new name was accepted. Gorry noted also that until recently, ULE had not defined a "format_identifier" that would be needed in the context of an MPEG TS multiplex to identify the ULE stream in the SI signalling. The value 0x554C4531 has now been assigned for use with ULE by SMPTE (the ISO registry for SI values). Similar registration requests could be made for a "Stream_Type" where registries are maintained by DVB, and ATSC. It was also possible to consider allocating a "Data_broadcast_ID", although this was normally used with table sections, and therefore was necessarily appropriate to ULE. If there is a strong desire for a "Data_broadcast_ID", this should be taken to the list. Finally, Gorry provided an update on ULE implementations: various commercial and open source receivers are available at this point but only commercial gateways (i.e., senders). Some at the meeting noted that the European IST project Daidalos is developing an implementation with work from Fraunhofer Gesellschaft; however, Gorry was unable to say whether or not the result will be open source. Information about known implementations can be found at http://www.erg.abdn.ac.uk/ipdvb/ipdvb-impl.html and implementers are encouraged to provide additional/updated information regarding this page. Address Resolution ------------------ draft-ietf-ipdvb-ar-00.txt Gorry briefly reported on AR on behalf of Marie-José Montpetit. Address resolution is about associating IPv4/IPv6 addresses with an MPEG-2 TS.The draft was adopted as a WG document and recent changes reflect much previous input from the UDLR WG, various nits, and a major reorganisation of the the sections. Further details are in the slides. Gorry strongly encouraged input from the group on a number of intended future changes (also listed in the slides). IP Address Configuration for ipdvb ---------------------------------- draft-stiemerling-ipdvb-config-01.txt Martin Stiemerling gave a short intro to the draft's history and then proceeded to summarise changes to the draft (see slides). He rehashed the problem space as well as the network and configuration scenarios (already introduced at the last IETF). Agreement within the group is needed on these issues and so he solicits feedback in order to proceed. One question from the audience was raised: why not simply use IPv6 autoconfig? Martin responded that there is a potential stability issue as IPDVB may be faced with 10s of thousands of receivers, and that other parameters (not currently specified by the NDP) may be required. Martin concluded, stating that a new draft will be available in the Sep/Oct timeframe. ULE Security Extension ---------------------- draft-cruickshank-ipdvb-sec-00.txt Haitham Cruikshank presented some proposed security extensions for ULE, a subject that was already raised at the last IETF, but no feedback was received on the list afterwards. He noted that there had been a parallel presentation in the MSEC WG (which could provide appropriate review for the key-management functions). He briefly reviewed comments received on this matter at the last IETF meeting (see slides and minutes from the 62nd IETF) and gave an overview of the changes. He proceeded with a motivation for ULE security and requirements for IP over MPEG-2 TS (see slides 3 and 4). In particular, he stated that the ULE security shall not be a replacement for security at other layers and shall help to maintain transparency with Performance Enhancing Proxies (PEPs). Haitham went ahead to discuss the proposed approach (see slides 5-8) and then suggested future plans for the next revision (slide 9). There was discussion about the number of keys that would need to be managed, and Haitham was asked if all entities shared a single key? - Haitham noted that the proposal could live with a only single key at each receiver for all unicast flows sent to a receiver, and perhaps one key per flow (as in msec) for multicast flows. There was discussion about whether one key for all receivers was possible, which provoked doubt in the audience that this was really advantageous. Looking at the proposed packet format and the presentation, Steve Bellovin noted that authentication of the source of data was essential. In practice, this required at least a sequence number and a crypto integrity check. He affirmed that using only a single key for all the network traffic was a mistake as this would make attacks on confidentiality much easier. With reference to the sample ULE packet format a question was raised which part of it would be encrypted. Haitham responded that this is the "SNDU payload", potentially including arbitrary inner extension headers. Haitham noted that the chosen approach allows also non-IP packets to be secured by ULE. A comment from the MSEC WG was made: whether or not IP-based key management could also be used for non-IP packets -- which Haitham confirmed: this was explicitly included in the current requirements. Steve Bellovin asked if there was a method defined that would allow the IPsec to be applied to non-IP traffic, because current IPsec relies on port numbers, etc to define the flows within the Security Policy Database (SPD). New entries/methods would be required if layer 2 frames were be to encrypted. He also urged caution regarding multicast traffic. In particular, he argued that a good justification is needed for doing non-IP traffic security in the IETF, and that this would need input and review from the Security Area. Modifications to the SPD and its use shouldn't be done in an Internet Area working group. He went on to state that the ULE security designers should not make simplifying assumptions about capabilities of attackers (hinting at the missing HMACs). He further noted that HMACs are pretty much free (in terms of processing, but not protocol overhead) at data rates around 100 Mbit/s. Joerg Ott raised concerns that the case for the inclusion of security at the ULE layer is still not really motivated. He noted that TCP PEPs could well work with IPsec (if just applied at the right point which also applied to ULE security). He encouraged the authors to perform at least a detailed analysis of why IPsec cannot/should not be used. During the discussion, it was noted that two things can be bought by L2 encryption: some degree of medium access control and prevention of traffic analysis (the latter only partially, however, since there is other information available). Margaret Wasserman stated that she was concerned that if the non-IP traffic required a new infrastructure, then this may not be appropriate work for the group. If the group decided to go with IP traffic only, IPsec key management may be appropriate. She also noted that the authors seemed to be looking for something in between - were bridging and IP traffic equally important? At the moment, she is not sure whether there is something to work on. People are encouraged to look into this problem since it requires a broad analysis, and a separate requirements document (as an I-D) would be the best way forward, so that the WG can understand the issues to be addressed. This also will allow the ADs to understand the motivation/needs/objectives. Steve volunteered to help understand the threat analysis and would send some references as a starting point to the authors. IP Encapsulation for DVB-S.2 ---------------------------- draft-cantillo-ipdvb-s2encaps-00.txt Juan Cantillo presented some requirements for transmission of IP datagrams over DVB-S2 (see slides). He gave a quick overview of DVB-S2 and particularly the available framing formats. Besides MPEG TS, DVB-S2 will also allow for "generic streams" that are IP friendly and no longer requires fixed-size frames. While, for IP encapsulation, IP over ULE/PPoE via MPEG TS over DVB-S2 is possible, no choice had been made for an adaptationlayer using the Generic Stream. Moreover, the capabilities of generic streams suggest the development of a new adaptation layer. He presented some basic ideas and issues to that end (see slides). Joerg Ott remarked that TU Braunschweig is working on an all-IP encapsulation (without ULE/PPoE) for DVB. Gorry said a number of other people had also voiced interest and on-going projects in this area to the ipdvb list. Rod Walsh said that the definition of such an adaptation layer would require coordination with DVB to avoid conflicts in the future. Instead of pursuing this work in the IETF, it may be possible to provide input to DVB. Gorry Fairhurst said that he was aware of the parallel work within DVB-GBS, and the work in an ad-hoc WG on the design of a new encapsulation. There was a good liaison with this group. He said this work had proved more difficult than first envisaged, and that there were complex dependencies between the physical layer needs and the IP network functions. These were not yet well understood, and a clear definition of the requirements would be good for all. The ad-hoc group responsible for this work were aware of this draft, and of the discussions within the ipdvb list. Gorry Fairhurst asked whether a DVB-S2 mechanism should be something completely different or some adaptation of ULE? Juan does not see a necessity for a completely different approach, but also indicates that ULE is not directly applicable for cases with no MPEG-2 TS, as in DVB-S2. An inquiry from the chair showed that few in the room had read (or was aware) of the draft. He urged the group to read and comment on it. The draft will be updated in September. Review of Milestones -------------------- Finally, Gorry Fairhurst returned to the status of the milestones (see above) and strongly urged the group to provide input on the address resolution as this is now the most pressing work item. |