IP over DVB (IPDVB) WG IETF-75, Stockholm, Sweden WG Chair: Gorry Fairhurst WG Secretary: Martin Stiemerling (via Jabber) Note-taker at IETF-75: Carsten/Michael/John 1. Agenda There were no additions to the Agenda. 2. Document Status * IPDVB Security Requirements - has been published as RFC 5458 * ULE Extensions - has been published as RFC 5163 The chair noted that there were now no active working group drafts, and therefore the group needed to examine whether there was a need for this WG to do future work, or whether the group should close. 3. Active Drafts * MIB for RCS (Chair, Proxy for Stephane Combes) http://tools.ietf.org/html/draft-combes-ipdvb-mib-rcs-05.txt Revisions -05 and -06 had been published, following comments from Dan Romascanu and Bert Wijnen as reviewers. This required many changes to the MIB layout. The new revision is available for further review. This process was proving useful to SatLabs. John Border: How does the chartered work on address resolution relate to the Generic Stream Encapsulation (GSE) that is progressing in DVB? What work is being done in the IETF? Gorry: There were drafts on address resolution in this WG, but these have not progressed. Since then, the DVB-GBS group studied how to do IP-oriented signaling, but my understanding is that this also did not progress. There is now renewed interest in DVB (e.g. DVB-RCS see a need) to work on this, although there is currently no DVB document I can refer you to. * IPDVB Security Extension (Michael Noisternig) http://www.ietf.org/internet-drafts/draft-noisternig-ipdvb-sec-ext-01.txt The authors of the two different individual drafts had discussed their implementation experience and the differences between the various mechanisms. The new draft reflected a common consensus on the best way forward. All authors were now happy with this direction and had produced some conference papers on the converged approach. They propose adding an appendix in the next version to relate this to GSE, since this is another alternate encapsulation that could be considered as a part of the RFC4259 framework. Can this be adopted as a WG item? Gorry: Adoption would be an AD decision, since it is not explicitly mentioned in our Charter. Carsten: What is the scope of the SA field (SID) - is 16-bits enough? Michael: The PID identifies the source flow for an MPEG stream. The authors think 16 bits may be enough for a link-scope, per PID or GSE link. Gorry: Is the 16-bit value sufficient? I guess the question about SID size is a topic that should be socialised with other communities. Perhaps this can be related to DVB requirements as stated for GSE. Does the scope match the intended use-cases, e.g. for DVB-S2, T2, and RCS? I think we could ask for comments from other groups? Carsten: There is a lot of capacity on a DVB transponder, does the field size force a specific design choice? Is the SID the only reference or is it combined with some other field? Michael: A 16 bit field is adequate for link‐layer security. One common unicast application is for VPNs at layer 2, rather than for individual security flows. Also for multicast this reflects the number of groups, not the number of receivers. Gorry: Does the larger scope of a GSE ISI raise issues? Michael: The SID value is interpreted per receiver, scoped by the NPA. Receivers first filter on the destination address (or null NPA) and then the security extension is processed. Carsten: This could be plenty, if this is the scope - isn't this optional? Michael: It may be natural to include the NPA base address (analogous to IPsec), since this could be done in hardware, and it is always an option to extend the range. Carsten: I agree this specification should stay independent of cipher suites, but you should write one, to know it can be done. This could be in a separate I-D. Michael: This is clear, we decided to split this from the base specification. Carsten: I would suggest making a separate draft on this, then it is clear what needs to be there. Michael: We intend to do that. Carsten: Is there support for padding? Michael: There is support in the SA field for CBC encryption. Carsten: You should check the key management protocol (say for DVB-RCS) can be used with your security method. This is also a good reason for providing a concrete example. Gorry: Is there any implementation experience of using the new method? Michael: We implemented our previous version. We now plan to start a joint effort with the others to implement and experiment with the new specification. Gorry: This is much simpler than the previous two drafts - which to me seems good. We would like feedback at this stage from other people. John: GSE supports 3 byte NPAs - does this specify how this would work? Michael: This is part of the adaptation to GSE that needs to go in the appendix. Summary of Chair comments: 1) I will seek AD advice on whether we can progress this in the IETF (and whether this would need a charter amendment or change of WG or other options). We would then need to ask the WG. 2) He did not see sufficient energy to do key management (this is a much bigger design space, and may not even be the same for each L2 deployment scenario) - My current advice is to take this forward as a research topic and then see if specific technoliges wish to take this forward (e.g. in DVB subgroups). * ROHC/IPDVB (Carsten Borman) http://tools.ietf.org/html/draft-bormann-rohc-over-802-02.txt The IETF had considerable experience on header compression, with 3 generations of specifications. The most recent generation is based on PPP - 3GPP has defined ROHC. Presented a draft for header compression proposal for 802 links, targeted at WiFi. This could use 802.2 LLC encapsulation in bridging mode. This could be directly applicable to ULE, but may be inefficient, assignment of a ULE codepoint for DVB frameworks would provide an efficient method. Work is needed also to negotiate parameters and then specify unidirectional use. Carsten: Was this in the Charter? Gorry: There is no milestone. This has been talked about as additional work in many meetings, stretching all the way back to the BarBoF sessions for the WG. Gorry: Draft -00 of this was in 2004, and -02 in 2009. In the interim there was discussion on the list on ROHC for DVB - i.e. ULE, and a series of presentations. Tcwan (via Jabber): We at Universiti Sains Malaysia, Penang, are interested in working on ROHC parameter negotiation over broadcast-type networks (satellite, primarily) and have a published an Internet draft on this topic. Gorry: Have you looked at this? Carsten: I did not look at this, since my focus was on WiFi. Gorry: I think we need to read and compare the two drafts and see how they compare. Carsten: I agree. Gorry: I like the idea of solving the ULE issues at the same time as other generic bridged solutions. Gorry: This is quite some interval between updates. Do you expect more rapid progress now with this? If we got comments can we expect a quick revision of the draft? Carsten: We are now in a position to progress this. The ROHC WG is also winding down, so I'd see a desire to progress within the year. Gorry: This could have wider applicability than just IPDVB, there could be other places in the IETF that have interest in this. John: I think the draft motivates work in ROHC, but I see they are winding down too. Carsten: The ROHC-specific details are minimal. The issues are does it work with bridging and IP over DVB systems. Jari (via jabber): We want to see interest from the community to work on a topic. the choice of this WG or INT Area WG is not so relevant - we need to know who needs and will do this. My basic rule for determining whether we continue with IPDVB is that you folks in the room want to do it, and can convince us that you have the energy Gorry: I would like to take this with other issues to Ralph (as AD) to examine how best to take this forward. 4. Discussion of next steps (All) Gorry: I see there appears to be no active work we know of from DVB on security or header compression. Do we have sufficient energy to address any of the new topics that people have suggested? Who has time? Who needs this done? Michael: Signaling security is an issue that needs to be addressed. This motivates the need for some common security methods. Gorry: I agree this is something that really needs to be addressed in the new systems. Carsten: Homegateways have identified a need to look in layer 2 devices and determine their queue sizes. This has needed to be solved in satellite systems, and has seen a number of options. Gorry: Right, this is no surpise, we could add this to the list. (See also presentation to IPDVB by Lloyd Wood at dublin IETF). Carsten: Not just the home side. Gorry: Yes, especially with header compression this is something that is not easy to integrate in existing systems. Gorry: Can we judge energy in the group to work on this? <5 people, all remaining in the room supported the work>. Carsten: Is this enough to continue? Gorry: Likely not based on people in the meeting, but we should judge activity from the list. Jari (via Jabber): The decision is not where to progress things, but more whether there is sufficient interest to take this forward. Jari (via Jabber): From the people in the room, what is their priority one topic that would like to work on? (from Gorry's slides). Carsten: To answer the question with respect to ROHC. We have done some recent work in the ROHC WG, and that went well. I am pretty sure we can do ROHC over WiFi. There is energy for this. John Border: Header compression is important to us as a first priority, followed by link-layer security. Michael: Security and then header compression. Gorry (not as chair): We have started a research project to suggest GSE signaling seeking to input to DVB, this would benefit from security and header compression and I would be keen to collaborate on these topics. Gorry: I would add that the feedback from the DVB-RCS activity in DVB was that this work relates to their future agenda (and that they do not have contributions on these specific topics). This seems like an opportunity to do work that will be used by other standards groups, it would be nice to hear confirmation of this. The group needed a clear statement on who would contribute what and the expected scope for using the developed work. The meeting concluded. There was then a discussion of who would contribute to each topic, and Gorry said that it is important that this discussion was taken to the list.