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

Brian Adamson <adamson@itd.nrl.navy.mil> Tue, 15 April 2008 16:38 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB063A6D27; Tue, 15 Apr 2008 09:38:10 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF15D3A6D7E; Mon, 14 Apr 2008 11:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YH943JtaL36; Mon, 14 Apr 2008 11:34:33 -0700 (PDT)
Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 625AD3A6D83; Mon, 14 Apr 2008 11:34:33 -0700 (PDT)
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id m3EIYqnw012350; Mon, 14 Apr 2008 14:34:52 -0400 (EDT)
Received: from [132.250.92.151] ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2008041414345109628 ; Mon, 14 Apr 2008 14:34:51 -0400
Mime-Version: 1.0
Message-Id: <p06240809c429233326e2@[132.250.92.151]>
In-Reply-To: <alpine.LRH.1.10.0804140835390.16919@netcore.fi>
References: <20080403140021.9211F28C5C9@core3.amsl.com> <alpine.LRH.1.10.0804071058380.23953@netcore.fi> <p06240808c425883a5645@[132.250.92.151]> <alpine.LRH.1.10.0804140835390.16919@netcore.fi>
Date: Mon, 14 Apr 2008 14:34:49 -0400
To: Pekka Savola <pekkas@netcore.fi>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard
X-Mailman-Approved-At: Tue, 15 Apr 2008 09:38:08 -0700
Cc: macker@itd.nrl.navy.mil, ietf@ietf.org, rmt@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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 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 
>instantiation...
>
>>>  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 receiver).
>
>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


-- 
Brian
__________________________________
Brian Adamson
<mailto:adamson@itd.nrl.navy.mil>
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf