IETF 68 RMT WG Minutes Wednesday, 21 March 2007 Afternoon Session I 1300-1500 ====================================== 1) Agenda Bashing The meeting began with a review and comments on the proposed agenda. Magnus Westerlund volunteered to act as Jabber scribe, taking minutes. 2) Working Group Progress The working group chairs presented working group status and progress. Please see the presentation on "RMT Working Group Status" for details. TOPIC: Documents Status: Magnus clarified that "draft-mehta-rmt-flute-sdp" does not expire and is approved waiting for publication. Toni Paila confirmed that a point Magnus made on reusing this in broadcast area was correct. Magnus stated the document is currently stuck in RFC-editor queue because of normative reference to revised building blocks. There was discussion on how to generalize this work for use in fecframe. However it was commented that the current draft is used in a number of standards like 3GPP, and OMA. Greg and Lorenzo discussed a bit on how to move forward with something more generic and it seems to not be a problem. It was noted that Vincent Roca is currently the main editor for FLUTE and Vincent stated there have been no changes recently. Vincent provided a presentation on the FEC RS building block. See the "FEC LDPC, Reed Solomon and TESLA Updates" presentation for details. Mark Watson commented/clarified that the FEC RS document itself should identify the IANA assignment for an Instance ID for a parallel specficication of the Reed Solomon codec as a "Under Specified" codec as well as its "Fully Specified" form. This comment was introduced by Brian Adamson so that an implementation could use the alternative, more detailed Object Transport Information format described in the "FEC Basic Schemes" building block document. Mark also raised the question of why 'G' larger than one is considered and Brian provided an example where a large packet comprised of small FEC symbols could allow some systems (ala UDP-Lite) to provide recovery of _portions_ of packets when needed. Vincent summarized that a new version of FEC RS document will be released soon to address these issues and Lorenzo indicated that another WGLC should not be required given these relatively minor issues. TOPIC: Revised WG Milestones WG Chairs will updated milestones on IETF RMT WG charter page. Also the "RMT Security Issues" draft presented at the previous meeting by Vincent and Brian will be submitted as a working group document. 3) TESLA for ALC/NORM Vincent Roca also addressed the TESLA ID update and mentioned questions with respect to NORM usage that are outstanding, including how to send direction time sync, etc. An issue was raised concerning how the opaque EXT_AUTH header extension for NORM/ALC could be interpreted by end points. It was indicated that out-of-band information (e.g. SDP) might be used. ALC also provides a codepoint that could be used to map algorithms, but NORM does not. Vincent has proposed an initial format for self-description, but Lorenzo pointed out that "if the WG are going down the path of self describing creates a lot of extra work". It was noted that in NORM we would not be able to change schemes on the fly or use more than one, but perhaps using one in the sender direction and a different scheme in the feedback direction might be implicitly possible given session context/information. Magnus also mentioned "in the new FLUTE draft it says the the codepoint is to be used for FEC Encoding ID". 4) FCAST: Scalable Object Delivery on top of the ALC Protocol draft-roca-rmt-newfcast-00.txt Lorenzo presenting background to FCAST. Being a altarnative to the IPR encumbered FLUTE. Vincent referred to Nokia IPR and the purpose is to try find an alternative that doesn't encumber this patent. FCAST is proposal ressurrected from 2000. Toni Paila commented "I would prefer to see Vincent focusing on technical aspects of the FCAST proposal." Lorenzo commented "the WG should focus on the looking at the new proposal" Vincent pointed out the original has major limiation: Need to download and decode to get to meta data. There are two complementary ways of carry meta data: Append or in Extension. Also, only subset of meta data are of interest to put in header extension. Rest can be appended. The FCAST session description object can describe all the objects that are part of the carousel instance. Simple way for client to learn if it has download all the files. Some options for the "way forward" for the WG were discussed: Option 1, look into the patent. Option 2. we don't care about the patent. Option 3. we continue in the direction of fcast. Although FCAST only is for ALC it can be extended for NORM. And Brian Adamson pointed out that NORM also provides the NORM_INFO mechanism for carrying such meta-data as an alternative way of carrying the information within Norm and has been implemented on low bandwidth links. Lorenzo indicated the discussion on the "way forward" should be brought to the WG list. Also one goal of FLUTE was to constrain the ALC so that they would interoperate more easily. We probably like to do that also for FCAST. Toni Paila also noted that Vincent mentioned that the intent is not to replace FLUTE. Also he identified that external organizations have already selected FLUTE and there are products based on that. This note by Vincent should be captured in the meeting notes. Rami lettinen question wheter we really like to put this also on standards track. And Stephen Wenger asked if the distinguishing factor between the propsals is only the IPR. For all we know, there might already be patents on this (FCAST)going into a design phase. Laksminath suggested the WG at least try to develop a new alternative and see where it goes. Toni Paila commented that the IPR discussion goes to way that is not in scope or expertise of RMT. I suggest that we stick to technical discussion. Gorry Fairhurst question how congestion control is covered for FCAST. It was pointed that both NORM and ALC upon which FCAST would ride address congestion control. Mark Watson commented "there might be patent out there that cover anything of the solution. Had we known about the Nokia patent at the time we did the design, then things may have looked different. However, I will not comment now on what to do. Lets take that on the list." Toni Paila mentioned that OMA, 3GPP and DVB make FLUTE mandatory and the light-weight option Laksminath is mentioning is only used as optional alternative. The question was raised" So, what do we do with Flute Laksminath mentioned there are standards bodies that adopted FLUTE. Thus, we shouldn't kick it out. However for the ones that hasn't selected yet we can develop alternatives such as FCAST. Lorenzo said he will send mail to the list about this question. Will also ask the list about accepting FCAST as WG item.s 5) NORM IPSec-based Baseline Secure Operation draft-ietf-rmt-pi-norm-revised-04 Brian Adamson presented. See "NORM Security" presentation for details. Discussion: Goal to establish a baseline approach that uses available security tools for the most common NORM usages. NORM SSM seems that lowest hanging fruit. The NORM SSM paradigm was described and the potential for bi-directional traffic from NORM receiver and senders. A number of options for securing the whole thing were considered. Laksminath noted we are _accustomed_ to see web server and client model for these (DTLS, etc). For both side authentication we need certificates. There some alternatives that could be using EAP to provide base for client side authentication. Brian pointed out that the DTLS approach considered doesn't work anyway because the norm sender can't demultiplex the different NORM feedback traffic arriving on the same port. Brian, IPSec transport mode, multicast support replay attack, wasn't expected. After some testing arrived at a solution with two security association per receiver. Can include replay protection for sender -> receiver flow. Receiver -> sender flow can be replay protected at NORM level and avoid having it in IPsec. Norm is reasonably well protected against feedback. Laksminath questioned if the 16-bit nack sequence number is very slow to wrap? Brian, yes, feedback traffic is sparse. Laksminath asked if we can consider to use a roll over counter that isn't included in packets. Brian, but that may can create some problem with dynamic groups where receivers come and leave. Lorenzo, GDOI groupkey-push: could go .... but is seems that it is likely that it need to go into the payload. Laksminath: Are you fine with the time it takes to establish the keys using GDOI? Brian: That is type of an out-of-band thing. Happens so no problem expected. Could use pre-placed keys. Laksminath: Worried by using a common key. Dan Harkins: Can affect security properties. Brian, included IPsec usage in draft. OSPF is a good example as they recently have done this work. They also have a sec requirement doc. Brian, a future solution could be to do SRTP similar solution in the EXT_AUTH header. However that is not likely yet. We are focusing on what are available now. Lorenzo commented this seems good and allow ALC to reuse a lot of this work and asked what does the AD think about this? Magnus, I think this is reasonable. Should send for sec review quite soon to determine if it seems okay. 6) Open Mobility Alliance (OMA) liaison query regarding LCT and BCAST. The liason query can be viewed at It was noted that the questioned LCT Specifications are stable and this should be rather soon moved forward for publication. Stephan Wenger volunteered to draft a response and send to the list. 7) Open Discussion Lorenzo questioned what to do with the experimental congestion control blocks? We may need to consider moving them forward later. Magnus" although there are exception mechanisms, it would be good to move them on to the same maturity as the other building blocks. Lorenzo: So far we have stated a requirement and provided examples of solutions to be used. 8) Meeting adjourned.