RMT minutes IETF66 Montreal Lorenzo Vicisano, WG chair Vincent Roca, note taker and editor ---------------------------------------------------------------- ----------------------------------------------------------------- 1- WG Status Update Chairs 2- RMT BBs to Standard Track and Security ADs/Chairs 3- NORM Security Discussion Brian Adamson 4- TESLA for NORM Vincent Roca draft-ietf-msec-tesla-for-alc-norm-00.txt 5- LDPC and Reed-Solomon FEC IDs Vincent Roca draft-ietf-rmt-bb-fec-ldpc-02.txt draft-ietf-rmt-bb-fec-rs-01.txt 6- Norm BB an PI revised for Standard Track Brian Adamson draft-ietf-rmt-pi-norm-revised-03 draft-ietf-rmt-bb-norm-revised-0 ------------------------------------------------------------------- 1- WG Status Update ------------------- * Most of the drafts that need to go to PS are almost ready, namely: FEC BB, ALC, LCT, FEC Basic Schemes, FLUTE, NORM PI and NORM BB. The situation of the various I-D is quickly presented by the respective authors. In particular: - Lorenzo: after the Digital Fountain IPR statement change, the WG agreed to continue the standardization process. Mark says there's no change between I-D version 3 and 4. - Vincent: FLUTE I-D will be slightly clarified, taking into account the comments sent on the list in June. * anything left over ? - Vincent: he still wants to update the FLUTE object aggregation I-D (now expired)... Lorenzo reminds that it's better to hurry up. - Lorenzo: the WG milestones needs to be updated 2- RMT BBs to Standard Track and Security ----------------------------------------- (point raised by Magnus Westerlund on the ML) Magnus: having specifications (BBs, PIs) on the STD track without any detailed guidelines on how to implement security services is not reasonable. Hence this discussion... Lorenzo: there are many possible goals which makes this discussion (and recommendations) difficult. The highest security goal is probably to protect the network, a lower goal is to protect the protocol itself, and an even lower goal is to protect the objects being transported. Magnus agrees that there is a hierarchy of possible goals, but it does not mean that we can ignore them altogether. Lorenzo: one initial RMT's goal was scalability, and therefore it was decided that the source should not know the identity of the receivers. As a consequence, it makes some security requirements more complex to achieve. George Gross: Scalability was one of the goals also for MSEC too (e.g. for key management). Many BBs developed in MSEC will come for free. Lorenzo: Do we need any modification to the protocols defined in MSEC to use them in RMT? George reminds the group that IPsec has been redesigned recently in order to support multicast. Lorenzo: We are not standardizing the application, but the transport. As RMT is providing transport solutions, is there any need to bother with application topics? George: IPsec is one solution, but the question is whether we want to use it (there are limitations) or want provide security in the application layer? Magnus: If we want to do that on a lower layer (i.e. with IPsec) we need to specify a profile for it here. The discussion now focusses on the above three goals (content, network and protocol protection): 1) Content protection: Magnus: The provider of the content has its own opinion on how to protect the content. Lorenzo: It's not the problem of RMT to provide content protection. We can say we need a WG in the application level to address this problem. Magnus agrees with Lorenzo. Mark: Yet but we must keep in mind that there's an urgent need to make progress. Many people are using FLUTE/ALC now... Magnus: Confidentiality issue is the last problem to solve. There are more important problems to solve first. 2) Network protection: Lorenzo: Network protection in our case means protecting the network from congestion. What is the situation ? Brian: There is a potential attack to TFMCC (used by NORM). The sender can slow down because of a malicious receivers who says to be a bad node. George explains that against this kind of receiver feedback attack, the only solution is to provide group key management and to use digital signatures. This technique can enable the sender to decide whether a receiver who sends feedback is an authorized member of the group or not. But a requirement is to use a key management infrastructure... 3) Protocol protection: One possible goal is to protect the transport protocol against nodes that want to stop the protocol. Lorenzo: Can we mandate the use of SSM to protect NORM? Magnus answers that an attacker having control over the network can easily spoof the source, so using SSM does not really solve the problem. George: Using public keys, a certificate authority and digital signature can help... The new version of IPsec, that features multicast extensions, is another way to achieve that goal. Lorenzo suggests to ask the MSEC WG to have it a WG item. He also suggests to add in the security requirement of NORM a note explaining that this scheme can be used. Gorry: Why do we go to SSM? Lorenzo explains there's a potential solution for TFMCC if we mandate the use of SSM. It seems a realistic assumption. Brian explains that with SSM, a receiver can still slow down the sender but cannot break the network. Lorenzo: A possible solution, for TFMCC, is to say that if the sender receives contradicting feedback, then he should trust the worst one. Gorry explains that in case of the ALC layer congestion control scheme, there's an incentive to receive at a higher rate even if it breaks the network (i.e. by not being fair with other TCP flows). Lorenzo: Is there any work in unicast to address the problem? What about a TCP receiver that acknowledges each packet even if he didn't receive them? It can happen in NORM and ALC but also in TCP. It seems to be a very tough problem since it needs to involve the routers. Somebody explains that the problem is that we trust the host to do the congestion control. In TCP, if a receiver misbehaves, he will probably be the only one to be hurt. Lorenzo: So we have a very big problem here... But we are only opening issues, we are not solving them! Magnus explains that we definitively need a few volunteers to analyze the problems and the possible answers. Vincent, Gorry, George and Brian volunteer to work on a document to address this. NORM specific security issues (Brian Adamson, NRL) -------------------------------------------------- Brian quickly goes through the slides since some topics have already been discussed. NORM specific issues: - sender->receiver traffic - receiver->sender traffic: NACK replay attack is extremely serious; CC feedback too. - receiver->receiver traffic: it occurs with ASM. Rogue messages directed to receivers could cause erroneous suppression of feedback. There's also a privacy concern. One key feature of NORM is the end-host identification (NormNodeID). A question is: what can or cannot be expected from IPsec? Source authentication, integrity check, confidentiality, anti-replay. Somebody explains that there are strict restrictions on the way multicast cast can be managed by the the IPsec mcast extension. Yes, it can be done, but sometimes it requires manual configuration. George explains that it also depends if there a single group speaker or several. TESLA BB (Vincent Roca) ----------------------- This I-D is now an MSEC WG item. Yet, as done before, Vincent will continue to present the progress to both WGs. Lorenzo: does this proposal offer an answer to the security issue discussed? Vincent: Yes, in parts. There are situations where TESLA can be used in a very effective way to address the basic source authentication and content integrity requirements of ALC and NORM. But with NORM, it only addresses the sender->receiver traffic... A complementary system has to be used in that case for the client->sender traffic (e.g. digital signatures). Reed-Solomon FEC BB (Vincent Roca) ---------------------------------- Vincent introduces the changes to the new version. The big question raised is to decide whether the new FPI format (which includes two variable-length fields) is in line with the FEC BB guidelines or not. Lorenzo, Mark, Brian all agree with the change in the FPI. Vincent: So the document can enter WGLC. LDPC FEC BB (Vincent Roca) -------------------------- Vincent explains he found a mistake in the specification recently so he will re-submit a corrected version soon. Then he thinks that the document could enter WGLC.