Tải bản đầy đủ
5 Whither IP Multicast Security? 239
Demystifying the IPsec Puzzle
multicast protocol that is computationally feasible and scalable for all groups,
all senders, and all receivers is. On the other hand, allowing the solution to
encompass too many protocols would be equally harmful, because it would
impose the burden of dealing with the disparate requirements not only on
the GC and KS but also on the individual members.
Recognizing that this problem required further investigation, in 1998
the Internet Society commissioned a research group under the umbrella of
the Internet Research Task Force (IRTF). That group, the Secure Multicast
Group (SMuG), recently released a number of documents [2, 511] setting
out the problems and issues inherent in secure IP multicast, alternative
approaches to resolve them, and components or building blocks that can be
defined separately and then combined to surmount the obstacles. Some of
the documents suggest pieces of protocols and message formats, but that level
of detail most likely will be defined by a different group within the IETF.
That will happen once this topic is considered sufficiently analyzed and
understood to be defined at the operational level.
Different multicast groups can have very different characteristics, which
affect the functional and operational priorities on which a multicast security
protocol is based. Because those characteristics generally are closely tied to
the functions and purpose of the group, it is conceivable that multiple multicast key management protocols will be necessary, each with its own specific
advantages and disadvantages. The initiator or manager of the group can
then select the optimal protocol before the group is formed; potential members will have to fall in line with that selection if they want to join.
The advantage of multicast is that each message, although destined
for multiple destinations, is processed only once by the originator. A single
packet leaves the source and travels through the network until the first routing branch. For both the sender and the network, the amounts of processing
and traffic are several orders of magnitude less than they would be if each
recipients message was processed and sent individually.
11.7 Further Reading
The sources on this topic all stem from IETF and IRTF working groups.
Most IETF Internet drafts are written in the context of a somewhat
The Unsolved Puzzle: Secure IP Multicast
understood problem. Because multicast security is still a research topic, a
number of Internet drafts fully describe the issues, along with the pros and
cons of alternative solutions. They also cite numerous other sources of information. There is a considerable amount of overlap among these documents.
A single, modular, and consistent approach is planned but has not yet been
completely laid out. Two treasure troves of multicast information and analysis are  and . IGMP is described in .  defines several problem areas
related to multicast security and suggests a series of building blocks that
could constitute the solution and the interrelationships among those components.  contains a conceptual definition of multicast SAs (GSAs) and the
KS.  describes three types of GSAs that could satisfy the multicast requirements, along with additional payloads and exchanges used for their establishment.  suggests an approach to multicast ESP (MESP), including the
requirements for special-purpose algorithms.  describes a multicast key
management scheme for large, dynamic groups.  lays out a framework
along with key management approaches for the intradomain trunk region as
well as for the interdomain leaf region.  further defines the key management protocol for the leaf region.  elucidates the issues connected with
Fenner, W., Internet Group Management Protocol, Version 2, RFC 2236, Nov. 1997.
Canetti, R., and B. Pinkas, A Taxonomy of Multicast Security Issues (Updated
Version), , Aug. 2000.
Hardjono, T., B. Cain, and N. Doraswamy, A Framework for Group Key Management for Multicast Security, , Aug. 2000.
Wallner, D., E. Harder, and R. Agee, Key Management for Multicast: Issues and Architectures, RFC 2627, June 1999.
Hardjono, T., et al., Secure IP Multicast: Problem Areas, Framework, and Building
Blocks, , Sep. 2000.
Baugher, M., T. Hardjono, and B. Weis, Group Domain of Interpretation for
ISAKMP, , Sep. 2000.
Harney, H., M. Baugher, and T. Hardjono, GKM Building Block: Group Security
Association (GSA) Definition, , Sep. 2000.
Canetti, R., P. Rohatgi, and P. Cheng, Multicast Data Security Transformations:
Requirements, Considerations, and Proposed Design, , June 2000.
Demystifying the IPsec Puzzle
 Balenson, D., D. McGrew, and A. Sherman, Key Management for Large Dynamic
Groups: One-Way Function Trees and Amortized Initialization, , Aug. 2000.
 Hardjono, T., B. Cainm, and I. Monga, Intra-Domain Group Key Management
Protocol, , Sep. 2000.
 McDaniel, P., et al., Multicast Security Policy, , May 2000.
