< draft-bhatia-zhang-pim-auth-extension-02.txt		draft-bhatia-zhang-pim-auth-extension-03.txt >
	Network Working Group M. Bhatia		Network Working Group M. Bhatia
	Internet-Draft Alcatel-Lucent		Internet-Draft Alcatel-Lucent
	Intended status: Experimental D. Zhang		Intended status: Experimental D. Zhang
	Expires: March 6, 2013 Huawei		Expires: September 29, 2013 Huawei
	September 6, 2012		B. Joshi
			Infosys Ltd.
			March 28, 2013
	In-Band Authentication Extension for Protocol Independent Multicast		In-Band Authentication Extension for Protocol Independent Multicast
	(PIM)		draft-bhatia-zhang-pim-auth-extension-03
	draft-bhatia-zhang-pim-auth-extension-02
	Abstract		Abstract
	Existing security mechanisms for the Protocol Independent Multicast -		Existing security mechanisms for the Protocol Independent Multicast -
	Sparse Mode (PIM-SM) routing protocol mandates to use IPsec to		Sparse Mode (PIM-SM) routing protocol mandates the use of IPsec to
	provide message authenticity and integrity. This draft proposes an		provide message authenticity and integrity. This draft proposes an
	embedded authentication mechanism to facilitate data origin		embedded authentication mechanism to facilitate data origin
	authentication and integrity verification for PIM packets in the		authentication and integrity verification for PIM packets in the
	cases where IPsec is not applied.		cases where IPsec cannot be applied.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 6, 2013.		This Internet-Draft will expire on September 29, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3		2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3
	3. PIM Security Association . . . . . . . . . . . . . . . . . . . 5		3. PIM Security Association . . . . . . . . . . . . . . . . . . . 5
	4. AEP Packet Processing . . . . . . . . . . . . . . . . . . . . 6		4. PIM Packet Processing . . . . . . . . . . . . . . . . . . . . 6
	4.1. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 6		4.1. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 6
	4.2. Outbounding Packet Processing . . . . . . . . . . . . . . 8		4.2. Outbounding Packet Processing . . . . . . . . . . . . . . 7
	4.3. Inbounding Packet Processing . . . . . . . . . . . . . . . 8		4.3. Inbounding Packet Processing . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	5.1. Register Packet Processing . . . . . . . . . . . . . . . . 9		5.1. Register packet processing . . . . . . . . . . . . . . . . 9
	5.2. New Packet Type Versus Authentication Trailer . . . . . . 9		5.2. Inter-Session Replay Attack Issue . . . . . . . . . . . . 9
	5.3. Inter-Session Replay Attack Issue . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	[RFC5796] describes the methods of using the IP security (IPsec)		[RFC5796] describes the methods of using the IP security (IPsec)
	Encapsulating Security Payload (ESP) [RFC4303] or the Authentication		Encapsulating Security Payload (ESP) [RFC4303] or the Authentication
	Header (AH) [RFC4302] (which is optional) to protect the authenticity		Header (AH) [RFC4302] (which is optional) to protect the authenticity
	and integrity of the link-local messages of Protocol Independent		and integrity of the link-local messages of Protocol Independent
	Multicast - Sparse Mode (PIM-SM)[RFC4601]. [RFC5796] mandates the		Multicast - Sparse Mode (PIM-SM)[RFC4601]. [RFC5796] mandates the
	application of manual key management mechanisms and provide optional		application of manual key management mechanisms and provide optional
	support for an automated group key management mechanism. However,		support for an automated group key management mechanism. However,
	the procedures for implementing automated group key management are		the procedures for implementing automated group key management are
	left undone yet.		not specified.
	It has been clarified in [I-D.bhatia-karp-pim-gap-analysis] that		It has been clarified in [I-D.bhatia-karp-pim-gap-analysis] that
	without the support of automated group key management mechanisms, the		without the support of automated group key management mechanisms, the
	PIM packets protected by IPsec will be vulnerable to both inter-		PIM packets protected by IPsec will be vulnerable to both inter-
	session and inner-session replay attacks. In addition, the poor		session and inner-session replay attacks. In addition, the poor
	scalability of manual keying may cause deployment issues in many		scalability of manual keying may cause deployment issues in many
	typical scenarios. This document proposes a new type of PIM packet,		typical scenarios. This document proposes few changes in the PIM
	called the Authentication Extension PIM packet (AEP), which is able		header which helps in carrying authentication data along with the
	to facilitate data origin authentication and message integrity		usual PIM packet. The PIM packet contains all the essential
	verification for PIM packets without the support of IPsec. An AEP		inforamtion for data origin authentication and message integrity
	actually contains all the essential information of a PIM packet being		verification without the support of IPsec.
	protected and provides cryptographic methods for the receiver to
	assess the authenticity and integrity of the packet. In this		In this solution, it is assumed that manual keying is performed while
	solution, it is assumed that manual keying is performed while the		the automatic key management mechanisms are not precluded. A
	automatic key management mechanisms are not precluded. Within a		strictly increasing sequence number is adopted to address the replay
	packet proposed in this document, a monotonically increasing sequence		attack issues. However, the work of addressing the scalability
	number is adopted to address the replay attack issues. However, the		issues imposed by manual keying is out of scope of this draft.
	work of addressing the scalability issues imposed by manual keying is
	out of scope of this draft.
	2. Proposed Solution		2. Proposed Solution
	Figure 1 illustrates the format of an example packet header.		This document adds some more fields in PIM packet to carry the
			authentication information. Figure 1 illustrates the format of a PIM
			packet that carries authentication information.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
	|PIM Ver| Type 1| Reserved 1 | Checksum | ^
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| |Original
	| Remainder part of the packet expected | packet
	~ to be protected ~ |
	| | |
	| | v
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
	|
	|
	|
	V
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
	|PIM Ver| Type | Reserved | Checksum | ^		|PIM Ver| Type |A| Reserved | PIM Message Length | Header
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Key ID | Auth Data Len | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Cryptographic Sequence Number (High Order 32 Bits) | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
	| Cryptographic Sequence Number (Low Order 32 Bits) | of AEP
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| | |
	| Authentication Data (Variable) | |
	~ ~ |
	| | V
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
	| Type 1| Reserved 1 | | ^		| Key ID | Auth Data Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+ | |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth
	| |Protected		| Cryptographic Sequence Number (High Order 32 Bits) | Header
	| Remainder part of the packet expected | packet		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ to be protected ~ |		| Cryptographic Sequence Number (Low Order 32 Bits) |
	| | V		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
			| |
			~ PIM Message ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
			| |
			~ Authentication Data ~
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
	Figure 1. The format of an example AEP		Figure 1. Format of a PIM packet carrying authentication information
	In compliance with [RFC4601], the first four fields of the AEP header		PIM Ver: PIM Version number is 2.
	is identical to those of the original types of PIM packets.
	Particularly, the PIM Version number is set to 2. The type number of
	AEP is 9 in order to distinguish AEP from other types of PIM packets.
	The Reserved field is set to zero on transmission and ignored upon
	receipt. The checksum field of the AEP is set to zero, and the
	checksum calculation and verification are omitted.
	Other fields of in the AEP header are described as follows:		Type: Types for specific PIM messages. PIM types are defined in
			[RFC4601].
			Auth bit: If 'Auth' bit is 1, it means the PIM packet is carrying
			authentication information. If 'Auth' bit is 0, it means the PIM
			packet is not carrying authentication information and such a
			packet should be handled as specified in [RFC4601].
			Reserved: Set to zero on transmission. Ignored upon receipt.
			PIM Message Length: A 16-bit field that contains the length of the
			PIM message. This length does not include the length of the PIM
			header, PIM auth header and authentication data.
	Key ID: A 16-bit field that identifies the secret key and the		Key ID: A 16-bit field that identifies the secret key and the
	algorithm used to create the authentication data.		algorithm used to create the authentication data.
			Auth Data Len: A 16-bit field that identifies the length of the
			trailing authentication data field.
	Cryptographic Sequence Number: A 64-bit strictly increasing		Cryptographic Sequence Number: A 64-bit strictly increasing
	sequence number that is used to guard against replay attacks. The		sequence number that is used to guard against replay attacks. The
	64-bit sequence number MUST be incremented for every AEP packet		64-bit sequence number MUST be incremented for every PIM packet
	sent by a PIM router. Upon reception, the sequence number MUST be		carrying authentication. Upon reception, the sequence number MUST
	greater than the sequence number in the last AEP packet accepted		be greater than the sequence number in the last PIM packet
	from the PIM router sending the packet. Otherwise, the AEP packet		accepted from the PIM router sending the packet. Otherwise, the
	is considered a replayed packet and dropped. PIM routers		PIM packet is considered a replayed packet and dropped. PIM
	implementing this specification SHOULD use available mechanisms to		routers implementing this specification SHOULD use available
	preserve the sequence number's strictly increasing property for		mechanisms to preserve the sequence number's strictly increasing
	the deployed life of the PIM router (including cold restarts).		property for the deployed life of the PIM router (including cold
	Techniques such as sequence number space partitioning and non-		restarts). Techniques such as sequence number space partitioning
	volatile storage preservation can be used but are beyond the scope		and non-volatile storage preservation can be used but are beyond
	of this specification.		the scope of this specification.
	Authentication Data: A field with a variable length. The field		PIM Message: PIM message as specified in [RFC4601].
	carries the digest for the protocol packet and other optional
	information.
	Type 1: This 4-bit field indicate the type of the encapsulated PIM		Authentication Data: Variable length authentication data. This
	packet.		field carries the digest for the protocol packet.
	Reserved 1: This 8-bit field is identical to the Reserved field of		A PIM packet carrying authentication information does not need
	the encapsulated PIM packet. Because the Version field and the		checksum for integrity check. So 'checksum' field has been replaced
	Checksum field in the header of the encapsulated PIM packet are		with 'PIM Message Length' in a PIM packet carrying authentication
	redundant, they are removed.		information.
	3. PIM Security Association		3. PIM Security Association
	An PIM Security Association (SA) consists of a set of parameters for		A PIM Security Association (SA) consists of a set of parameters for
	PIM routers to correctly generate or verify AEP packets. In manual		PIM routers to correctly generate or verify PIM packets carrying
	keying, it is the responsibility of network operators to generate and		authentication information. In manual keying, it is the
	deploy PIM SAs amongst PIM routers appropriately to ensure the		responsibility of network operators to generate and deploy PIM SAs
	routers can exchange PIM signalling messages securely.		amongst PIM routers appropriately to ensure the routers can exchange
			PIM messages.
	The parameters associated with a PIM SA:		The parameters associated with a PIM SA:
	o Key Identifier (Key ID) : A 16-bit unsigned integer which is used		o Key Identifier (Key ID) : A 16-bit unsigned integer which is used
	to uniquely identify an PIM SA within a PIM domain.		to uniquely identify a PIM SA within a PIM domain.
	o Authentication Algorithm: This parameter is used to indicate the		o Authentication Algorithm: This parameter is used to indicate
	authentication algorithm to be used with the PIM SA. The value of		authentication algorithm to be used with the PIM SA. The value of
	this parameter can be implementer specific. Currently, the		this parameter can be implementation specific. The following
	following algorithms SHOULD be supported: HMAC-SHA-1, HMAC-SHA-		algorithms SHOULD be supported: HMAC-SHA-1, HMAC-SHA-256, HMAC-
	256, HMAC-SHA-384, and HMAC-SHA-512.		SHA-384, and HMAC-SHA-512.
	o Key: The value of this parameter denotes the cryptographic key		o Key: The value of this parameter denotes the cryptographic key
	associated with the key ID. The length of this key is determined		associated with the key ID. The length of this key is determined
	by the algorithm specified in the PIM SA.		by the algorithm specified in the PIM SA.
	o Key Start Accept: The time after which a PIM router will accept a		o Key Start Accept: The time after which a PIM router will accept a
	packet if it is created with this PIM SA.		packet if it is created with this PIM SA.
	o Key Start Generate: The time after which a PIM router will begin		o Key Start Generate: The time after which a PIM router will begin
	using this PIM SA for PIM packet generation.		using this PIM SA for PIM packet generation.
	o Key Stop Generate: The time after which a PIM router will stop		o Key Stop Generate: The time after which a PIM router will stop
	using this PIM SA for PIM packet generation.		using this PIM SA for PIM packet generation.
	o Key Stop Accept: The time after which a PIM router will refuse to		o Key Stop Accept: The time after which a PIM router will refuse to
	accept a packet if it is generated with this PIM SA.		accept a packet if it is generated with this PIM SA.
	4. AEP Packet Processing		4. PIM Packet Processing
	4.1. Cryptographic Aspects		4.1. Cryptographic Aspects
	In the algorithm description below, the following nomenclature, which		In the algorithm description below, the following nomenclature, which
	is consistent with [FIPS-198], is used:		is consistent with [FIPS-198], is used:
	H is the specific hashing algorithm (e.g. SHA-256).		H is the specific hashing algorithm (e.g. SHA-256).
	K is the Authentication Key for the PIM security association.		K is the Authentication Key for the PIM security association.
	skipping to change at page 7, line 14 ¶		skipping to change at page 7, line 4 ¶
	Apad is a value which is the same length as the hash output or		Apad is a value which is the same length as the hash output or
	message digest. If the packet is transported upon IPv6, the first 16		message digest. If the packet is transported upon IPv6, the first 16
	octets contain the IPv6 source address followed by the hexadecimal		octets contain the IPv6 source address followed by the hexadecimal
	value 0x878FE1F3 repeated (L-16)/4 times. If the packet is		value 0x878FE1F3 repeated (L-16)/4 times. If the packet is
	transported upon IPv4, the first 4 octets contain the IPv4 source		transported upon IPv4, the first 4 octets contain the IPv4 source
	address followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4		address followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4
	times.		times.
	1. Preparation of the Key		1. Preparation of the Key
	In this application, Ko is always L octets long.		In this application, Ko is always L octets long.
	If the Authentication Key (K) is L octets long, then Ko is equal		If the Authentication Key (K) is L octets long, then Ko is equal
	to K. If the Authentication Key (K) is more than L octets long,		to K. If the Authentication Key (K) is more than L octets long,
	then Ko is set to H(K). If the Authentication Key (K) is less		then Ko is set to H(K). If the Authentication Key (K) is less
	than L octets long, then Ko is set to the Authentication Key (K)		than L octets long, then Ko is set to the Authentication Key (K)
	with zeros appended to the end of the Authentication Key (K) such		with zeros appended to the end of the Authentication Key (K) such
	that Ko is L octets long.		that Ko is L octets long.
	2. First Hash		2. First Hash
	First, the AEP packet's Authentication Data field in the AEP		First, the PIM packet's Authentication Data field is filled with
	header is filled with the value Apad.		the value Apad.
	Then, a First-Hash, also known as the inner hash, is computed as		Then, a First-Hash, also known as the inner hash, is computed as
	follows:		follows:
	If the original packet is a Register packet		If the PIM packet is a Register packet
	First-Hash = H(Ko XOR Ipad || (AEP Packet-Data Part))		First-Hash = H(Ko XOR Ipad || (PIM Packet - Data Part))
	else		else
	First-Hash = H(Ko XOR Ipad || (AEP Packet))		First-Hash = H(Ko XOR Ipad || (PIM Packet))
	The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets;		The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets;
	for SHA-384, 48 octets; and for SHA-512, 64 octets.		for SHA-384, 48 octets; and for SHA-512, 64 octets.
	3. Second Hash		3. Second Hash
	Then a second hash, also known as the outer hash, is computed as		Then a second hash, also known as the outer hash, is computed as
	follows:		follows:
	Second-Hash = H(Ko XOR Opad || First-Hash)		Second-Hash = H(Ko XOR Opad || First-Hash)
	skipping to change at page 8, line 4 ¶		skipping to change at page 7, line 40 ¶
	for SHA-384, 48 octets; and for SHA-512, 64 octets.		for SHA-384, 48 octets; and for SHA-512, 64 octets.
	3. Second Hash		3. Second Hash
	Then a second hash, also known as the outer hash, is computed as		Then a second hash, also known as the outer hash, is computed as
	follows:		follows:
	Second-Hash = H(Ko XOR Opad || First-Hash)		Second-Hash = H(Ko XOR Opad || First-Hash)
	4. Result		4. Result
	The resulting Second-Hash becomes the authentication data that is		The resulting Second-Hash becomes the authentication data that is
	sent in the AEP header. The length of the authentication data is		added in the PIM packet. The length of the authentication data is
	always identical to the message digest size of the specific hash		always identical to the message digest size of the specific hash
	function H that is being used.		function H that is being used.
	4.2. Outbounding Packet Processing		4.2. Outbounding Packet Processing
	First of all, a sender needs to find a proper PIM SA and generate a		If embedded authentication is enabled, sender first finds an
	PIM header. The checksum field of the AEP header is set as zero.		appropriate PIM security association (SA) to be used for this packet.
	The length of the Authentication Data field is determined according		Following processing is done:
	the algorithm specified in the SA. The sequence number for this SA
	is increased, and the new value is inserted into the Sequence Number		o It first prepares the PIM header and PIM auth header as follows:
	field. The Authentication Data field is set as Apad. After these,
	the sender appends the encapsulated PIM packet (without the redundant		* PIM version is set to 2
	fields) at the end of the AEP header and generates the authentication
	data as illustrated in Section 4.1. After inserting the calculated		* Type field is set to the PIM message type that is being sent.
	authentication data into the Authentication Data field, the sender
	delivers the packet.		* Auth bit is set to 1.
			* Reserved field is set to 0.
			* Key ID is set to the key-id from PIM SA
			* Auth Data Len is set to the length of the Authentication Data
			field which is determined based on the algorithm specified in
			the selected SA.
			* The sequence number for the selected SA is increased and the
			new value is inserted into the Sequence Number field.
			o It then populates the PIM message that is to be sent out. As
			length of the PIM message is now known, it is updated in the PIM
			header.
			o The Authentication Data field is set to Apad and then sender
			generates the authentication data as described in Section 4.1 for
			the PIM packet. Calculate authentication data is inserted in the
			Authentication data field.
			After this PIM packet is sent out on the idenfitied interface.
	4.3. Inbounding Packet Processing		4.3. Inbounding Packet Processing
	A router identifies a received PIM packet is an AEP by examining the		A router identifies a received PIM packet is carrying authentication
	Type field in PIM packet header. If the cryptographic sequence		data by examining the 'Auth' bit in the PIM header. If the 'Auth'
	number of the packet is less than or equal to the last sequence		bit is 1, it means the PIM packet is carrying embedded authentication
	number received from the PIM router, the AEP packet MUST be dropped.		information. Following processing is done:
	If the Checksum fields in the AEP header and in the PIM header of the
	encapsulated PIM packet are not zero, the AEP packet MUST be dropped.
	According to the key ID in the packet header, the receiver tries to		o Find the PIM SA for the Key ID available in PIM auth header in the
	find the associated PIM SA. If no valid PIM SA exists for this		PIM packet. If no valid PIM SA is found for this packet or the
	packet or the key is not in its valid period, the receiver MUST		PIM SA is not in its valid period, receiver MUST discard the
	discard the packet. If the appropriate PIM SA for the received		packet and SHOULD log an error event.
	packet is found, the receiver starts performing the authentication
	algorithm dependent processing, using the algorithm specified in the
	SA.
	In the first step, the receiver derives the cryptographic algorithm		o If the cryptographic sequence number of the packet is less than or
	from the PIM SA and identify the length of the Authentication Data		equal to the last sequence number received from the same PIM
	field. Then the receiver fills the Authentication Data field with		router, receiver MUST discard the packet and SHOULD log an error
	Apad . After this, the receiver calculate the authentication data		event.
	for the AEP as described in Section 4.1. The calculated data is
	compared with the received authentication data in AEP header. If the
	two do not match, the packet MUST be discarded. In such a case, an
	error event SHOULD be logged.
	5. Security Considerations		o Find the Auth data len expected from the PIM SA and compare it
			against the Auth Data Len in the packet. If the two do not match,
			receiver MUST discard the packet and SHOULD log an error event.
	5.1. Register Packet Processing		o Calculate the PIM message length using total packet length from IP
			header and Auth Data Len from PIM Auth Header. Compare it with
			the PIM message length in PIM header. If the two do not match,
			receiver MUST discard the packet and SHOULD log an error event.
	The solution proposed in this draft only intends to secure PIM		o Receiver stores the Authentication Data from packet locally. It
	signaling packets. The efforts of protecting data packets		then fills the Authentication Data field with Apad. Then the
	transported among PIM routers are out of scope. Therefore, for a		receiver calculates the authentication data for the PIM packet as
	register packet, only the Type field, the B field, and the N field		described in Section 4.1. The calculated authentication data is
	are secured while the Multicast data packet part is not protected by		then compared with the received authentication data in PIM packet.
	the authentication data.		If the two do not match, reciever MUST discard the packet and
			SHOULD log an error event. If the two matches, PIM message is
			passed for further processing.
	5.2. New Packet Type Versus Authentication Trailer		5. Security Considerations
	Both PIM and OSPFv3 rely on IPsec to secure packet transmission, and		5.1. Register packet processing
	they meet similar security issues, such as the vulnerability to the
	replay attacks and lack of support to priority packets.
	[I-D.ietf-ospf-auth-trailer-ospfv3] proposes an authentication
	trailer which is appended at the end of an OSPFv3 packet and provides
	IPsec independent authentication for the packet. This idea can also
	be adopted into PIM. However, compared with the OSPFv3 packet
	header, the PIM header lacks a field to point out the length the PIM
	packet. The length of the PIM packet is actually indicated by the
	length of the IP payload and can be variable. This raises a issue.
	If an authentication trailer is attached at the end of a PIM packet,
	it will be difficult to locate. This issue can be addressed by
	extending the PIM headers with an Length field.
	5.3. Inter-Session Replay Attack Issue		The solution proposed in this draft only intends to secure PIM
			singaling packets. The efforts for protecting data packets
			transported among PIM routers is out of scope. Therefore, for a
			register packet, only PIM header, PIM Auth Header, the B field and
			the N field are secured while the Multicast data packet part is not
			protected.
	When a router is rebooted , the sequence number will be re-		5.2. Inter-Session Replay Attack Issue
	initialzed. This will cause a problem. When a PIM router received a
			When a router is rebooted, the sequence number will be re-
			initialzed. This will cause a problem. When a PIM router receive a
	hello message with a changed GenID and an re-inialized sequence		hello message with a changed GenID and an re-inialized sequence
	number, it is difficult for the receiver to distinguish this message		number, it is difficult for the receiver to distinguish this message
	from a replay attack. The soltuion proposed in this document is		from a replay attack. The soltuion proposed in this document is
	subject to this problem. However, the experience in		subject to this problem. However, the experience in
	[I-D.ietf-ospf-security-extension-manual-keying] can be used to		[I-D.ietf-ospf-security-extension-manual-keying] can be used to
	address this problem. In the solution proposed in		address this problem. In the solution proposed in
	[I-D.ietf-ospf-security-extension-manual-keying], there is a reboot		[I-D.ietf-ospf-security-extension-manual-keying], there is a reboot
	counter maintained in non-violate memory which is increased by 1		counter maintained in non-volatile memory which is increased by 1
	after every reboot. The count value is set into the first 32 bits of		after every reboot. The reboot count value is set into the first 32
	the sequence number. Therefore, even after a restart, the sequence		bits of the sequence number. Therefore, even after a restart, the
	number will still be increased.		sequence number will still be increased.
	6. Acknowledgements		6. Acknowledgements
	We would like to thank Stig Venaas for his kindly review work and		We would like to thank Stig Venaas for his kind review and comments
	comments on this document.		on this document.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.2. Informative References		7.2. Informative References
	[I-D.bhatia-karp-pim-gap-analysis]		[I-D.bhatia-karp-pim-gap-analysis]
	Bhatia, M., "Analysis of Protocol Independent Multicast		Bhatia, M., "Analysis of Protocol Independent Multicast
	Sparse Mode (PIM-SM) Security According to KARP Design		Sparse Mode (PIM-SM) Security According to KARP Design
	Guide", draft-bhatia-karp-pim-gap-analysis-00 (work in		Guide", draft-bhatia-karp-pim-gap-analysis-00 (work in
	progress), April 2011.		progress), April 2011.
	[I-D.ietf-ospf-auth-trailer-ospfv3]
	Bhatia, M., Manral, V., and A. Lindem, "Supporting
	Authentication Trailer for OSPFv3",
	draft-ietf-ospf-auth-trailer-ospfv3-11 (work in progress),
	November 2011.
	[I-D.ietf-ospf-security-extension-manual-keying]		[I-D.ietf-ospf-security-extension-manual-keying]
	Bhatia, M., Hartman, S., Zhang, D., and A. Lindem,		Bhatia, M., Hartman, S., Zhang, D., and A. Lindem,
	"Security Extension for OSPFv2 when using Manual Key		"Security Extension for OSPFv2 when using Manual Key
	Management",		Management",
	draft-ietf-ospf-security-extension-manual-keying-01 (work		draft-ietf-ospf-security-extension-manual-keying-04 (work
	in progress), October 2011.		in progress), February 2013.
	[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
	Independent Multicast - Dense Mode (PIM-DM): Protocol
	Specification (Revised)", RFC 3973, January 2005.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	December 2005.		December 2005.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.		RFC 4303, December 2005.
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		Protocol Specification (Revised)", RFC 4601, August 2006.
	skipping to change at line 451 ¶		skipping to change at page 11, line 16 ¶
	Manav Bhatia		Manav Bhatia
	Alcatel-Lucent		Alcatel-Lucent
	Email: manav.bhatia@alcatel-lucent.com		Email: manav.bhatia@alcatel-lucent.com
	Dacheng Zhang		Dacheng Zhang
	Huawei		Huawei
	Email: zhangdacheng@huawei.com		Email: zhangdacheng@huawei.com
			Bharat Joshi
			Infosys Ltd.
			Email: bharat_joshi@infosys.com
End of changes. 52 change blocks.
	183 lines changed or deleted		179 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/