< draft-rafiee-6man-ssas-10.txt		draft-rafiee-6man-ssas-11.txt >
	Network Group H. Rafiee		Network Group H. Rafiee
	INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH		INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH
	Intended status: Experimental C. Meinel		Intended status: Experimental C. Meinel
	Hasso Plattner Institute		Hasso Plattner Institute
	Expires: March 9, 2015 September 9, 2014		Expires: March 19, 2015 September 19, 2014
	A Simple Secure Addressing Scheme for IPv6 AutoConfiguration (SSAS)		A Simple Secure Addressing Scheme for IPv6 AutoConfiguration (SSAS)
	<draft-rafiee-6man-ssas-10.txt>		<draft-rafiee-6man-ssas-11.txt>
	Abstract		Abstract
	Since performance and security are, both, two important criteria for		Since performance and security are, both, two important criteria for
	a mechanism to be widely used by different nodes with various		a mechanism to be widely used by different nodes with various
	resources, the purpose of this document is to propose a mechanism for		resources, the purpose of this document is to propose a mechanism for
	local security and to prevent IP spoofing. This mechanism also		local security and to prevent IP spoofing. This mechanism also
	consider user's privacy.		consider user's privacy.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 working		Task Force (IETF). Note that other groups may also distribute working
	documents as Internet-Drafts. The list of current Internet-Drafts is		documents as Internet-Drafts. The list of current Internet-Drafts is
	at http://datatracker.ietf.org/drafts/current.		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 9, 2015.		This Internet-Draft will expire on March 19, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved. This document is subject to		document authors. All rights reserved. This document is subject to
	BCP 78 and the IETF Trust's Legal Provisions Relating to IETF		BCP 78 and the IETF Trust's Legal Provisions Relating to IETF
	Documents (http://trustee.ietf.org/license-info) in effect on the		Documents (http://trustee.ietf.org/license-info) in effect on the
	date of publication of this document. Please review these documents		date of 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
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	4.2. Authentication in Network layer . . . . . . . . . . . . . 9		4.2. Authentication in Network layer . . . . . . . . . . . . . 9
	4.3. Authentication in Application Layer . . . . . . . . . . . 10		4.3. Authentication in Application Layer . . . . . . . . . . . 10
	4.4. Other Applications . . . . . . . . . . . . . . . . . . . 10		4.4. Other Applications . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Privacy Consideration . . . . . . . . . . . . . . . . . . . . 11		7. Privacy Consideration . . . . . . . . . . . . . . . . . . . . 11
	8. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Comparison of CGA and SSAS generation time . . . . . . . 11		8.1. Comparison of CGA and SSAS generation time . . . . . . . 11
	9. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Network-based protection vs. Node-based protection . . . 12		9.1. Network-based protection vs. Node-based protection . . . 12
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 13		11.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 13
	11.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 14		11.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	In IPv6 networks, nodes can use two different mechanisms to configure		In IPv6 networks, nodes can use two different mechanisms to configure
	their IP addresses -- Neighbor Discovery Protocol (NDP) [RFC4861,		their IP addresses -- Neighbor Discovery Protocol (NDP) [RFC4861,
	RFC4862] and Dynamic Host Configuration Protocol (DHCPv6) [RFC3315].		RFC4862] and Dynamic Host Configuration Protocol (DHCPv6) [RFC3315].
	Unfortunately none of these mechanisms are natively secure. So, they		Unfortunately none of these mechanisms are natively secure. So, they
	open the nodes with so many local security problems. There are		open the nodes with so many local security problems. There are
	several attacks possible in local network [RFC3756]. One example is		several attacks possible in local network [RFC3756]. One example is
	IP spoofing that enable an attacker to forge the identity of a victim		IP spoofing that enable an attacker to forge the identity of a victim
	node, the other example is preventing the node from configuring its		node, the other example is preventing the node from configuring its
	IP address.		IP address.
	The reasons that local security is important are as follows		The reasons that local security is important are as follows
	[localSecurity]:		[localSecurity]:
	- Not all the nodes on the local link are trusted: viruses or other		- Not all the nodes on the local link are trusted: viruses or other
	malware can infect the legitimate node in the local link and turn it		malware can infect a legitimate node in the local link and turn it to
	to an attacker.		an attacker.
	- Attacker might be inside the network: The networks of big		- Attacker might be inside the network: The networks of big
	enterprises might be harmed by one of the staff that was recently		enterprises might be harmed by one of the staff that was recently
	fired.		fired.
	There is currently a mechanism available to secure the NDP, i.e.,		There is currently a mechanism available to secure the NDP, i.e.,
	Secure Neighbor Discovery (SeND) [RFC3971]. SeND does this protection		Secure Neighbor Discovery (SeND) [RFC3971]. SeND does this protection
	by adding 4 options to NDP packets. Among these options,		by adding 4 options to NDP packets. Among these options,
	Cryptographically Generated Addresses (CGA) [RFC3972] is a very		Cryptographically Generated Addresses (CGA) [RFC3972] is a very
	important option that provides the node with the proof of IP address		important option that provides the node with the proof of IP address
	ownership by finding a binding between the node's public key and its		ownership by finding a binding between the node's public key and its
	IP address. Unfortunately CGA has some problems that are listed as		IP address. Unfortunately CGA has some problems that are listed as
	follows:		follows:
	- CGA sec value problem: This problem is explained in [cgaattack] and		- CGA sec value problem: This problem is explained in [cgaattack] and
	addressed in [cgabis].		addressed in [cgabis].
	- CGA increase complexity and decrease performance: CGA uses sec		- CGA increases complexity and decreases performance: CGA uses sec
	value (the value between 0 to 7) and claims to complicate the brute		value (the value between 0 to 7) and claims to complicate the brute
	force attacks. (However it is not true based on [cgaattack]) If CGA		force attacks. (However it is not true based on [cgaattack]) If CGA
	sec value higher than 0 is in use, then this will reduce the		sec value higher than 0 is in use, then this will reduce the
	performance because CGA algorithm needs to repeat some steps and it		performance because CGA algorithm needs to repeat some steps and it
	needs the high attention of the CPU and makes the CPU busy. So, CGA		needs the high attention of the CPU and makes the CPU busy. So, CGA
	sec value higher than 0, consumes more energy than other nodes that		sec value higher than 0, consumes more energy than other nodes that
	do not use CGA. Today, the demands on malti-functioning smaller		do not use CGA. Today, the demands on malti-functioning smaller
	devices are increasing but unfortunately the battery technology is		devices are increasing but unfortunately the battery technology is
	not as advanced as expected. So, the use of CGA algorithm that needs		not as advanced as expected. So, the use of CGA algorithm that needs
	to use higher level of energy is not ideal for these types of nodes		to use higher level of energy is not ideal for these types of nodes
	and the use of CGA sec value zero does not protect the node as		and the use of CGA sec value zero does not protect the node as
	expected. (Please refer to appendix A for more information)		expected. (Please refer to appendix A for more information)
	- CGA might cause privacy issue: Since the generation of CGA higher		- CGA might cause privacy issue: Since the generation of CGA higher
	sec values might take time. The nodes might not be willing to change		sec values might take time. The nodes might not be willing to change
	its IP address and keep this address as long as the subnet prefix is		its IP address and keep this address as long as the subnet prefix is
	valid. If the node is a fixed node in the network, then it will be		valid. If the node is a fixed node in the network, then it will be
	vulnerable to node tracking. The node might also not change the CGA		vulnerable to node tracking. The node might also not change the CGA
	address when it visits a new network. Since in Hash2 process		address when it visits a new network or it might not generate any new
			key pairs. In other word, it might use the same CGA parameters
			(excluding prefix) as used in the old network and thus it will be
			vulnerable to node tracking.
	- Packet size		- Packet size
	CGA uses RSA as a default key pair generation algorithm. This is why,		CGA uses RSA as a default key pair generation algorithm. This is why,
	if SeND with CGA option is in use to secure NDP messages, the minimum		if SeND with CGA option is in use to secure NDP messages, the minimum
	packet size needs to carry this public key for CGA nodes is 460		packet size needs to carry this public key for CGA nodes is 460
	bytes. Packet size also reduces the performance and causes delays in		bytes. Packet size also reduces the performance and causes delays in
	the network.		the network.
	Since privacy and security are, both, very important issues in		Since privacy and security are, both, very important issues in
	skipping to change at page 4, line 50 ¶		skipping to change at page 4, line 53 ¶
	needed for the IID algorithm generation. Another concern is for the		needed for the IID algorithm generation. Another concern is for the
	lack of security (if CGA is not in use). This is what this document		lack of security (if CGA is not in use). This is what this document
	intends to address.		intends to address.
	3.1. Interface ID (IID) Generation		3.1. Interface ID (IID) Generation
	To generate the IID a node will need to execute the following steps.		To generate the IID a node will need to execute the following steps.
	1. Generate key pairs (public/private keys) using one of the latest		1. Generate key pairs (public/private keys) using one of the latest
	version of ECC algorithm [RFC6090] or other fastest short key size		version of ECC algorithm [RFC6090] or other fastest short key size
	algorithms. ECC is the default algorithm, but any algorithm capable		algorithms. . The implementations SHOULD be updated with any new
	of generating a small key size in a short amount of time is viable.		version of ECC algorithm when ECC current version is no longer
	It then uses this new value for the generation of the IP address and		secure. ECC is the default algorithm, but any algorithm capable of
	signature. Comparing the use of ECC to that of RSA shows that an ECC		generating a small key size in a short amount of time is viable. The
	with a 192 bit key is equivalent to a RSA with a 7680 bit key		node then uses this new value for the generation of the IP address
			and signature. Comparing the use of ECC to that of RSA shows that an
			ECC with a 192 bit key is equivalent to a RSA with a 7680 bit key
	(according to US National Security Agency) In this case the packet		(according to US National Security Agency) In this case the packet
	size would be decreased by a factor 11 times smaller than that when		size would be decreased by a factor 11 times smaller than that when
	using RSA.		using RSA.
	Note 1: The node MUST not generate the weak key. For ECC, the node		Note 1: The node MUST not generate the weak key. For ECC, the node
	MUST not use ECC key size lower than 192 bits. If any nodes used a		MUST not use ECC key size lower than 192 bits. If any nodes used a
	weak key size, then the other nodes MUST discard receiving the		weak key size, then the other nodes MUST discard receiving the
	message from that node. If in future, key size 192 bits is considered		message from that node. If in future, key size 192 bits is considered
	as a weak key size, the default key size value MUST be changed to the		as a weak key size, the default key size value MUST be changed to the
	next strong key size.		next strong key size.
	2. Divide the public key array of bytes into two half byte arrays		2. Execute a hash function on the public key. The default hash
	(see figure 1). Obtain the first 4 bytes from the first half byte		function is SHA256. If in future, this hash function is no longer
	array and call it the partial IID1. Obtain the first 4 bytes of the		secure, the node MUST use the next strong hash function.
	second half byte array and call this the partial IID2. (Dividing the
	public key is only for randomization)
	It is not RECOMMENDED to use this algorithm in case IID is less than		3. Take the first 64bits of the digest and call it IID. In case
	64 bits [variableprefix]. If the IID is more than 64 bits and it is		collision count is higher than 1, then depends on the number, takes
	odd value, for example 69 bits, then after dividing the public key in		second 64 bits or third 64 bits of this hash value.
	two halves, partial IID1 would be 34 bits and partial IID2 will be
	35. In other word, partial IID2 might not be in the same size as
	partial IID1 when subnet prefix is not 64 bits. A node obtains this
	information from the router messages.
	3. Concatenate partial IID1 with partial IID2 and call this the IID.		It is not RECOMMENDED to use this algorithm in case IID is less than
			64 bits [variableprefix]. A node MUST obtain the prefix length
			information form router advertisement messages.
	4. Concatenate the IID with the local subnet prefix to set the link		4. Concatenate the IID with the local subnet prefix to set the link
	local IP address.		local IP address.
	5. Concatenate the IID with the router subnet prefix (Global subnet		5. Concatenate the IID with the router subnet prefix (Global subnet
	prefix), obtained from the Router Advertisement (RA) message, and set		prefix), obtained from the Router Advertisement (RA) message, and set
	it as a tentative public IP address. This IP address will become		it as a tentative public IP address. This IP address will become
	permanent after Duplicate Address Detection (DAD) processing. (For		permanent after Duplicate Address Detection (DAD) processing. (For
	more information about DAD refer to section 3.1.2.)		more information about DAD refer to section 3.1.2.)
	Note 1: In this document bits u and g does not have any particular		Note 1: In this document bits u and g does not have any particular
	meaning and is used as a part of public key. This assumption is by		meaning and is used as a part of public key. This assumption is by
	the clarification of using these bits in [RFC7136].		the clarification of using these bits in [RFC7136].
	+-------------+---------+ +-------------+---------+
	|partial IID1 | | |Partial IID2 | |
	+-------------+ | +-------------+ |
	| | | |
	+-----------------------+ +-----------------------+
	Figure 1 Public key divided into two halves
	3.1.1. Signature Generation		3.1.1. Signature Generation
	SSAS is not dependent to SeND but it can be used as a new option of		SSAS is not dependent to SeND but it can be used as a new option of
	SeND. When SSAS is used as an option of SeND, SSAS signature can be		SeND. When SSAS is used as an option of SeND, SSAS signature can be
	placed as a RSA signature in SeND. If SSAS is used alone, this		placed as a RSA signature in SeND. If SSAS is used alone, this
	section MUST be included in SSAS data structure. This proves that		section MUST be included in SSAS data structure. This proves that
	SSAS is compatible to use with SeND.		SSAS is compatible to use with SeND.
	The SSAS signature is added to NDP messages in order to protect them		The SSAS signature is added to NDP messages in order to protect them
	from IP spoofing and spoofing types of attack. SSAS will provide		from IP spoofing and spoofing types of attack. SSAS will provide
	proof of IP address ownership. To generate the SSAS signature, the		proof of IP address ownership. To generate the SSAS signature, the
	node needs to execute the following steps:		node needs to execute the following steps:
	1. Concatenate the timestamp with the MAC address, collision count,		1. Concatenate the timestamp with the MAC address, collision count,
	algorithm type and the global (public) IP address. (see figure 2)		algorithm type and the global (public) IP address. (see figure 1)
	+---------+-----------+---------------+--------------+		+---------+-----------+---------------+--------------+
	|timestamp|Mac address|Collision Count|Algorithm type|		|timestamp|Mac address|Collision Count|Algorithm type|
	| 8 bytes | 6 bytes | 3 bits | 1 byte |		| 8 bytes | 6 bytes | 3 bits | 1 byte |
	+---------------------+---------------+--------------+		+---------------------+---------------+--------------+
	|Global IP address | Other Options |		|Global IP address | Other Options |
	| 16 bytes | variable |		| 16 bytes | variable |
	+---------------------+---------------+		+---------------------+---------------+
	Figure 2 SSAS Signature format		Figure 1 SSAS Signature format
	2. Sign the resulting value from step 1, using the ECC private key		2. Sign the resulting value from step 1, using the ECC private key
	(or any other short key size algorithm), and call the resulting		(or any other short key size algorithm), and call the resulting
	output the SSAS signature.		output the SSAS signature.
	If NDP messages contain other data that must be protected, such as		If NDP messages contain other data that must be protected, such as
	important routing information, then this data SHOULD also be included		important routing information, then this data SHOULD also be included
	in the signature. The signature is designed for the inclusion of any		in the signature. The signature is designed for the inclusion of any
	data needing protection. If there is no data that needs protection,		data needing protection. If there is no data that needs protection,
	then the signature will only contain the timestamp, MAC address,		then the signature will only contain the timestamp, MAC address,
	Collision count and Global IP address (Router subnet prefix plus		Collision count and Global IP address (Router subnet prefix plus
	skipping to change at page 7, line 7 ¶		skipping to change at page 6, line 53 ¶
	3.1.2.1. SSAS signature data field		3.1.2.1. SSAS signature data field
	+------+-------+------------+---------+		+------+-------+------------+---------+
	| Type |Length | Reserved |Other len|		| Type |Length | Reserved |Other len|
	|1 byte|1 byte | 2 bytes | 1 byte |		|1 byte|1 byte | 2 bytes | 1 byte |
	+----------+---------+------+---------+		+----------+---------+------+---------+
	| Algorithm|Collision|Subnet| Other |		| Algorithm|Collision|Subnet| Other |
	| type | count |prefix|Options |		| type | count |prefix|Options |
	| 1 byte | 3 bits |8bytes| |		| 1 byte | 3 bits |8bytes| |
	+-------------------------------------+		+-------------------------------------+
	| |		|Hash | Response| |
	| SSAS Signature |		|Function | No. | SSAS Signature |
	| |		| 1 byte | 2 byte | |
	+-------------------------------------+		+-------------------------------------+
	| padding |		| padding |
	+-------------------------------------+		+-------------------------------------+
	Figure 3 NDP Message Format with SSAS Signature Data Field		Figure 2 NDP Message Format with SSAS Signature Data Field
	- Type: This option is set to 15. This is the sequential number used		- Type: This option is set to 15. This is the sequential number used
	in SeND to indicate a SSAS data field.		in SeND to indicate a SSAS data field.
	- Length: The length of the Signature Data field, including the Type,		- Length: The length of the Signature Data field, including the Type,
	Length, Reserved, Algorithm type, Signature and padding, must be a		Length, Reserved, Algorithm type, Signature and padding, must be a
	multiple of eight.		multiple of eight.
	- Reserved: A 2 byte field reserved for future use. The value must be		- Reserved: A 2 byte field reserved for future use. The value must be
	initialized to zero by the sender and should be ignored by the		initialized to zero by the sender and should be ignored by the
	receiver.		receiver.
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 31 ¶
	length of this field is 1 byte.		length of this field is 1 byte.
	- Algorithm type: The algorithm used to generate key pairs and sign		- Algorithm type: The algorithm used to generate key pairs and sign
	the message. The length of this field is 1 byte. For ECC, this value		the message. The length of this field is 1 byte. For ECC, this value
	is 0. Future algorithms will start at one and increase from there.		is 0. Future algorithms will start at one and increase from there.
	- Collision count: When a collision occurs during the DAD, the node		- Collision count: When a collision occurs during the DAD, the node
	will increment this value and store it in a file to be included in		will increment this value and store it in a file to be included in
	the sent packets for as long as the current IP address is valid. This		the sent packets for as long as the current IP address is valid. This
	value indicates to the node where it needs to start its check from,		value indicates to the node where it needs to start its check from,
	i.e., the first or second or third bytes from the start of the half		i.e., the first or second or third 64 bytes from the start of the
	byte array of the public key.		hash value (digest) array of the public key.
	- Subnet Prefix: This is the router subnet prefix.		- Subnet Prefix: This is the router subnet prefix.
			- Hash Function: A hash function used to generate IID. The length of
			this field is 1 byte. For SHA256, this value is 0. Future algorithms
			will start at one and increase from there.
			- Response No: This is similar to nonce but by the use of different
			mechanism. This value is not random and it is a copy of timestamp. In
			sender?s message, this value MUST be set to zero and in response
			message (sent from a receiver node), this value MUST be set to the
			timestamp of the sender?s message. The length of this field is 2
			bytes. The sender node should cache this value in order to compare it
			with all responses sent by other nodes. This informs the sender node
			that the message is the response to his message and protects the node
			against replay attack.
	- Other Options. This variable-length field contains important data		- Other Options. This variable-length field contains important data
	that needs to be protected in the packet. The padding is used to		that needs to be protected in the packet. The padding is used to
	insure that the field is a multiple of eight in length.		insure that the field is a multiple of eight in length.
	- Padding. A variable-length field containing padding to insure that		- Padding. A variable-length field containing padding to insure that
	the entire signature field is a multiple of eight in length. It thus		the entire signature field is a multiple of eight in length. It thus
	contains the number of blanks needed to make the entire signature		contains the number of blanks needed to make the entire signature
	field end on a multiple of eight.		field end on a multiple of eight.
	All NDP messages (except RS messages) SHOULD contain the SSAS		All NDP messages (except RS messages) SHOULD contain the SSAS
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 24 ¶
	and after 3 times generates a new public/private keys. Since the		and after 3 times generates a new public/private keys. Since the
	likelihood of two nodes having the same value is 1/(2^63). This is		likelihood of two nodes having the same value is 1/(2^63). This is
	really a small value while we also considered the order of magnitude		really a small value while we also considered the order of magnitude
	relative to roughly 2 power 64 against sloppy implementations.		relative to roughly 2 power 64 against sloppy implementations.
	3.1.3. SSAS verification process		3.1.3. SSAS verification process
	A node's verification process should start when it receives NDP		A node's verification process should start when it receives NDP
	messages. Following are the steps used in the verification process:		messages. Following are the steps used in the verification process:
	1. Obtain prefix information from its own cache or from a router		1. Obtain Response No from the sender?s packet. Compare this value
			with its own timestamp that used in its previous message. If it is
			the same go to the next step, otherwise discard the message. (If SSAS
			is a part of SeND, this step should be skipped.)
			2. Obtain prefix information from its own cache or from a router
	advertisement to make sure about the prefix sizes and number of bits		advertisement to make sure about the prefix sizes and number of bits
	used for IID.		used for IID.
	2. Obtain the timestamp from the NDP message and call this value t1.		3. Obtain the timestamp from the NDP message and call this value t1.
	3. Obtain the timestamp from the node's system, convert it to UTC,		4. Obtain the timestamp from the node's system, convert it to UTC,
	and call this value t2.		and call this value t2.
	4. If (t2- x) < = t1 < = (t2 + x) go to step 4. Otherwise, the		5. If (t2- x) < = t1 < = (t2 + x) go to step 6. Otherwise, the
	message SHOULD be discarded without further processing. The value of		message SHOULD be discarded without further processing. The value of
	x is dependent on network delays and network policy. The default		x is dependent on network delays and network policy. The default
	value would be the value of Round Trip Time (RTT). The		value would be the value of Round Trip Time (RTT). The
	implementations SHOULD allow to set different values.		implementations SHOULD allow to set different values.
	5. Obtain the public key from its own neighboring cache. If no		6. Obtain the public key from its own neighboring cache. If no
	matches are found in the node cache and if there is a centralized		matches are found in the node cache and if there is a centralized
	RPKI model available in the local network, then the node MIGHT obtain		RPKI model available in the local network, then the node MIGHT obtain
	this public key from that node. Otherwise go to the next step.		this public key from that node. Otherwise go to the next step.
	6. Compare this to its own public key. If it is not the same, go to		7. Compare this to its own public key. If it is not the same, go to
	the next step. Otherwise, the message should be discarded without		the next step. Otherwise, the message should be discarded without
	further processing. (This step should be skipped when the node uses		further processing. (This step should be skipped when the node uses
	the RPKI to obtain the other nodes' public key.)		the RPKI to obtain the other nodes' public key.)
	7. Divide the public key into two arrays of bytes. Based on the		8. Obtain the hash algorithm from the packet. By default it is
	collision count, start from the first, second or third bytes of		SHA256.
	public key and select 4 bytes from each half byte array and call them
	partial IID 1 and 2. Concatenate partial IID 1 with partial IID2.		9. Execute hash function on the public key. Takes 64bits, depends on
	Obtain the node's source IP address. Compare this value with the		collision count, from the hash function. Compare this value with the
	node's IID source IP. If it is the same, go to the next step.		node's IID source IP. If it is the same, go to the next step.
	Otherwise, discard the message without further processing.		Otherwise, discard the message without further processing.
	8. Concatenate the timestamp with the MAC address, algorithm type,		10. Concatenate the timestamp with the MAC address, algorithm type,
	collision count, sender's Global IP address (subnet prefix and IID),		collision count, sender's Global IP address (subnet prefix and IID),
	and other options (if any) and call this entity the plain message.		and other options (if any) and call this entity the plain message.
	9. Obtain the SSAS signature from the SSAS signature data field.		11. Obtain the SSAS signature from the SSAS signature data field.
	Obtain the Algorithm type from the message.		Obtain the Algorithm type from the message.
	10. Verify the Signature using the public key and then enter the		12. Verify the Signature using the public key and then enter the
	plain message and the SSAS signature as an input to the verification		plain message and the SSAS signature as an input to the verification
	function. If the verification process is successful, process the		function. If the verification process is successful, process the
	message. Otherwise, the message should be discarded without further		message. Otherwise, the message should be discarded without further
	processing.		processing.
	After a successful verification, the node SHOULD store the public key		After a successful verification, the node SHOULD store the public key
	and MAC address of the sender node in its neighboring cache. By		and MAC address of the sender node in its neighboring cache. By
	default, the cache is valid for two days but the implementation		default, the cache is valid for two days but the implementation
	SHOULD consider a way to let the end users change this default value.		SHOULD consider a way to let the end users change this default value.
	skipping to change at page 11, line 6 ¶		skipping to change at page 11, line 20 ¶
	Interface ID? If he could, he could then generate the signature using		Interface ID? If he could, he could then generate the signature using
	his own private key and thus break SSAS. Mathematically it has been		his own private key and thus break SSAS. Mathematically it has been
	shown that the likelihood of matching 64 bits in the public key		shown that the likelihood of matching 64 bits in the public key
	against 64bits in the IID is 1/(2^64). in [SSASAnalysis] the analysis		against 64bits in the IID is 1/(2^64). in [SSASAnalysis] the analysis
	of SSAS is explained and compared to CGA. Since the nodes in the		of SSAS is explained and compared to CGA. Since the nodes in the
	network need to keep the public key and the MAC address of other		network need to keep the public key and the MAC address of other
	nodes in the cache, the attacker only has a few seconds to perform		nodes in the cache, the attacker only has a few seconds to perform
	this attack and then the attacker needs to perform this attack		this attack and then the attacker needs to perform this attack
	against the whole public key. For CGA, this value is less. in		against the whole public key. For CGA, this value is less. in
	[cgaattack], the attack in CGA was explained. So, in general, SSAS is		[cgaattack], the attack in CGA was explained. So, in general, SSAS is
	faster and in a good security level.		faster and in a good security level. In other word, SSAS tried to
			address the security and performance problem exists in CGA and offer
			a fastest algorithm.
	6. IANA Considerations		6. IANA Considerations
	There is no IANA consideration		There is no IANA consideration
	7. Privacy Consideration		7. Privacy Consideration
	When an attacker is inside a local link, he is enable to identify a		When an attacker is inside a local link, he is enable to identify a
	node. although, this target node changes its IP address. The reason		node. although, this target node changes its IP address. The reason
	is because the target node does not change its MAC address. However,		is because the target node does not change its MAC address. However,
End of changes. 30 change blocks.
	57 lines changed or deleted		72 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/