[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Anycast

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)
Follow-Ups: References: