Re: Gen-art review of draft-ietf-rmt-bb-norm-revised-05.txt
Elwyn, Thank you. I have incorporated your editorial notes below into the xml source. best regards, Brian Adamson [EMAIL PROTECTED] On Jun 27, 2008, at 3:04 PM, Elwyn Davies wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-rmt-bb-norm-revised-05.txt Reviewer: Elwyn Davies Review Date: 27 June 2008 IESG Telechat date: 3 July 2008 Summary: Ready. This update has addressed all the issues I raised in my LC review excellently. There are a couple of new and a couple of legacy editorial nits Editorial: s2.4: s/specify use/specify use of/ s3.2.3.1, para 1, last line: s/provided/providing/ s8: s/George, Gross/George Gross/? s5, end of para 3: s/if this acceptable/if this is acceptable/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-art review of draft-ietf-rmt-bb-norm-revised-04.txt
Elwyn, Pekka, et al, FYI, I have finally posted an updated version of the NACK-Based Reliable Multicast Building Blocks document: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-norm-revised-05.txt This update addresses the comments you raised including removal of references to "Router Assistance" discussion, updates to the Security Considerations and references using the suggestions of George Gross and others, various areas requiring clarification as pointed out and all of the comments that Elwyn raise below. best regards, Brian Adamson At 1:50 PM +0100 4/15/08, Elwyn Davies wrote: >I have been selected as the General Area Review Team (Gen-ART) >reviewer for this draft (for background on Gen-ART, please see >_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_). > >Please resolve these comments along with any other Last Call comments >you may receive. > > >Document: draft-ietf-rmt-bb-norm-revised-04.txt >Reviewer: Elwyn Davies >Review Date: 15 April 2008 >IETF LC End Date: 17 April 2008 >IESG Telechat date: (if known) > >Summary: >A well-written document covering some pretty complex ideas. >Technically ready for the IESG but a little up front explanation for >the naive reader would help as noted below. Referring to the RFC >3269 guidelines, the document seems to have covered all the >(relevant) bases. There might be a question mark about the >suggested congestion control mechanisms since they are pre-standard >(at best). There are also a few editorial nits. > >[Aside: The phrase 'the creation of an "early NACK" slot for these >historical NACKers' raised a chuckle here! Non-British readers may >not appreciate this.] > >Comments: > >s1. A little more explanation of just what a NACK based protocol >does would be helpful, together with a note on 'timer-based >NACK-suppression' and the idea of 'repairs' and 'repair >transmission'. > >s2.4: 'NACK implosion problems' - this may require a little explanation. > >s2.5: 'probabilistic timer-based NACK suppression' is just a piece >of jargon at this stage in the document as it stands. See comment on >s1. One thought I had was to move s2 after s3, but s3 is so large >that this may not be appropriate. > >s3.2.3.1, para 1: s/affect/effect/, s/provided/providing/ > >s3.9: Without casting aspersions on the competence of the papers >referenced as [TfmccPaper] and [PGMCC], the assertion that the >solutions described in two academic papers can meet the requirements >for congestion control might seem a little cavalier or premature > >s3.11: Since this covers one of the prime requirements of RFC 3269, >it might sit better as a top level section even though it is short. > >Editorial: >(idnits does not report any issues). > >Abstract: s/negative- acknowledgment/negative-acknowledgment/ > >s3.1: s/theFEC/the FEC/ > >s3.2.1, para 2: 'to initiate the NACK processor': s/processor/processing/? > >s3.2.1, para 3: 'For probabilistic, timer-base suppression': s/base/based/ > >s3.2.2, bullet 1.: Define what sort of logarithm is meant by 'ln' - >and later define 'exp()' > >s3.2.2, bullet 2.: The page break between page 15 and 16 is >particularly infelicitous! > >s3.2.2: The relationship between the parameters of the C routine and >the variables defined on the body of the text is not absolutely >clear. > >s3.2.2, at top of page 16: 'Alternate values may be used to for >buffer utilization, reliable delivery latency and group size >scalability tradeoffs': >s/to for/for/ probably > >s3.7, para 1: 'only the sender require RTT knowledge' either >s/sender require/sender requires/ or s//senders require/ > >s3.7.4, last para: s/therange/the range/ > >s4, end of para 3: s/if this acceptable/if this is acceptable/ -- Brian __ Brian Adamson <mailto:[EMAIL PROTECTED]> ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard
Pekka, I will provide an updated draft to address your issues below as best possible. The principal challenge is related to security and most notably key management. I hope we can avoid waiting on the more comprehensive "RMT Security Discussion" document? I agree that it would be _nice_ to be able to reference the "RMT Security Discussion" document that is in development. However it doesn't yet provide all the answers either. We have some other documents coming along, too. The most relevant is a draft describing "Simple Authentication" schemes for the RMT protocols. Our focus in RMT has been on "reliabilty" and "congestion control" for multicast which were hard problems on their own ;-). Key management, etc adds a new dimension to our transport working group, but I understand the need for it. I guess my question is whether it is acceptable to suggest a baseline "out of band" (wr2 the NACK RMT protocol) key management scheme to establish/maintain the Security Associations, keys, etc for the unicast feedback from the receivers to the sender? I.e., the sender would establish trust relationships with the receivers (and provide them with the key for the sender multicast transmission). BTW, I have actually run transport mode IPsec (w/ Linux and MacOS hosts) for multicast sender->receivers and unicast receivers->sender with 2 Security Associations configured at each node, one for the sender->receiver traffic and a common SA that all of the the receivers use for feedback to the sender. In this case, all of the receivers use a common key for the unicast feedback to the sender. The issue here is if one receiver decides to be malicious, he might generate traffic using another receiver's source address and make it hard to identify the bad behaving node. I have also tested use of transport mode IPsec with multiple unicast flows (each source with its own SA/key) multiplexed to a single receiving UDP socket (This would be analogous to a multicast sender getting unicast feedback from multiple, separately authenticated receivers). The stock IPsec implementations support this. So, the basic mechanisms to do this _exist_ providing the Security Association and key information can be put into place ... My question is if identifying an approach along these lines (IPsec with out-of-band key mgmnt) is sufficient for the NACK base reliable multicast building block? I.e., if pre-placed certificates/keys isn't good enough? In the NORM "Protocol Instantiation" document (based on this NACK building block), I do describe in more detail how to use IPsec for this as a "baseline" secure mode of operation ... some of that discussion could be moved to or duplicated in this NACKK Building Block document. Also, I think there are multiple approaches possible to address security for these protocols, depending upon how they are deployed. For example, I have also played with the MSEC GDOI key management stuff a little bit (it's a little immature still wr2 implementation) and Brian Weis indicated it might be possible that the GDOI GROUPKEY-PUSH key update message might be passed as an inband message within the reliable multicast protocol ... but there is more work to be done there. And as mentioned above, we have a couple of non-IPsec approaches in the works (TESLA and "Simple Authentication") At 9:35 AM +0300 4/14/08, Pekka Savola wrote: >Hi Brian, > >On Fri, 11 Apr 2008, Brian Adamson wrote: >>I appreciate your comments here. I plan to issue a new version of >>the draft that addresses these to the extent I can. I have some >>questions about your concerns with comments in-line below: > >Thanks for your quick response. Below I won't quote all the text if >additional clarification doesn't seem warranted. > >>But this is certainly not a "fully-baked" area. So [router >>assistance] discussion _could_ be removed ... I suppose it will >>persist in the RFC 3941 for historical purposes until there is >>further interest in the area? > >That would be my preference. > >>In fact, the U.S. Postal Service has used a NACK-based protocol to >>deliver bulk data content to a group of 10,000 - 20,000 receivers >>in a single multicast group over a fairly limited IP-based VSAT >>delivery system. This system was (and still is as far as I know) >>been used operationally on a daily basis for more than 5 years. >> >>One of the references for this document is some work I did to >>assess (and to predict) the volume of feedback of these types of >>protocols with group sizes through this scale. >> >>I can probably provide more clarification on the impact ... erring >>on the large size may add some extra late
Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard
work and it is "safer" (with respect to impact on the network) to err on a larger group size. In retrospect, the 10,000 value that was recommended was based on closer to the maximum group size that these protocols may be useful for. In fact, the U.S. Postal Service has used a NACK-based protocol to deliver bulk data content to a group of 10,000 - 20,000 receivers in a single multicast group over a fairly limited IP-based VSAT delivery system. This system was (and still is as far as I know) been used operationally on a daily basis for more than 5 years. One of the references for this document is some work I did to assess (and to predict) the volume of feedback of these types of protocols with group sizes through this scale. I can probably provide more clarification on the impact ... erring on the large size may add some extra latency to the NACK-based reliability process and require more buffering in the implementation to maintain state. > >NACK-based reliable multicast is compatible with IP security (IPsec) >authentication mechanisms [RFC4301] that are RECOMMENDED for >protection against session intrusion and denial of service attacks. > >The details how one might apply IPsec to the unicast channel are absent. >I'm not commenting on the multicast delivery part because that is somewhat >covered though details are fuzzy. Unicast has two major issues that I did >not see clearly addressed: > > 1) malicious, misconfigured or under-performing (beyond small capacity > links etc.) receivers. Is there even a way to differentiate between > these classes of receivers? When these send a lot of NACK feedback, > progress of the stream is deterred. How do you deal with this issue > (this is partly operations, protocol, and security problem)? This is an issue. I did try to point out that (but perhaps still too subtly) in the "Security Considerations" section. The idea in the text there was to point out that SSM operation eliminates direct receiver<->receiver messaging, simplifying security such that only the sender need to authenticate/trust receiver operations. For the case of IPsec, that means the sender implementation may have alot of Security Association state depending upon group size. But I thought it beyond the scope of this "Building Block" document to go into the details of this. It should more thoroughly addressed in any "Protocol Instantiations" that are made. > > 2) receiver authentication for the feedback back-channel; how could you > do it? This seems unfeasible in practise if the expected default > group sizes (e.g. the recommended default of 10,000 receivers) would > be realized. There indeed may be practical limitations on group size due to security. I suppose it is comparable to a server that would need maintain alot of simultaneous secure TCP connections? But again I am not sure it is in the scope of the NACK Building Block document to predict scalability limits of IPsec implementations? But I suppose that some language could be added to point out these issues. Would that address your concerns here? > >editorial >- > >The document header should have "Obsoletes: 3941" or similar; likewise in >abstract/introduction. > >[McastModel] refers to a (good) SSM PhD dissertation, but I'd say reference >to either RFC3569 or RFC4607 is probably more readily available and more >appropriate in the IETF context. > >1. Multicast Sender Transmission > >2. NACK Repair Process > >3. Multicast Receiver Join Policies > >1. Node (member) Identification >... > >In section 3, the building block numbering wraps around; there are two >instances of building blocks 1-3. I will fix _all_ of these. -- Brian __ Brian Adamson <mailto:[EMAIL PROTECTED]> ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
