Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard

Pekka Savola <> Mon, 14 April 2008 06:35 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 5A59028C119; Sun, 13 Apr 2008 23:35:42 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB20F3A6AF0; Sun, 13 Apr 2008 23:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NkW5LPstr5WV; Sun, 13 Apr 2008 23:35:37 -0700 (PDT)
Received: from ( [IPv6:2001:670:86:3001::1]) by (Postfix) with ESMTP id F0DE03A6A3C; Sun, 13 Apr 2008 23:35:36 -0700 (PDT)
Received: from (localhost []) by (8.13.8/8.13.8) with ESMTP id m3E6ZqNq019411; Mon, 14 Apr 2008 09:35:52 +0300
Received: from localhost (pekkas@localhost) by (8.13.8/8.13.8/Submit) with ESMTP id m3E6ZptF019408; Mon, 14 Apr 2008 09:35:51 +0300
Date: Mon, 14 Apr 2008 09:35:51 +0300 (EEST)
From: Pekka Savola <>
To: Brian Adamson <>
Subject: Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard
In-Reply-To: <p06240808c425883a5645@[]>
Message-ID: <>
References: <> <> <p06240808c425883a5645@[]>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.92.1/6751/Sun Apr 13 23:15:49 2008 on
X-Virus-Status: Clean
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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 latency to the NACK-based reliability process 
> and require more buffering in the implementation to maintain state.

Some clarification would be great, as well as an explicit reference 
as, if you say, this number has already been tested and found to be 
working, and have caused no ill effects in other scales.

>> 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.

I have a bad feeling that protocol instatiations will not be able to 
develop a deployable security model based on this approach, or if it's 
done, the security models will be different for each protocol 

>>  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?

While the number of 10,000 IPsec SAs already seems to be a significant 
number, I'm more concerned about what else is required, especially 
what's required to bring up these SAs.  You will need some key 
exchange protocol, like IKEv2.  That's probably around 4-10 round 
trips per receiver to signal the SAs (and more to keep it running). 
But even more challenging, you will require some mechanism to identify 
the good receivers (and the receivers need to identify the sources, 
but that's likely easier) and tie that to the security association. 
What would be that mechanism?  Each source having a shared secret with 
each receiver would likely could prove a provisioning challenge.  Or 
you could generate each receiver a certificate and build a local 
certificate authority but that only works if all the receivers are 
under your management.  Or there could be some other mechanism.

draft-ietf-rmt-sec-discussion already provides a lot of good analysis 
on security aspects of RMT work.  Too bad it isn't referenced here and 
that it isn't finished yet.  Yet, when draft-ietf-rmt-sec-discussion 
discusses solutions, I don't see how it addresses some of the problems 
specific to this document, e.g., receiver-based attacks 
(authenticating and securing the feedback return channel; how to 
ensure the reports are valid even if they come from an authenticated 

I'd like to see that draft referenced here.  It's not clear to me 
whether it would be reasonable to ask that this document should not go 
forward until sec-discussion goes forward; if that is not reasonable, 
I believe this document's security considerations needs some 
additional work especially wrt the unicast feedback channel; section 
6.1.1 and its subsections already discusses the multicast part in some 
detail (I'm not qualified to evaluate whether that's sufficient), but 
while the first paragraph mentions unicast, it is not obvious whether 
it's fully covered in the text that follows.

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
IETF mailing list