[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Anycast
Multicast key management, along with other multicast security issues,
is currently being discussed at the Secure Multicast Group (SMuG) of the IRTF.
See http://www.ipmulticast.com/community/smug/ for details.
A primary goal of this IRTF group is to come up with a first-cut
prototype that can be handed over to an IETF group for standardization.
Ran
> From owner-ipsec@portal.ex.tis.com Thu Dec 17 12:33:06 1998
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> In-Reply-To: <199812162233.OAA27474@kebe.eng.sun.com>
> References: <004901be293c$7dfa8820$0100010a@irish1> from "John Irish" at
> Dec 16, 98 04:38:58 pm
> Date: Thu, 17 Dec 1998 10:05:40 -0500
> To: Dan McDonald <danmcd@Eng.Sun.Com>, irishjd@erols.com (John Irish)
> From: "Carl F. Muckenhirn" <cfm@columbia.sparta.com>
> Subject: Re: Anycast
> Cc: ipsec@tis.com
> Precedence: bulk
>
> Multicast key management isn't hard, just complex. There are already
> several RFC's on the topic (1949, 2093, 2094), with more on the way, as
> well as several current ID's.
> (http://search.ietf.org/internet-drafts/draft-ietf-ipsec-intragkm-00.txt,
> http://search.ietf.org/internet-drafts/draft-canetti-secure-multicast-taxonomy-0
> 0.txt, http://search.ietf.org/internet-drafts/draft-wallner-key-arch-01.txt)
>
> There is most definitely a lack of consensus as to how to implement various
> approaches, and which are more "efficient," if that - gaining consensus -
> is the "Hard Problem (tm)" then I might agree.
>
> carl.
>
> On 12/16/98 at 2:33 PM -0800, Dan McDonald wrote:
>
>
> >> Has there been any discussion regarding support of Anycast with IPSec and
> >> ISAKMP?
> >
> > Historically, no.
> >
> >> Due to the address change which occurs on response packets, conducting SA
> >> negotiations for a remote Anycast address creates some unique problems for
> >> ISAKMP and the SA/policy database. Is the general practice in IPSec
> >> implementations just to leave out support for Anycast?
> >
> > Anycast kinda/sorta starts its life out not unlike multicast, which we
> > already know is a Hard Problem (TM).
> >
> >> Please post any pointers or thoughts on this.
> >
> > Assuming my understanding of anycast is still up to snuff (it may not be),
> > and that you've solve multicast key distribution, what you can have happen is
> > this:
> >
> > 0.) Anycast keys are distributed, a node sends to the anycast
> > address using that IPsec SA.
> >
> > 1.) The node that handles the anycast traffic accepts the packet, and
> > turns around a response. This response is to a unicast address,
> > and if you use source address as a selector, it comes from a
> > "different" source address. This should kick off an IKE
> > negotiation.
> >
> > 2.) The remaining traffic is protected with a pair of unicast SAs
> > that were negotiatied by the anycast handler and the original
> > node.
> >
> > The way I see it, decoupling the ISKAMP "initiator" from the traffic
> > "initiator" will help here.
> >
> > Like I said, I'm assuming my anycast understanding is complete, which it
> > might not be. Also like I said, getting the anycast keys out reduces to the
> > problem of getting multicast keys out, which is very HARD.
> >
> > Dan
>
> Carl F. Muckenhirn
> Director, Engineering and Integration
> SPARTA, Inc.
> Secure Systems Engineering Division
> 9861 Broken Land Parkway, Suite 300
> Columbia, Maryland 21046
> 410.381.9400 x208
> 410.381.5559 (fax)
>