< draft-ietf-nsis-nslp-natfw-10.txt		draft-ietf-nsis-nslp-natfw-11.txt >
	NSIS Working Group M. Stiemerling		NSIS Working Group M. Stiemerling
	Internet-Draft NEC		Internet-Draft NEC
	Expires: September 7, 2006 H. Tschofenig		Expires: October 9, 2006 H. Tschofenig
	Siemens		Siemens
	C. Aoun		C. Aoun
	ENST		ENST
	E. Davies		E. Davies
	Folly Consulting		Folly Consulting
	March 6, 2006		April 7, 2006
	NAT/Firewall NSIS Signaling Layer Protocol (NSLP)		NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
	draft-ietf-nsis-nslp-natfw-10		draft-ietf-nsis-nslp-natfw-11.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 7, 2006.		This Internet-Draft will expire on October 9, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This memo defines the NSIS Signaling Layer Protocol (NSLP) for		This memo defines the NSIS Signaling Layer Protocol (NSLP) for
	Network Address Translators (NATs) and firewalls. This NSLP allows		Network Address Translators (NATs) and firewalls. This NSLP allows
	hosts to signal on the data path for NATs and firewalls to be		hosts to signal on the data path for NATs and firewalls to be
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	4.2.1 Session Lifetime Object . . . . . . . . . . . . . . . 55		4.2.1 Session Lifetime Object . . . . . . . . . . . . . . . 55
	4.2.2 External Address Object . . . . . . . . . . . . . . . 55		4.2.2 External Address Object . . . . . . . . . . . . . . . 55
	4.2.3 Extended Flow Information Object . . . . . . . . . . . 56		4.2.3 Extended Flow Information Object . . . . . . . . . . . 56
	4.2.4 Information Code Object . . . . . . . . . . . . . . . 57		4.2.4 Information Code Object . . . . . . . . . . . . . . . 57
	4.2.5 Nonce Object . . . . . . . . . . . . . . . . . . . . . 60		4.2.5 Nonce Object . . . . . . . . . . . . . . . . . . . . . 60
	4.2.6 Message Sequence Number Object . . . . . . . . . . . . 60		4.2.6 Message Sequence Number Object . . . . . . . . . . . . 60
	4.2.7 Data Terminal Information Object . . . . . . . . . . . 61		4.2.7 Data Terminal Information Object . . . . . . . . . . . 61
	4.2.8 Trace Object . . . . . . . . . . . . . . . . . . . . . 62		4.2.8 Trace Object . . . . . . . . . . . . . . . . . . . . . 62
	4.2.9 NI Credential Object . . . . . . . . . . . . . . . . . 63		4.2.9 NI Credential Object . . . . . . . . . . . . . . . . . 63
	4.2.10 ICMP Types Object . . . . . . . . . . . . . . . . . 64		4.2.10 ICMP Types Object . . . . . . . . . . . . . . . . . 64
	4.3 Message Formats . . . . . . . . . . . . . . . . . . . . . 64		4.3 Message Formats . . . . . . . . . . . . . . . . . . . . . 65
	4.3.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . . 65		4.3.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . . 65
	4.3.2 RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . . 66		4.3.2 RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . . 66
	4.3.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 66		4.3.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 66
	4.3.4 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 67		4.3.4 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 67
	4.3.5 TRACE . . . . . . . . . . . . . . . . . . . . . . . . 67		4.3.5 TRACE . . . . . . . . . . . . . . . . . . . . . . . . 67
	5. Security Considerations . . . . . . . . . . . . . . . . . . 68		5. Security Considerations . . . . . . . . . . . . . . . . . . 68
	5.1 Authorization Framework . . . . . . . . . . . . . . . . . 68		5.1 Authorization Framework . . . . . . . . . . . . . . . . . 68
	5.2 Peer-to-Peer Relationship . . . . . . . . . . . . . . . . 68		5.2 Peer-to-Peer Relationship . . . . . . . . . . . . . . . . 68
	5.3 Intra-Domain Relationship . . . . . . . . . . . . . . . . 69		5.3 Intra-Domain Relationship . . . . . . . . . . . . . . . . 69
	skipping to change at page 33, line 29 ¶		skipping to change at page 33, line 29 ¶
	For an initial CREATE message creating a new NATFW NSLP session, the		For an initial CREATE message creating a new NATFW NSLP session, the
	processing of CREATE messages is different for every NATFW node type:		processing of CREATE messages is different for every NATFW node type:
	o NSLP initiator: An NI only generates CREATE messages and hands		o NSLP initiator: An NI only generates CREATE messages and hands
	them over to the NTLP. The NI should never receive request		them over to the NTLP. The NI should never receive request
	messages and MUST discard it.		messages and MUST discard it.
	o NATFW NSLP forwarder: NFs that are unable to forward the request		o NATFW NSLP forwarder: NFs that are unable to forward the request
	message to the next hop MUST generate an error RESPONSE of class		message to the next hop MUST generate an error RESPONSE of class
	'Permanent failure' (0x6) with response code 'Did not reach the		'Permanent failure' (0x6) with response code 'Did not reach the
	NR' (0x06). This case may occur if the NTLP layer cannot find an		NR' (0x07). This case may occur if the NTLP layer cannot find an
	NATFW NSLP peer, either another NF or the NR, and returns an error		NATFW NSLP peer, either another NF or the NR, and returns an error
	via the GIST API. The NSLP message processing at the NFs depends		via the GIST API. The NSLP message processing at the NFs depends
	on the middlebox type:		on the middlebox type:
	* NAT: When the initial CREATE message is received at the public		* NAT: When the initial CREATE message is received at the public
	side of the NAT, it looks for a reservation made in advance, by		side of the NAT, it looks for a reservation made in advance, by
	using a REA message (see Section 3.8.2). The matching process		using a REA message (see Section 3.8.2). The matching process
	considers the received MRI information and the stored MRI		considers the received MRI information and the stored MRI
	information, as described in Section 3.9. If no matching		information, as described in Section 3.9. If no matching
	reservation can be found, i.e. no reservation has been made in		reservation can be found, i.e. no reservation has been made in
	skipping to change at page 40, line 48 ¶		skipping to change at page 40, line 48 ¶
	rule is remembered, but not activated, if the action in the		rule is remembered, but not activated, if the action in the
	NATFW_EFI object is set to 'allow'. In both cases, a		NATFW_EFI object is set to 'allow'. In both cases, a
	successful RESPONSE message is generated.		successful RESPONSE message is generated.
	* Combined NAT and firewall: Processing at combined firewall and		* Combined NAT and firewall: Processing at combined firewall and
	NAT middleboxes is the same as in the NAT case.		NAT middleboxes is the same as in the NAT case.
	o NSLP receiver: This type of message should never be received by		o NSLP receiver: This type of message should never be received by
	any NR+ and it MUST generate an error RESPONSE message of class		any NR+ and it MUST generate an error RESPONSE message of class
	'Permanent failure' (0x5) with response code 'No edge-device here'		'Permanent failure' (0x5) with response code 'No edge-device here'
	(0x05).		(0x06).
	Processing of a RESPONSE message is different for every NSIS node		Processing of a RESPONSE message is different for every NSIS node
	type:		type:
	o NSLP initiator: Upon receiving a successful RESPONSE message, the		o NSLP initiator: Upon receiving a successful RESPONSE message, the
	NI+ can rely on the requested configuration for future inbound		NI+ can rely on the requested configuration for future inbound
	sessions. If the response contains an NATFW_EXT_IP object, the NI		sessions. If the response contains an NATFW_EXT_IP object, the NI
	can use IP address and port pairs carried for further application		can use IP address and port pairs carried for further application
	signaling. After receiving a error RESPONSE message, the NI+ MAY		signaling. After receiving a error RESPONSE message, the NI+ MAY
	try to generate the REA message again or give up and report the		try to generate the REA message again or give up and report the
	skipping to change at page 46, line 16 ¶		skipping to change at page 46, line 16 ¶
	The processing when receiving a TRACE message is the different for		The processing when receiving a TRACE message is the different for
	each type of NATFW node:		each type of NATFW node:
	o NSLP initiator: NI generates TRACE request messages. The NI		o NSLP initiator: NI generates TRACE request messages. The NI
	should never receive request messages and MUST silently discard		should never receive request messages and MUST silently discard
	it.		it.
	o NSLP forwarder: NFs solely forward the message if their local		o NSLP forwarder: NFs solely forward the message if their local
	policies permits tracing. A NF MUST generate an error RESPONSE of		policies permits tracing. A NF MUST generate an error RESPONSE of
	class 'Permanent failure' (0x6) with response code 'Tracing is not		class 'Permanent failure' (0x6) with response code 'Tracing is not
	allowed' (0x07) if the local policies do not allow tracing.		allowed' (0x08) if the local policies do not allow tracing.
	o NSLP responder: NRs receiving a TRACE request message terminate		o NSLP responder: NRs receiving a TRACE request message terminate
	the forwarding and reply with a successful RESPONSE message. The		the forwarding and reply with a successful RESPONSE message. The
	NATFW_TRACE object MAY be filled by the NR with its IP address.		NATFW_TRACE object MAY be filled by the NR with its IP address.
	Processing of a RESPONSE message to a TRACE request message is		Processing of a RESPONSE message to a TRACE request message is
	different for every NSIS node type:		different for every NSIS node type:
	o NSLP initiator: The NI terminates the forwarding and checks the		o NSLP initiator: The NI terminates the forwarding and checks the
	response message for further local processing.		response message for further local processing.
	skipping to change at page 59, line 25 ¶		skipping to change at page 59, line 25 ¶
	o Transient failure:		o Transient failure:
	* 0x01: Requested resources temporarily not available.		* 0x01: Requested resources temporarily not available.
	o Permanent failure:		o Permanent failure:
	* 0x01: Authentication failed.		* 0x01: Authentication failed.
	* 0x02: Authorization failed.		* 0x02: Authorization failed.
	* 0x02: Unable to agree transport security with peer.		* 0x03: Unable to agree transport security with peer.
	* 0x03: Internal or system error.		* 0x04: Internal or system error.
	* 0x04: No NAT here.		* 0x05: No NAT here.
	* 0x05: No edge-device here.		* 0x06: No edge-device here.
	* 0x06: Did not reach the NR.		* 0x07: Did not reach the NR.
	* 0x07: Tracing is not allowed.		* 0x08: Tracing is not allowed.
	o Signaling session failures:		o Signaling session failures:
	* 0x01: Session terminated asynchronously.		* 0x01: Session terminated asynchronously.
	* 0x02: Requested lifetime is too big.		* 0x02: Requested lifetime is too big.
	* 0x03: No reservation found matching the MRI of the CREATE		* 0x03: No reservation found matching the MRI of the CREATE
	request.		request.
	skipping to change at page 61, line 29 ¶		skipping to change at page 61, line 29 ¶
	the data sender. This object contains information about (if		the data sender. This object contains information about (if
	applicable) DR's port number (the destination port number), DS' port		applicable) DR's port number (the destination port number), DS' port
	number (the source port number), the used transport protocol, the		number (the source port number), the used transport protocol, the
	prefix length of the IP address, and DS' IP address.		prefix length of the IP address, and DS' IP address.
	Type: NATFW_DTINFO_IPv4 (IANA-TBD)		Type: NATFW_DTINFO_IPv4 (IANA-TBD)
	Length: 3		Length: 3
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|I|P|S| reserved | dest prefix | protocol |		|I|P|S| reserved | sender prefix | protocol |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: dst port number | src port number :		: dst port number | src port number :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: IPsec SPI :		: IPsec SPI :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| data sender's IPv4 address |		| data sender's IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 29: Data Terminal IPv4 Address Object		Figure 29: Data Terminal IPv4 Address Object
	The flags are:		The flags are:
	o I: I=1 means that Protocol should be interpreted.		o I: I=1 means that 'protocol' should be interpreted.
	o I: P=1 means that 'dst port number' and 'src port number' are		o P: P=1 means that 'dst port number' and 'src port number' are
	present and should be interpreted.		present and should be interpreted.
	o S: S=1 means that SPI is present and should be interpreted.		o S: S=1 means that SPI is present and should be interpreted.
	The SPI field is only present if F is set. The port numbers are only		The SPI field is only present if S is set. The port numbers are only
	present if P is set. The flags P and F MUST NOT be set at the same		present if P is set. The flags P and S MUST NOT be set at the same
	time. An error RESPONSE of class 'Protocol error' (0x3) with		time. An error RESPONSE of class 'Protocol error' (0x3) with
	response code 'Invalid Flag-Field combination' (0x09) MUST be		response code 'Invalid Flag-Field combination' (0x09) MUST be
	generated if they are both set.		generated if they are both set. If either P or S is set, I MUST be
			set as well and the protocol field MUST carry the particular
			protocol. An error RESPONSE of class 'Protocol error' (0x3) with
			response code 'Invalid Flag-Field combination' (0x09) MUST be
			generated if S or P is set but I is not set.
	The fields MUST be interpreted according these rules:		The fields MUST be interpreted according these rules:
	o dest prefix: This parameter indicates the prefix length of the		o (data) sender prefix: This parameter indicates the prefix length
	'data sender's IP address' in bits. For instance, a full IPv4		of the 'data sender's IP address' in bits. For instance, a full
	address requires 'dest prefix' to be set to 32. A value of 0		IPv4 address requires 'dest prefix' to be set to 32. A value of 0
	indicates an IP address wildcard.		indicates an IP address wildcard.
	o protocol: The IPv4 protocol field. This field MUST be interpreted		o protocol: The IPv4 protocol field. This field MUST be interpreted
	if I=1, otherwise it MUST be set to 0 and MUST be ignored.		if I=1, otherwise it MUST be set to 0 and MUST be ignored.
	o dst port number: A value of 0 indicates a port wildcard, i.e., the		o dst port number: A value of 0 indicates a port wildcard, i.e., the
	destination port number is not known. Any other value indicates		destination port number is not known. Any other value indicates
	the destination port number.		the destination port number.
	o src port number: A value of 0 indicates a port wildcard, i.e., the		o src port number: A value of 0 indicates a port wildcard, i.e., the
	skipping to change at page 64, line 6 ¶		skipping to change at page 64, line 6 ¶
	Figure 31: Credential Object		Figure 31: Credential Object
	The field 'credential type' field contains one of these values:		The field 'credential type' field contains one of these values:
	o 0x0002: Token		o 0x0002: Token
	Other trace types MUST generate an error RESPONSE of class 'Protocol		Other trace types MUST generate an error RESPONSE of class 'Protocol
	error' (0x3) with response code 'Unknown object field value' (0x08).		error' (0x3) with response code 'Unknown object field value' (0x08).
			The field 'credential length' counts the total number of bytes of the
			included 'credential data'. Note that the total number of bytes
			contained in the NATFW_CREDENTIAL object may not end on a 32 bit word
			boundary. In this case a padding must be included at the end of the
			object right after the 'credential data' field. The padding must
			fill the NATFW_CREDENTIAL object to next 32 bit word boundary.
	4.2.10 ICMP Types Object		4.2.10 ICMP Types Object
	The 'ICMP types' object contains additional information needed to		The 'ICMP types' object contains additional information needed to
	configure a NAT of firewall with rules to control ICMP traffic. The		configure a NAT of firewall with rules to control ICMP traffic. The
	object contains a number of values of the ICMP Type field for which a		object contains a number of values of the ICMP Type field for which a
	filter action should be set up:		filter action should be set up:
	Type: NATFW_ICMP_TYPES (IANA-TBD)		Type: NATFW_ICMP_TYPES (IANA-TBD)
	Length: Variable = ((Number of Types carried + 1) + 3) DIV 4		Length: Variable = ((Number of Types carried + 1) + 3) DIV 4
	skipping to change at page 94, line 8 ¶		skipping to change at page 94, line 8 ¶
	[25] Maler, E., Philpott, R., and P. Mishra, "Assertions and		[25] Maler, E., Philpott, R., and P. Mishra, "Assertions and
	Protocol for the OASIS Security Assertion Markup Language		Protocol for the OASIS Security Assertion Markup Language
	(SAML) V1.1", September 2003.		(SAML) V1.1", September 2003.
	[26] Maler, E. and J. Hughes, "Technical Overview of the OASIS		[26] Maler, E. and J. Hughes, "Technical Overview of the OASIS
	Security Assertion Markup Language (SAML) V1.1", March 2004.		Security Assertion Markup Language (SAML) V1.1", March 2004.
	[27] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as		[27] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as
	firewall Signalling Protocol", Proceedings of the 6th IEEE		firewall Signalling Protocol", Proceedings of the 6th IEEE
	Symposium on Computers and Communications, Hammamet,		Symposium on Computers and Communications, Hammamet, Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001.
	Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001.
	Authors' Addresses		Authors' Addresses
	Martin Stiemerling		Martin Stiemerling
	Network Laboratories, NEC Europe Ltd.		Network Laboratories, NEC Europe Ltd.
	Kurfuersten-Anlage 36		Kurfuersten-Anlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 (0) 6221 905 11 13		Phone: +49 (0) 6221 905 11 13
End of changes. 22 change blocks.
	25 lines changed or deleted		35 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/