The Whole Puzzle: Is IPsec the Correct
.da dlejc ,da kesde da kesd :xme` ba ba pa
ej:d zea` iwxs
Ben Bag Bag says: Turn it over and turn it over, for all is contained
Mishnah Avot 5:26
We have now described the various facets of IPsec. Some of them are mature
in both definition and implementation, some are still in the testing stage,
and others as yet have not been fully fleshed out. It is now time to summarize
the pluses and minuses of IPsec, its major competitors, and its future.
We have seen that IPsec has the potential to add a needed layer of
security to Internet traffic. The protections that it can provide include source
authentication, message integrity and confidentiality, replay protection,
some protection from traffic analysis, and some types of access control.
Those protections qualify IPsec to be used in the creation of VPNs. A fully
fleshed-out and agreed-on IPsec could be used to protect not only Internet
traffic but the Internets infrastructure.
When a protocol is used extensively to protect infinite variations on
multiple axes (configuration, policy, types of users, etc.), it risks two opposing types of failure. One is that it will become so complex that it cannot
Demystifying the IPsec Puzzle
possibly be implemented correctly, let alone in a secure manner. The other is
that it will not meet the needs of so many of its proponents that they will be
forced to add nonstandard or proprietary extensions. That is the tightrope
walked by IPsec.
12.1 Advantages of IPsec
What are the pluses of IPsec protection? The level at which it is provided, the
IP layer, is a major advantage. That means all types of Internet traffic can be
IPsec protected, independent of the specific applications that conduct the
communications. The applications do not need to be aware of the protection
and do not need to be altered in any way to enable it. It also means that the
granularity of protection can vary widely: A single SA can protect all communications between two hosts or two networks, just specific types of traffic, a
single application-specific session, or many intermediate gradations of coverage. The level and type of IPsec protection to be applied, as well as the keys
to provide that protection, are both flexible and negotiable.
Just as specific applications do not have to be IPsec aware, so too users
can be protected in spite of themselves. A network administrator can determine and enforce either networkwide or host-specific policies. Individual
users can be prevented from altering those policies; they can be allowed to
strengthen the preset policies but be forbidden from diluting or weakening
them; or they can be afforded total control over their own individual
A distinct advantage of IPsec is that it can be deployed incrementally;
unlike other network-related protocols or technologies, it is not an all-ornothing proposition. A business that leases private communication lines
to link multiple sites can replace one of those lines with an IPsec-protected
VPN connecting two sites. Once the kinks are worked out on that relatively
limited segment, the private lines can gradually be replaced by IPsec VPNs
linking all the sites. IPsec can be easily applied to create various flavors of
VPNs: intranets, extranets, and multiple combinations. But IPsec is not limited to enterprisewide use. A road warrior who accesses a PC, located either at
home or at work, from a laptop can decide to use IPsec to protect those
communications. If the PC is at a business location protected by a firewall,
the firewall must allow these strange new packet headers to pass through the
Thus, the flexibility and the power of IPsec are its strongest
The Whole Puzzle: Is IPsec the Correct Solution?
12.2 Disadvantages of IPsec
What are some of the minuses? The use of IPsec carries a cost: additional
processing and increased packet size. That includes the IKE traffic that precedes the IPsec-protected communications, as well as the additional information added to each IPsec-protected packet. Moreoever, IPsec as it exists today
is not for the faint of heart. It can require quite a bit of network-level tinkering. Those who install IPsec but are not sufficiently knowledgeable about
the options not only risk disruption of network communications but serious
security breaches. Like any entity that has been designed through a consensus
process, IPsec is not always as streamlined or as consistent as it might have
been. But, on balance, even its detractors have great hopes and expectations
for its future expansion and use.
12.3 Alternatives to IPsec
For businesses or individuals looking to improve their Internet security, a
number of alternatives to IPsec are currently in widespread use.
12.3.1 Transport Layer Security Protocol
Originally developed by Netscape and known as the Secure Sockets Layer
(SSL), the Transport Layer Security (TLS)  Protocol was subsequently
adopted, renamed, and slightly modified by the IETF. It is a session-oriented
protocol that provides security at the transport layer, a higher layer in the
TCP/IP protocol stack than IP. It can more easily provide individual userlevel access protection than the current IPsec. However, that comes at a
price: Applications that use TLS must be modified for the purpose, and each
individual session must establish its own TLS protection. Moreover, TLS can
protect only applications that run over TCP. TLS is currently used to protect
browser traffic and quite possibly could continue to be used for that purpose
even after IPsec has been more universally deployed.
12.3.2 Layer 2 Tunneling Protocol
The Layer 2 Tunneling Protocol (L2TP)  is an extension of the Point-toPoint Protocol (PPP) , which was developed to incorporate dial-up traffic
into an IP network. PPP allows a dial-up user to connect with its destination
and authenticate through the use of a protocol such as RADIUS. It then creates a PPP tunnel, encapsulating the phone link in an IP packet, enabling the