- Author :
- Email : [email protected]
- Date: 2021.01.24
- Copyright: Shall not be reproduced without permission!!
- Version: ubantu – 18.04.02
- Reference:blog.csdn.net/s2603898260…
directory
One, foreword
Second, clarify the two issues
GRE encapsulation principle
4. Why not IPsec?
Five, description,
One, foreword
This question may be an interesting topic when learning IPsec protocol. The general answer is that IPsec is positioned as a point-to-point protocol during protocol design, which can be seen from IPsec SA: IPsecSA is uniquely identified by triples (destination IP address, SPI, protocol number). Destination IP addresses are unicast addresses, so an SA can correspond to only one V.P.N node. In short, ipsec does not protect multicast and broadcast packets. The proposed solution is GRE over Ipsec.
The reason is that GRE is a point-to-point protocol that encapsulates multicast and broadcast packets, but does not have confidentiality or source authentication. IPsec has the advantages of confidentiality and integrity protection, but it cannot encapsulate multicast and broadcast packets. Therefore, GRE over IPsec combines the advantages of the two protocols to encapsulate unicast, multicast, and broadcast packets and encrypt data flows.
The question is: since both are point-to-point protocols, why can’t IPsec encapsulate broadcast multicast packets, but GRE can? I have searched for this question for a long time, but there is no satisfactory answer for me, more is: to answer my reason with the conclusion, but I know the conclusion, the reason does not know, the answer is not the question. Or organize it by yourself, many of the following are personal views, if there are mistakes, welcome to correct
Second, clarify the two issues
- Question 1: Does IPsec support multicast?
- Question 2: Can IPsec protect multicast and broadcast packets?
These two questions can be considered as different problems, because the difficulty is different and the object of emphasis is different.
First of all, point one:
It emphasizes whether the IPsec protocol can establish V.P.N with only one tunnel and multiple peer devices. The local end does not need to care about several peer devices. They share the same IpsecSA for me. The root cause of this problem is the problem of ipsec protocol design. SA does not support one-to-many mode, which is also the cause of many online comments. Current common ipsec protocols do not support this function. (Multicast ipsec is supported by RFC standards.)
And then question two:
It does not require an ipsec tunnel to establish V.P.N with multiple peer ends, but only hopes that multicast and broadcast packets can be transmitted in the tunnel. This problem cannot be completely caused by the ipsec protocol itself. Whether ipsec supports this function depends on the implementation mode. What is the implementation of ipsec?
Generally, IPsec can be implemented in two modes:
- Based on the ACL
- Based on the virtual tunnel interface
2.1 based on * * * * the ACL
Based on the Acess Control List (ACL), ipsec traffic can be controlled more accurately, for example, using packet IP addresses, UDP/TCP protocols, port numbers, and application-layer protocols, making ipsec more intelligent. After an IPsec policy that references an ACL is applied to an interface (including a physical interface and a virtual interface), the packets matching the ACL on the interface are protected by IPsec.
2.2 Based on virtual Tunnel Interfaces
After the IPsec profile is applied to a tunnel interface, the IPsec protects the packets routed to the tunnel interface and protects multicast and broadcast traffic. The encapsulation mode of IPsec established in this mode must be tunnel mode. This application is also called applying IPsec on a Virtual Tunnel Interface (VTI)
Note: This mode supports protecting multicast and broadcast traffic. It works in the same way as GRE supports multicast and broadcast packets.
From these two implementation modes, it is not impossible for IPsec to encapsulate multicast and broadcast packets. In this case, it cannot be said that other protocols cannot encapsulate multicast and broadcast packets.
The following describes why GRE encapsulates multicast and broadcast packets. This is also why ipsec based on virtual interfaces can encapsulate multicast broadcast packets.
GRE encapsulation principle
The GRE tunnel protocol
GRE protocol theory is not complicated, nor does it say why multicast is supported. Therefore, I set up a GRE tunnel configuration environment based on the GRE tunnel function of the Linux system to analyze the reasons. For details about how to set up a GRE tunnel between uBANTU and CentOS VMS, see this section
Note the following when configuring the GRE function of the Linux operating system:
- addGREA tunnel actually means adding a new virtual tunnel interface
- addGREDuring a tunnel, you must specify the local peer tunnel address
- This parameter needs to be configured for the newly added virtual tunnel interfaceIPaddress
- ifGREA tunnel is connected to two subnets. You need to add a static route: DestinationIPIs the peer terminal network, and the next line is the virtual tunnel interface
- GREOnly one virtual interface can be added if the local and peer tunnel addresses are the same(That is, two different virtual interfacesGREThe same tunnel address is not allowed to drop)
- Different configurations cannot be configured for the same virtual interfaceGREThe tunnel
Based on the configuration precautions summarized above, you can conclude that each GRE tunnel is bound to a unique virtual tunnel interface, and vice versa.
What does that mean? Note The GRE number corresponds to the number of virtual tunnel interfaces. Then GRE encapsulation multicast function is not a dream. Based on this premise, I drew a simple graph (you should query the multicast routing table for multicast messages) :
Multicast packets need to be queried in the multicast routing table to determine which interfaces to forward multicast packets. By querying the multicast routing table, the router copies multiple multicast packets and forwards them to different interfaces. In other words, the packets forwarded to the GRE virtual interface are multicast packets. The GRE virtual interface has only one encapsulation policy (the one-to-one mapping relationship mentioned above). Therefore, packets can be encapsulated according to the encapsulation policy, regardless of the packet type (unicast, multicast, broadcast). Therefore, GRE supports encapsulation of multicast packets because GRE processes multicast packets after they are distributed. Encapsulation of GRE does not affect the processing of multicast packets by other interfaces because the interface holds only one copy of the multicast packet. The preceding figure shows that packets can be encapsulated repeatedly.
4. Why not IPsec?
As mentioned above, it is not IPsec that cannot be used, but ACL that cannot be used. Virtual tunnel interface can be used. The principle of using a virtual interface is the same as that of GRE encapsulation. However, ensure that each virtual interface has only one encapsulation policy. That is, multiple ipsec tunnels cannot share the same virtual tunnel interface. The following processing architectures, GRE over Ipsec or Ipsec over GRE, are relatively simple to implement. Traffic diversion can be controlled by routing.
So why not acL-based?
Ipsec based on ACLs can be configured on physical interfaces and virtual tunnel interfaces, but only those that meet the filtering conditions can be encapsulated. In addition, even if the multicast packets meet the filtering conditions, the interface may be configured with multiple IPsec ACL filtering conditions, and the multicast packets may meet multiple ACLs at the same time. In this case, it becomes a problem to use the SA of the tunnel to encapsulate the packets. No matter which TUNNEL SA is used to encapsulate multicast packets, the multicast packets become unicast packets and the multicast packets function is lost. Therefore, ipsec based on ACL cannot encapsulate multicast and broadcast packets.
Five, description,
The analysis of ipsec and GRE encapsulated multicast packets is purely my personal opinion. I’m not responsible if you make a mistake in an interview.