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... >> >> ============================================= >> >> >> On 6 March 2012 17:04, Joe Astorino <[email protected]> wrote: >>> I have one more question for you Peter if you don't mind. How would >>> this differ from a plain old fashioned crypto map whereby we are >>> running ESP in tunnel mode with a proxy ACL configured as "permit ip >>> any any". From an IP stack perspective this and the VTI >>> implementation look the same, but we were NOT able to do multicast >>> with the old style crypto map configuration. >>> >>> In other words -- With a plain crypto map configuration applied >>> matching a "permit ip any any" ACL and using ESP tunnel mode my stack >>> looks like this: >>> [IP][ESP][IP][L4][DATA] but I can NOT do multicast. >>> >>> With a VTI using ESP tunnel mode the implied crypto map behind the >>> scenes is the same "permit ip any any" , my stack looks exactly the >>> same, and I CAN multicast. What is the difference? >>> >>> On Tue, Mar 6, 2012 at 10:53 AM, Peter Debye <[email protected]> wrote: >>>> Yes, exactly. >>>> While IP multicast implementation with cisco IPSEC VTI (end to end) is >>>> possible, it requires that each IP multicast router on the SPT path >>>> performs decryption/encryption of each packet it has to forward. >>>> ==================================== >>>> >>>> On 6 March 2012 15:44, Joe Astorino <[email protected]> wrote: >>>>> No, that is perfect, we are all learning! (at least I am). That makes >>>>> sense. So a true "native" IP multicast with IPSEC would by your >>>>> definition HAVE to run in transport mode with a stack looking somewhat >>>>> like this: [IP][ESP][L4][DATA][ESP Trail] whereby the IP header has a >>>>> destination multicast address >>>>> >>>>> On Tue, Mar 6, 2012 at 4:51 AM, Peter Debye <[email protected]> wrote: >>>>>> The "native" support for IP multicast by IPSEC would be: >>>>>> the IP header (outer and the only one) with IP multicast >>>>>> destination address, and the payload protected by IPSEC. >>>>>> IPSEC cannot do this in cisco implementation. Period. >>>>>> All that VTI does is encapsulating mcast in IP unicast, >>>>>> and replicating it to p2p links using unicast encr. key. >>>>>> This is not multicast functionality in a strict sense, just >>>>>> a workaround. No real muticast implementation would ever relay on >>>>>> that, except for maybe routing protocols (that are p2p implemented >>>>>> here). >>>>>> Sorry if didn't understand properly your initial doubt which >>>>>> was just about the proxy kludge. >>>>>> ===================================== >>>>>> On 5 March 2012 21:01, Joe Astorino <[email protected]> wrote: >>>>>>> I think I have my answer after talking to a colleague I very much >>>>>>> trust on this topic : ) The "exception" is because of the proxy ACL >>>>>>> associated with a VTI interface, which is "permit ip any any". Even >>>>>>> though technically ESP is encapsulating and encrypting an IP packet >>>>>>> with a multicast destination address, that is OK because the Proxy ACL >>>>>>> is not specifying a multicast address. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 5, 2012 at 2:35 PM, Joe Astorino >>>>>>> <[email protected]> wrote: >>>>>>>> Thanks Peter for the reply. Since the IPSEC standards do not allow >>>>>>>> for the encryption/encapsulation of an IP packet with a destination >>>>>>>> address in the multicast range (224.0.0.0/4), would it be correct to >>>>>>>> say that the Cisco VTI implementation itself somehow "gets around" >>>>>>>> this? Specifically, when the router goes to encapsulate the original >>>>>>>> packet destined to some multicast group address into ESP or AH, >>>>>>>> normally that would raise a red flag so to speak. I am guessing Cisco >>>>>>>> put in a bit of code when using VTI to basically say "It's OK to do >>>>>>>> this now" >>>>>>>> >>>>>>>> For example, lets say we have R1 and R2 and these are connected to >>>>>>>> each other via a VTI interface. The tunnel addresses are 10.0.0.1/30 >>>>>>>> and 10.0.0.2/30 respectively. We run EIGRP over the VTI interface, >>>>>>>> which uses multicast. When R1 sends an EIGRP multicast hello packet >>>>>>>> destined to 224.0.0.10 the original IP packet looks like this: >>>>>>>> >>>>>>>> Source: 10.0.0.1 >>>>>>>> Destination: 224.0.0.10 >>>>>>>> >>>>>>>> Now, at this point the router IPSEC process has to make a conscious >>>>>>>> choice to encapsulate an IP packet destined to a multicast address >>>>>>>> into ESP. If I understand correctly, "normal" IPSEC forbids this from >>>>>>>> happening because of the destination address being a multicast. The >>>>>>>> VTI implementation must make an exception for this and basically say >>>>>>>> "Encapsulate/encrypt this anyways, and send it to the outbound IPSEC >>>>>>>> SA associated with this tunnel interface. Use the unicast encryption >>>>>>>> keys negotiated by IPSEC Phase 2 for this specific SA" >>>>>>>> >>>>>>>> Is that about right? >>>>>>>> >>>>>>>> On Mon, Mar 5, 2012 at 1:31 PM, Peter Debye <[email protected]> wrote: >>>>>>>>> Joe, >>>>>>>>> you're right in that the reason IPSEC doesn't forward IP >>>>>>>>> broad/multicast >>>>>>>>> is the lack of common encryption key distribution mechanism - >>>>>>>>> evidently, >>>>>>>>> this key must be the same on all clients/group members. >>>>>>>>> >>>>>>>>> You may view IPSEC as a collection of point-to-point links over a >>>>>>>>> non-broadcast medium. The usual strategy for multicast support over >>>>>>>>> such media is just replicating the packet to each p2p link the router >>>>>>>>> has. >>>>>>>>> The VTI does the same thing - the packet is copied to all IPSEC >>>>>>>>> tunnels that lead to mcast group members, and is encrypted >>>>>>>>> individually (with corresponding unicast encr key) on each tunnel. >>>>>>>>> In case of IP multicast IP PIM takes care of replicating packets >>>>>>>>> to necessary tunnels only. >>>>>>>>> Evidently, the drawback of this method is, e.g., the spoke-to-spoke >>>>>>>>> communication in a hub-and-spoke topology: the hub must decrypt >>>>>>>>> and then n times encrypt each packet to simulate broadcast medium. >>>>>>>>> >>>>>>>>> BTW, the multi/broadcast key distribution IS realized in 802.11 wi-fi, >>>>>>>>> for example. >>>>>>>>> With WEP or WPA the two negotiating STAs (AP and client) derive TWO >>>>>>>>> independent keys: one - for unicast, and the other - for broadcast >>>>>>>>> frames. >>>>>>>>> ======================================================= >>>>>>>>> >>>>>>>>> >>>>>>>>> Date: Mon, 5 Mar 2012 10:30:18 -0500 >>>>>>>>> From: Joe Astorino <[email protected]> >>>>>>>>> To: OSL Security <[email protected]> >>>>>>>>> Subject: [OSL | CCIE_Security] IPSEC Theoretical Question >>>>>>>>> Message-ID: >>>>>>>>> >>>>>>>>> <CAO+ThHREhBSOm1T4xp-9Ya__VsR5ASj2KB-5=Fun7=6-skz...@mail.gmail.com> >>>>>>>>> Content-Type: text/plain; charset=ISO-8859-1 >>>>>>>>> >>>>>>>>> So, before we had the magic of VTI from Cisco, we were all told that >>>>>>>>> IPSEC did not natively support multicast. After perusing RFC2401 for >>>>>>>>> a bit, it seems the reason for this has to do with the fact that an >>>>>>>>> IPSEC SA is defined by a destination address, a security protocol and >>>>>>>>> an SPI and that destination address for all practical purposes must be >>>>>>>>> a unicast address. The RFC basically says that in THEORY the address >>>>>>>>> COULD be multicast, but there is no key management implementation >>>>>>>>> currently to support it. >>>>>>>>> >>>>>>>>> OK, we we got by with GRE over IPSEC via crypto maps or tunnel >>>>>>>>> interfaces. Then along comes VTI. If you look at the protocol stack >>>>>>>>> VTI looks just about the same as putting a crypto map on an interface. >>>>>>>>> You have something that looks like this, assuming IPSEC tunnel mode >>>>>>>>> with ESP: [Outside IP header][ESP Header][Inside IP >>>>>>>>> header][TCP/UDP/L4 Header][Data][ESP Trailer] >>>>>>>>> >>>>>>>>> My question is -- How does Cisco VTI all the sudden magically support >>>>>>>>> multicast over native IPSEC? Is it some sort of proprietary magic, or >>>>>>>>> is there a good explanation anywhere (that I have not been able to >>>>>>>>> find via the intertron) >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Joe Astorino >>>>>>>>> CCIE #24347 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> >>>>>>>> Joe Astorino >>>>>>>> CCIE #24347 >>>>>>>> http://astorinonetworks.com >>>>>>>> >>>>>>>> "He not busy being born is busy dying" - Dylan >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> Joe Astorino >>>>>>> CCIE #24347 >>>>>>> http://astorinonetworks.com >>>>>>> >>>>>>> "He not busy being born is busy dying" - Dylan >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Joe Astorino >>>>> CCIE #24347 >>>>> http://astorinonetworks.com >>>>> >>>>> "He not busy being born is busy dying" - Dylan >>> >>> >>> >>> -- >>> 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 -- 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
