This makes perfect sense when you think about it from the perspective of what RFC2401 says about the topic. It says that technically the proxy ACL could be ANYTHING including multicast traffic, but at this time there is no key distribution method. It says that all multicast group members should use the same key, but basically there is no way for everybody to have the same key. Think about Peter's scenario and it makes sense. R1 and R2 could potentially establish an isakmp SA and generate ipsec SA keys through DH exchange, but there would be no possible way for R3 to also get that same set of keys without some sort of key distribution protocol.
On Wed, Mar 7, 2012 at 7:40 AM, Peter Debye <[email protected]> wrote: > Kings, > try to set three (three, not 2) routers talking OSPF over a LAN, > use crypto with permit ospf on phy interfaces. You'll see that, while > in the case of only two routers the OSPF works (and multicast is > encapsulated IP[ESP[mcastIP]], then, adding the 3rd router everyting > breaks apart. > To make it work you create static VTIs (i.e. p2p links) between three > peers with mode and protection set to ipsec. Note how OSPF will change > from bcast to p2p type... > > This proves the conclusion that to make multicast work over > ipsec you need p2p mesh between peers. > =================================== > > > On 7 March 2012 07:17, Joe Astorino <[email protected]> wrote: >> I was talking about multicast as a destination IP address in the >> original IP header. >> >> On Wed, Mar 7, 2012 at 1:03 AM, Kingsley Charles >> <[email protected]> wrote: >>> If you have "permit ip any any", crypto maps will encrypt multicast >>> and I have confirmed it with wireshark using AH. >>> >>> >>> Here, we are talking about two things - Multicast in the payload and >>> Multicast in the IPsec IP header. >>> >>> Multicast in the IPsec IP header has not been addressed in the rfcs. >>> Are we talking about that? >>> >>> >>> With regards >>> Kings >>> >>> On Tue, Mar 6, 2012 at 10:17 PM, Peter Debye <[email protected]> wrote: >>>> We were able to protect IP multicast with good old IPSEC cryptomaps >>>> when applying them to GRE tunnels. Functionally, there's no >>>> difference with the newer VTI. For GRE tunneled traffic you >>>> said "permit all gre" in your crypto, and then the traffic to protect >>>> was chosen according to IP routing tables for unicast or multicast. >>>> The same way you say: "permit all ip sent to VTI". >>>> Pobably, your question is: Why do we need a tunnel interface >>>> in both cases? Why don't we apply a multicast crypto to a physical >>>> interface directly? -- I guess that for multicast implemented the way >>>> we are discussing we need p2p interfaces between peers. The physical >>>> router interfaces are not in p2p mode in all cases. Imagine what will >>>> happen if you have several routers connected to a LAN... >>>> >>>> ============================================= >>>> -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
