IP over DVB IETF-68 Prague, CZ TUESDAY, March 20, 2007 1850-1950 Afternoon Session IV Note taker: Martin Stiemerling 1. Agenda The agenda was accepted with small a change. There was no presentation this meeting about the current header compression ID. 2. Document Status (Gorry Fairhurst, GF) This presented the document status and the WG milestones. 3. ULE Security Requirements (Sunil Iyengar, SI) http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-sec-req-01.txt This presented the changes since this was introduced as a WG item. Michael Noistering (MN): Sequence numbers prevents replay inside/outside attacks. SI: This was a typo in slides, it does not matter whether it is inside or outside. MN: Do you accept other extension headers before the security extension header? A decapsulator could work on headers before security header and use these, only to later discover that the authentication fails? SI: One example is extension headers that may do compression. MN: Other attacks, such as active attacks, could change the unprotected headers. These headers may also need to be authenticated. SI: The set of headers protected is a matter of policy. MN: At which point do you evaluate the security extension header? SI: Three different scenarios exist, some are optional, e.g. in SPD/SAD. MN: Suppose we have a policy that says everything needs to be authenticated, if there are outer headers, these can later be discovered to be wrong. SI: The CRC may help. GF: ... but this is framing validation, not authentication. SI: The length given in security header determines the part under security protection. MN: An adversary could have tampered with the unprotected headers. GF: From a security point this may not be a good idea, this should be noted, and we should identify the vulnerabilities. However, Timestamps for measurement could be of interest, even if not protected. NM: You do not find out that TS has changed. GF: You live with it, if you are using it for OAM - for other purposes this may not be good. Christian Praehauser (CP): This should be left to the encapsulator configuration. GF: Needs work on this point. I suggest you propose text. We have comments from Knut at ESA, and will update the Framework. GF: It is important to get the framework right. NM: I will send more comments to the list. One comment is that the appendix may not be the right place, as it looks at a solution. GF: In the IETF, we often do not separate requirements from frameworks, this could be useful in an appendix to show the way this could move forward. 4. Extension Formats (Gorry Fairhurst, GF) http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-ext-01.txt This is a WG item. We can request IANA allocations for the set of extensions we will define, even if we do not yet know the details of each of these. GF: Who has read this? (roughly 6 people showing hands) GF: Who thinks the WG should specify an MPEG2 TS-Concat option? (3 people showing hands) GF: Who thinks the PDU concatenation should be in specification? (4 people showing hands) The discussion follows next presentation. 5. Implementation Experience (Christian Praehauser, CP) CP: Could we include a type field for each PDU? GF: Do we need to concatenate PDUs of different type? If we do not, decapsulation is easier. CP: Currently this is straightforward. A T-bit would increase processing overhead, but give more flexibility. GF: This also gives more branches where things could go wrong. CP: My concerns are about loosing flexibility. GF: Let us have a dicussion about the bit and look at use-cases, and look at benefits, and decide. CP: Possibility this also lets you add further ULE extension to each PDU, which may be another scenario in which the T-bit would offer benefit. GF: Is the Timestamp extension useful for OAM, do we need this? Kenneth Toney (KT): Definitely this is useful at the set top box. GF: Is a Timestamp useful? Should we be doing it? (7 in favour, none opposing) GF: Please send these comments, and other issues to the list. CP: Will summ up all issues and send to list. 6. Individual Drafts * Providing IP Services Over DVB-S2 (Juan Cantillo, JC) http://www.ietf.org/internet-drafts/draft-cantillo-ipdvb-s2encaps-04 JC: What to do with the draft? GF: The draft has been around for some time. Please send comments to the list on how to proceed with the draft. 7. MIB Status Some allocations had been made since the last meeting by IANA to SatLabs. * SatLabs MIB (Stephane Combes, SC) There is a draft on web, to be published in ID archive when re-opened after the meeting. This is aimed at an Informational RFC. GF: I have a couple of questions... GF: The IPR statement maintains change control. This therefore can not be submitted as WG item. The IETF will need to request changes to the draft on the way to making an RFC. There will be review by experts, also the MIB review. They will undoubtly find something to change in the MIB. SC: We will make the changes to implement them in the draft. KT: Do you also plan to submit the MIB somewhere else as well? SC: No. The aim is to register this with the IETF community. Interface types have been registered with IANA. Ken: I am asking, just to be sure, is DVB interested in this MIB? SC: DVB as it stands is not much focused on management. The DVB-RCS WG did not want to push this forward, we need it for interoperability. KT: It looks the ETSI BSM working group will write some MIBs. SC: There's a regular liaison with SatLabs and ETSI/BSM. GF: Good, we do have a WG-level liaison with ETSI/BSM, but no formal liaison with DVB. GF: We expect the draft to be published as rev -00, and then please do comment. 8. Header Compression Discussion GF: Carsten would like to update us on the topic of header compression, after the discussions at the last IETF. Carsten Bohrmann (CB): Not much happened since the last IETF. It may be a good idea, to get the "cow off the ice", i.e., get things moving. People are interested in header compression, please stay here in this room or meet in the bar sometimes this week, to sketch out what to do next. GF: The Internet Area Chairs have spoken of header compression in general. CB: Every IP-over-Foo WG thinks about header compression, but they do not all have the same needs. GF: We will discuss this more in future. Session ended at 20:05 CET.