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

[Brian Adamson <[e-mail]>]

Thanks George, This is timely. I wasn't aware that this document was 
close to publication.  I will take a look at this.




At 7:04 PM -0400 4/14/08, [e-mail] wrote:
>Hi Brian and Pekka,
>
>With regard to this thread, the relevant draft to cite is the MSEC work item
>for IPsec multicast extensions: draft-ietf-msec-ipsec-extensions-08.txt (and
>its successors). It is currently in IESG review as a proposed standard. v09
>will be out shortly.
>
>A few observations:
>
>1) The appendix A-2 specifically speaks to the NORM protocol service model
>and how to handle it in unison with multicast IPsec.
>
>2) The issue of scalable group member authentication on the NORM unicast
>flow has tradeoffs. The data origin authentication issue is discussed in
>section 4.3. The tradeoffs are discussed in the "Security Considerations"
>section 6.2.2. Regarding Group Sender authentication of an arbitrary Group
>Receiver unicast transmission, if you really need individual host
>authentication then the Group Receiver could use a digital signature on the
>ESP payload. Either an identity-based signature system or a group-specific
>public key infrastructure could avoid per Group Receiver state at the Group
>Sender endpoint.
>
>3) GSAKMP offers a mode wherein pre-shared secrets allow a member to acquire
>the group keying materials by receiving and interpreting the group rekey
>event multicast, without the overhead of a registration exchange (RFC 4535
>section 5.2.3). This capability was originally motivated by uni-directional
>satellite systems.
>
>I would suggest referencing both RFC 4301 and this document in the context
>of your security considerations.
>
>hth,
>
>   George
>
>
>  ------------------------
>
>Date: Mon, 14 Apr 2008 14:34:49 -0400
>From: Brian Adamson <[e-mail]>
>To: Pekka Savola <[e-mail]>
>Cc: [e-mail], [e-mail], [e-mail]
>Subject: Re: [Rmt] 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 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:[e-mail]>
>_______________________________________________
>Rmt mailing list
>[e-mail]
>
>
>_______________________________________________
>Rmt mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rmt


-- 
Brian
__________________________________
Brian Adamson
<http://cs.itd.nrl.navy.mil/5522>
<mailto:[e-mail]>
_______________________________________________
Rmt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rmt