< draft-ietf-nsis-nslp-natfw-24.txt   draft-ietf-nsis-nslp-natfw-25.txt >
NSIS Working Group M. Stiemerling NSIS Working Group M. Stiemerling
Internet-Draft NEC Internet-Draft NEC
Intended status: Experimental H. Tschofenig Intended status: Experimental H. Tschofenig
Expires: October 11, 2010 Nokia Siemens Networks Expires: October 29, 2010 Nokia Siemens Networks
C. Aoun C. Aoun
E. Davies E. Davies
Folly Consulting Folly Consulting
April 9, 2010 April 27, 2010
NAT/Firewall NSIS Signaling Layer Protocol (NSLP) NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
draft-ietf-nsis-nslp-natfw-24.txt draft-ietf-nsis-nslp-natfw-25.txt
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
configured according to the needs of the application data flows. For configured according to the needs of the application data flows. For
instance, it enables hosts behind NATs to obtain a public reachable instance, it enables hosts behind NATs to obtain a public reachable
address and hosts behind firewalls to receive data traffic. The address and hosts behind firewalls to receive data traffic. The
overall architecture is given by the framework and requirements overall architecture is given by the framework and requirements
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 October 11, 2010. This Internet-Draft will expire on October 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 6 1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 6
1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 9 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 9
1.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 1.3. Notes on the Experimental Status . . . . . . . . . . . . . 10
1.4. General Scenario for NATFW Traversal . . . . . . . . . . . 12 1.4. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 11
1.5. General Scenario for NATFW Traversal . . . . . . . . . . . 12
2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 14 2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 14
2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 14 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 14
2.2. NAT with two Private Networks . . . . . . . . . . . . . . 15 2.2. NAT with two Private Networks . . . . . . . . . . . . . . 15
2.3. NAT with Private Network on Sender Side . . . . . . . . . 16 2.3. NAT with Private Network on Sender Side . . . . . . . . . 16
2.4. NAT with Private Network on Receiver Side Scenario . . . . 16 2.4. NAT with Private Network on Receiver Side Scenario . . . . 16
2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . . 17 2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . . 17
2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 18 2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 18
2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 19 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 19
2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 20 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 20
skipping to change at page 4, line 16 skipping to change at page 4, line 17
4.2.4. Extended Flow Information Object . . . . . . . . . . . 62 4.2.4. Extended Flow Information Object . . . . . . . . . . . 62
4.2.5. Information Code Object . . . . . . . . . . . . . . . 63 4.2.5. Information Code Object . . . . . . . . . . . . . . . 63
4.2.6. Nonce Object . . . . . . . . . . . . . . . . . . . . . 66 4.2.6. Nonce Object . . . . . . . . . . . . . . . . . . . . . 66
4.2.7. Message Sequence Number Object . . . . . . . . . . . . 66 4.2.7. Message Sequence Number Object . . . . . . . . . . . . 66
4.2.8. Data Terminal Information Object . . . . . . . . . . . 67 4.2.8. Data Terminal Information Object . . . . . . . . . . . 67
4.2.9. ICMP Types Object . . . . . . . . . . . . . . . . . . 68 4.2.9. ICMP Types Object . . . . . . . . . . . . . . . . . . 68
4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 69 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 69
4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 70 4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 70
4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 71 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 71 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 72
5. Security Considerations . . . . . . . . . . . . . . . . . . . 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 73
5.1. Authorization Framework . . . . . . . . . . . . . . . . . 73 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 73
5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 73 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 73
5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 74 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 74
5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 75 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 75
5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 76 5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 76
5.2.1. Security Protection between neighboring NATFW NSLP 5.2.1. Security Protection between neighboring NATFW NSLP
Nodes . . . . . . . . . . . . . . . . . . . . . . . . 76 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.2. Security Protection between non-neighboring NATFW 5.2.2. Security Protection between non-neighboring NATFW
skipping to change at page 10, line 48 skipping to change at page 10, line 48
o Private/Local IP address: An IP address located in the private o Private/Local IP address: An IP address located in the private
network according to Section 2.8 of [RFC2663]. network according to Section 2.8 of [RFC2663].
o Signaling Destination Address (SDA): An IP address generally taken o Signaling Destination Address (SDA): An IP address generally taken
from the public/global IP address range, although, the SDA may in from the public/global IP address range, although, the SDA may in
certain circumstances be part of the private/local IP address certain circumstances be part of the private/local IP address
range. This address is used in EXTERNAL signaling message range. This address is used in EXTERNAL signaling message
exchanges, if the data receiver's IP address is unknown. exchanges, if the data receiver's IP address is unknown.
1.3. Middleboxes 1.3. Notes on the Experimental Status
The same deployment issues and extensibility considerations described
in [I-D.ietf-nsis-ntlp] and [I-D.ietf-nsis-ext] also apply to this
document.
1.4. Middleboxes
The term middlebox covers a range of devices and is well-defined in The term middlebox covers a range of devices and is well-defined in
[RFC3234]: "A middlebox is defined as any intermediate device [RFC3234]: "A middlebox is defined as any intermediate device
performing functions other than the normal, standard functions of an performing functions other than the normal, standard functions of an
IP router on the datagram path between source host and a destination IP router on the datagram path between source host and a destination
host". As such, middleboxes fall into a number of categories with a host". As such, middleboxes fall into a number of categories with a
wide range of functionality, not all of which is pertinent to the wide range of functionality, not all of which is pertinent to the
NATFW NSLP. Middlebox categories in the scope of this memo are NATFW NSLP. Middlebox categories in the scope of this memo are
firewalls that filter data packets against a set of filter rules, and firewalls that filter data packets against a set of filter rules, and
NATs that translate packet addresses from one address realm to NATs that translate packet addresses from one address realm to
skipping to change at page 11, line 46 skipping to change at page 12, line 4
o Transport protocol number o Transport protocol number
o Transport source and destination port numbers o Transport source and destination port numbers
Actions for firewalls are usually one or more of: Actions for firewalls are usually one or more of:
o Allow: forward data packet o Allow: forward data packet
o Deny: block data packet and discard it o Deny: block data packet and discard it
o Other actions such as logging, diverting, duplicating, etc o Other actions such as logging, diverting, duplicating, etc
Actions for NATs include (amongst many others): Actions for NATs include (amongst many others):
o Change source IP address and transport port number to a globally o Change source IP address and transport port number to a globally
routable IP address and associated port number. routable IP address and associated port number.
o Change destination IP address and transport port number to a o Change destination IP address and transport port number to a
private IP address and associated port number. private IP address and associated port number.
It should be noted that a middlebox may contain two logical It should be noted that a middlebox may contain two logical
representations of the policy rule. The policy rule has a representations of the policy rule. The policy rule has a
representation within the NATFW NSLP, comprising the message routing representation within the NATFW NSLP, comprising the message routing
information (MRI) of the NTLP and NSLP information (such as the rule information (MRI) of the NTLP and NSLP information (such as the rule
action). The other representation is the implementation of the NATFW action). The other representation is the implementation of the NATFW
NSLP policy rule within the NAT and firewall engine of the particular NSLP policy rule within the NAT and firewall engine of the particular
device. Refer to Appendix D for further details. device. Refer to Appendix D for further details.
1.4. General Scenario for NATFW Traversal 1.5. General Scenario for NATFW Traversal
The purpose of NSIS NATFW signaling is to enable communication The purpose of NSIS NATFW signaling is to enable communication
between endpoints across networks, even in the presence of NAT and between endpoints across networks, even in the presence of NAT and
firewall middleboxes that have not been specially engineered to firewall middleboxes that have not been specially engineered to
facilitate communication with the application protocols used. This facilitate communication with the application protocols used. This
removes the need to create and maintain application layer gateways removes the need to create and maintain application layer gateways
for specific protocols that have been commonly used to provide for specific protocols that have been commonly used to provide
transparency in previous generations of NAT and firewall middleboxes. transparency in previous generations of NAT and firewall middleboxes.
It is assumed that these middleboxes will be statically configured in It is assumed that these middleboxes will be statically configured in
such a way that NSIS NATFW signaling messages themselves are allowed such a way that NSIS NATFW signaling messages themselves are allowed
skipping to change at page 32, line 31 skipping to change at page 32, line 31
and sends the message back towards NSLP initiator. and sends the message back towards NSLP initiator.
Each NSLP forwarder processes the RESPONSE message, reads and stores Each NSLP forwarder processes the RESPONSE message, reads and stores
the granted NATFW NSLP signaling session lifetime value. The the granted NATFW NSLP signaling session lifetime value. The
forwarders MUST accept the granted NATFW NSLP signaling session forwarders MUST accept the granted NATFW NSLP signaling session
lifetime, if the lifetime value is within the acceptable range. The lifetime, if the lifetime value is within the acceptable range. The
acceptable value refers to the value accepted by the NSLP forwarder acceptable value refers to the value accepted by the NSLP forwarder
when processing the CREATE or EXTERNAL message. For received values when processing the CREATE or EXTERNAL message. For received values
greater than the acceptable value, NSLP forwarders MUST generate a greater than the acceptable value, NSLP forwarders MUST generate a
RESPONSE message of class 'Signaling session failure' (0x6) with RESPONSE message of class 'Signaling session failure' (0x6) with
response code 'Modified lifetime is too big' (0x11). For received response code 'Modified lifetime is too big' (0x11), including a
values lower than the values acceptable by the node local policy, Signaling Session Lifetime object that carries the maximum acceptable
NSLP forwarders MUST generate a RESPONSE message of class 'Signaling signaling session lifetime for this node. For received values lower
session failure' (0x6) with response code 'Modified lifetime is too than the values acceptable by the node local policy, NSLP forwarders
small' (0x12). In both cases, either 'Modified lifetime is too big' MUST generate a RESPONSE message of class 'Signaling session failure'
(0x11) or 'Modified lifetime is too small' (0x12), the NF MUST (0x6) with response code 'Modified lifetime is too small' (0x12),
generate a NOTIFY message and send it outbound with the error class including a Signaling Session Lifetime object that carries the
set to 'Informational' (0x1) and with the severity class to 'NATFW minimum acceptable signaling session lifetime for this node. In both
signaling session terminated.' (0x05). cases, either 'Modified lifetime is too big' (0x11) or 'Modified
lifetime is too small' (0x12), the NF MUST generate a NOTIFY message
and send it outbound with the error class set to 'Informational'
(0x1) and with the severity class to 'NATFW signaling session
terminated.' (0x05).
Figure 13 shows the procedure with an example, where an initiator Figure 13 shows the procedure with an example, where an initiator
requests 60 seconds lifetime in the CREATE message and the lifetime requests 60 seconds lifetime in the CREATE message and the lifetime
is shortened along the path by the forwarder to 20 seconds and by the is shortened along the path by the forwarder to 20 seconds and by the
responder to 15 seconds. When the NSLP forwarder receives the responder to 15 seconds. When the NSLP forwarder receives the
RESPONSE message with a NATFW NSLP signaling session lifetime value RESPONSE message with a NATFW NSLP signaling session lifetime value
of 15 seconds it checks whether this value is lower or equal to the of 15 seconds it checks whether this value is lower or equal to the
acceptable value. acceptable value.
+-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+
skipping to change at page 36, line 46 skipping to change at page 36, line 46
response code 'Requested policy rule denied due to policy response code 'Requested policy rule denied due to policy
conflict' (0x4). The MRI information is updated to reflect the conflict' (0x4). The MRI information is updated to reflect the
address, and if applicable port, translation. The NSLP message address, and if applicable port, translation. The NSLP message
is forwarded towards the NR with source address set to the is forwarded towards the NR with source address set to the
NAT's external address from the newly remembered binding. NAT's external address from the newly remembered binding.
* Firewall: When the initial CREATE message is received, the NSLP * Firewall: When the initial CREATE message is received, the NSLP
just remembers the requested policy rule, but does not install just remembers the requested policy rule, but does not install
any policy rule. Afterwards, the message is forwarded towards any policy rule. Afterwards, the message is forwarded towards
the NR. An error RESPONSE message is generated, if the the NR. An error RESPONSE message is generated, if the
requested policy rule cannot be installed later on, with of requested policy rule cannot be reserved right away, with of
class 'Signaling session failure' (0x6) with response code class 'Signaling session failure' (0x6) with response code
'Requested policy rule denied due to policy conflict' (0x4). 'Requested policy rule denied due to policy conflict' (0x4).
* 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. No policy NAT middleboxes is the same as in the NAT case. No policy
rules are installed. Implementations MUST take into account rules are installed. Implementations MUST take into account
the order of packet processing in the firewall and NAT the order of packet processing in the firewall and NAT
functions within the device. This will be referred to as functions within the device. This will be referred to as
'order of functions' and is generally different depending on 'order of functions' and is generally different depending on
whether the packet arrives at the external or internal side of whether the packet arrives at the external or internal side of
skipping to change at page 71, line 43 skipping to change at page 71, line 43
o External binding address object (O) o External binding address object (O)
The RESPONSE message for other classes than 'Success' (0x2) carries The RESPONSE message for other classes than 'Success' (0x2) carries
these objects: these objects:
o Message sequence number object (M) o Message sequence number object (M)
o Information code object (M) o Information code object (M)
o Signaling Session Lifetime object (O)
This message is routed towards the NI hop-by-hop, using existing NTLP This message is routed towards the NI hop-by-hop, using existing NTLP
messaging associations. The MRM used for this message MUST be the messaging associations. The MRM used for this message MUST be the
same as MRM used by the corresponding CREATE or EXTERNAL message. same as MRM used by the corresponding CREATE or EXTERNAL message.
4.3.4. NOTIFY 4.3.4. NOTIFY
The NOTIFY messages is used to report asynchronous events happening The NOTIFY messages is used to report asynchronous events happening
along the signaled path to other NATFW NSLP nodes. along the signaled path to other NATFW NSLP nodes.
The NOTIFY message carries this object: The NOTIFY message carries this object:
skipping to change at page 85, line 37 skipping to change at page 85, line 37
RFC 4080, June 2005. RFC 4080, June 2005.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", [RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004. RFC 3726, April 2004.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), January 2010. (work in progress), January 2010.
[I-D.ietf-nsis-ext]
Manner, J., Bless, R., Loughney, J., and E. Davies, "Using
and Extending the NSIS Protocol Family",
draft-ietf-nsis-ext-07 (work in progress), April 2010.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
A. Rayhan, "Middlebox communication architecture and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002. framework", RFC 3303, August 2002.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005. Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
 End of changes. 14 change blocks. 
20 lines changed or deleted 38 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/