< draft-ietf-pim-dm-new-v2-02.txt		draft-ietf-pim-dm-new-v2-03.txt >
	Internet Engineering Task Force PIM WG		Internet Engineering Task Force PIM WG
	INTERNET DRAFT Andrew Adams (NextHop Technolgies)		INTERNET DRAFT Andrew Adams (NextHop Technolgies)
	draft-ietf-pim-dm-new-v2-02.txt Jonathan Nicholas (ITT A/CD)		draft-ietf-pim-dm-new-v2-03.txt Jonathan Nicholas (ITT A/CD)
	William Siadak (NextHop Technologies)		William Siadak (NextHop Technologies)
	October 2002		February 2003
	Expires April 2003		Expires August 2003
	Protocol Independent Multicast - Dense Mode (PIM-DM):		Protocol Independent Multicast - Dense Mode (PIM-DM):
	Protocol Specification (Revised)		Protocol Specification (Revised)
	Status of this Document		Status of this Document
	This document is an Internet Draft and is in full conformance with all		This document is an Internet Draft and is in full conformance with all
	provisions of Section 10 of RFC 2026.		provisions of Section 10 of RFC 2026.
	Internet Drafts are working documents of the Internet Engineering Task		Internet Drafts are working documents of the Internet Engineering Task
	skipping to change at page 50, line 18 ¶		skipping to change at page 50, line 18 ¶
	is large, they may be assigned as First Come First Served as defined in		is large, they may be assigned as First Come First Served as defined in
	[7]. Such assignments are valid for one year, and may be renewed.		[7]. Such assignments are valid for one year, and may be renewed.
	Permanent assignments require a specification as defined in [7].		Permanent assignments require a specification as defined in [7].
	7. Security Considerations		7. Security Considerations
	The IPsec authentication header [8] MAY be used to provide data		The IPsec authentication header [8] MAY be used to provide data
	integrity protection and groupwise data origin authentication of PIM		integrity protection and groupwise data origin authentication of PIM
	protocol messages. Authentication of PIM messages can protect against		protocol messages. Authentication of PIM messages can protect against
	unwanted behaviors caused by unauthorized or altered PIM messages. In		unwanted behaviors caused by unauthorized or altered PIM messages. In
	any case, PIM router SHOULD NOT accept and process PIM messages from		any case, a PIM router SHOULD NOT accept and process PIM messages from
	neighbors unless a valid Hello message has been received from that		neighbors unless a valid Hello message has been received from that
	neighbor.		neighbor.
	We should note that PIM-DM has no rendezvous point, and therefore no		We should note that PIM-DM has no rendezvous point, and therefore no
	single point of failure that may be vulnerable. It is further worth		single point of failure that may be vulnerable. It is further worth
	noting that because PIM-DM uses unicast routes provided by an unknown		noting that because PIM-DM uses unicast routes provided by an unknown
	routing protocol, it may suffer collateral effects if the unicast		routing protocol, it may suffer collateral effects if the unicast
	routing protocol is attacked.		routing protocol is attacked.
	7.1. Attacks Based on Forged Messages		7.1. Attacks Based on Forged Messages
	skipping to change at page 51, line 32 ¶		skipping to change at page 51, line 32 ¶
	same impact as a forged Assert message, having the same general		same impact as a forged Assert message, having the same general
	functions. In addition, forged State Refresh messages would be		functions. In addition, forged State Refresh messages would be
	propagated downstream and might be used in a denial of service		propagated downstream and might be used in a denial of service
	attack. Therefore, a PIM-DM router SHOULD rate limit State Refresh		attack. Therefore, a PIM-DM router SHOULD rate limit State Refresh
	messages propagated.		messages propagated.
	7.2. Non-cryptographic Authentication Mechanisms		7.2. Non-cryptographic Authentication Mechanisms
	A PIM-DM router SHOULD provide an option to limit the set of neighbors		A PIM-DM router SHOULD provide an option to limit the set of neighbors
	from which it will accept PIM-DM messages. Either static configuration		from which it will accept PIM-DM messages. Either static configuration
	of IP addresses or an IPsec security association may be used. All		of IP addresses or an IPSec security association may be used. All
	options that restrict the range of addresses from which packets are		options that restrict the range of addresses from which packets are
	accepted MUST default to allowing all packets.		accepted MUST default to allowing all packets.
	Furthermore, a PIM router SHOULD NOT accept protocol messages from a		Furthermore, a PIM router SHOULD NOT accept protocol messages from a
	router from which it has not yet received a valid Hello message.		router from which it has not yet received a valid Hello message.
	7.3. Authentication Using IPsec		7.3. Authentication Using IPsec
	The IPsec [8] transport mode using the Authentication Header (AH) is the		The IPSec [8] transport mode using the Authentication Header (AH) is the
	recommended method to prevent the above attacks in PIM. The anti-replay		recommended method to prevent the above attacks in PIM. The specific AH
	option provided by IPsec SHOULD also be enabled. The specific AH
	authentication algorithm and parameters, including the choice of		authentication algorithm and parameters, including the choice of
	authentication algorithm and the choice of key, are configured by the		authentication algorithm and the choice of key, are configured by the
	network administrator. The Encapsulating Security Payload (ESP) MAY also		network administrator. The Encapsulating Security Payload (ESP) MAY also
	be used to provide both encryption and authentication of PIM protocol		be used to provide both encryption and authentication of PIM protocol
	messages. When IPsec authentication is used, a PIM router SHOULD reject		messages. When IPsec authentication is used, a PIM router SHOULD reject
	(drop without processing) any unauthorized PIM protocol messages.		(drop without processing) any unauthorized PIM protocol messages.
	To use IPsec, the administrator of a PIM network configures each PIM		To use IPSec, the administrator of a PIM network configures each PIM
	router with one or more Security Associations and associated SPI(s) that		router with one or more Security Associations and associated SPI(s) that
	are used by senders to sign PIM protocol messages and are used by		are used by senders to sign PIM protocol messages and are used by
	receivers to authenticate received PIM protocol messages. This document		receivers to authenticate received PIM protocol messages. This document
	does not describe protocols for establishing Security Associations. It		does not describe protocols for establishing Security Associations. It
	assumes that manual configuration of Security Associations is performed,		assumes that manual configuration of Security Associations is performed,
	but it does not preclude the use of some future negotiation protocol		but it does not preclude the use of some future negotiation protocol
	such as GDOI [16] to establish Security Associations.		such as GDOI [15] to establish Security Associations.
	The network administrator defines a Security Association (SA) and		The network administrator defines a Security Association (SA) and
	Security Parameters Index (SPI) that is to be used to authenticate all		Security Parameters Index (SPI) that is to be used to authenticate all
	PIM-DM protocol messages from each router on each link in a PIM-DM		PIM-DM protocol messages from each router on each link in a PIM-DM
	domain. Note that if the same SA is used by different sending routers on		domain.
	the same link, anti-replay mechanisms could prevent the acceptance of
	legitimate PIM-DM messages.		Note that if the same SA is used by different sending routers on
			the same link, it will not be possible to authenticate the individual
			sender precisely and anti-replay mechanisms would prevent the
			acceptance of legitimate PIM-DM messages, so IPSec's Replay Protection
			would need to be disabled.
	The Security Policy Database at a PIM-DM router should be configured to		The Security Policy Database at a PIM-DM router should be configured to
	ensure that all incoming and outgoing PIM-DM packets use the SA		ensure that all incoming and outgoing PIM-DM packets use the SA
	associated with the interface to which the packet is sent. Note that,		associated with the interface to which the packet is sent. Note that,
	according to [8], there is nominally a different Security Association		according to [8], there is nominally a different Security Association
	Database (SAD) for each router interface. Thus, the selected Security		Database (SAD) for each router interface. Thus, the selected Security
	Association for an inbound PIM-DM packet can vary depending on the		Association for an inbound PIM-DM packet can vary depending on the
	interface on which the packet arrived. This fact allows the network		interface on which the packet arrived. This fact allows the network
	administrator to use different authentication methods for each link,		administrator to use different authentication methods for each link,
	even though the destination address is the same for most PIM-DM packets,		even though the destination address is the same for most PIM-DM packets,
	skipping to change at page 53, line 49 ¶		skipping to change at page 53, line 49 ¶
	[1] S.E. Deering, "Multicast Routing in a Datagram Internetwork",		[1] S.E. Deering, "Multicast Routing in a Datagram Internetwork",
	Ph.D. Thesis, Electrical Engineering Dept., Stanford University,		Ph.D. Thesis, Electrical Engineering Dept., Stanford University,
	December 1991.		December 1991.
	[2] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast		[2] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast
	Routing Protocol", November 1988, RFC 1075		Routing Protocol", November 1988, RFC 1075
	[3] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol		[3] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol
	Independent Multicast - Sparse Mode (PIM-SM)",		Independent Multicast - Sparse Mode (PIM-SM)",
	draft-ietf-pim-sm-v2-new-05.txt, work in progress.		draft-ietf-pim-sm-v2-new-06.txt, work in progress.
	[4] S.E. Deering, "Host Extensions for IP Multicasting", August 1989,		[4] S.E. Deering, "Host Extensions for IP Multicasting", August 1989,
	RFC 1112.		RFC 1112.
	[5] W.Fenner, "Internet Group Management Protocol, Version 2",		[5] W.Fenner, "Internet Group Management Protocol, Version 2",
	November 1997, RFC 2236.		November 1997, RFC 2236.
	[6] IANA, "Address Family Numbers", linked from		[6] IANA, "Address Family Numbers", linked from
	http://www.iana.org/numbers.html.		http://www.iana.org/numbers.html.
	[7] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA		[7] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", October 1998, RFC 2434.		Considerations Section in RFCs", October 1998, RFC 2434.
	[8] S. Kent, R. Atkinson, "Security Architecture for the Internet		[8] S. Kent, R. Atkinson, "Security Architecture for the Internet
	Protocol", November 1998, RFC 2401.		Protocol", November 1998, RFC 2401.
	[9] H.Holbrook, B. Cain, "Source Specific Multicast for IP",		[9] H.Holbrook, B. Cain, "Source Specific Multicast for IP",
	draft-holbrook-ssm-00.txt, work in progress.		draft-ietf-ssm-arch-01.txt, work in progress.
	[10] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan,		[10] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan,
	"Internet Group Management Protocol, Version 3",		"Internet Group Management Protocol, Version 3",
	draft-ietf-idmr-igmp-v3-09.txt, work in progress.		October 2002, RFC 3376.
	[11] D. Thaler, "Interoperability Rules for Multicast Routing		[11] D. Thaler, "Interoperability Rules for Multicast Routing
	Protocols", October 1999, RFC 2715		Protocols", October 1999, RFC 2715
	[12] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol		[12] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol
	Independent Multicast MIB for IPv4", October 2000, RFC 2934		Independent Multicast MIB for IPv4", October 2000, RFC 2934
	[13] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)		[13] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", December 1998, RFC 2460.		Specification", December 1998, RFC 2460.
	[14] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional		[14] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
	Protocol Independent Multicast", draft-ietf-pim-bidir-04.txt,		Protocol Independent Multicast", draft-ietf-pim-bidir-04.txt,
	work in progress.		work in progress.
	[15] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Bootstrap Router		[15] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group Domain of
	(BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-02.txt,		Interpretation", draft-ietf-msec-gdoi-07.txt, work in progress.
	work in progress.
	[16] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group Domain of
	Interpretation", draft-ietf-msec-gdoi-03.txt, work in progress.
End of changes. 12 change blocks.
	16 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/