< draft-ietf-nsis-nslp-natfw-13.txt   draft-ietf-nsis-nslp-natfw-14.txt >
NSIS Working Group M. Stiemerling NSIS Working Group M. Stiemerling
Internet-Draft NEC Internet-Draft NEC
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: April 26, 2007 Siemens Expires: September 6, 2007 Siemens
C. Aoun C. Aoun
ENST
E. Davies E. Davies
Folly Consulting Folly Consulting
October 23, 2006 March 5, 2007
NAT/Firewall NSIS Signaling Layer Protocol (NSLP) NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
draft-ietf-nsis-nslp-natfw-13.txt draft-ietf-nsis-nslp-natfw-14.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 April 26, 2007. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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. It configured according to the needs of the application data flows. It
enables hosts behind NATs to obtain a public reachable address and enables hosts behind NATs to obtain a public reachable address and
hosts behind firewalls to receive data traffic. The overall hosts behind firewalls to receive data traffic. The overall
architecture is given by the framework and requirements defined by architecture is given by the framework and requirements defined by
skipping to change at page 2, line 45 skipping to change at page 2, line 45
3. Protocol Description . . . . . . . . . . . . . . . . . . . . 20 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 20
3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21
3.2.1. Message Types . . . . . . . . . . . . . . . . . . . . 25 3.2.1. Message Types . . . . . . . . . . . . . . . . . . . . 25
3.2.2. Classification of RESPONSE Messages . . . . . . . . . 25 3.2.2. Classification of RESPONSE Messages . . . . . . . . . 25
3.2.3. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26 3.2.3. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26
3.3. Basic Message Processing . . . . . . . . . . . . . . . . 27 3.3. Basic Message Processing . . . . . . . . . . . . . . . . 27
3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27
3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . 30 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . 30
3.6. Authentication, Authorization, and Policy Decisions . . . 31 3.6. Authentication, Authorization, and Policy Decisions . . . 31
3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 31 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 32
3.7.1. Creating Sessions . . . . . . . . . . . . . . . . . . 31 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 32
3.7.2. Reserving External Addresses . . . . . . . . . . . . 34 3.7.2. Reserving External Addresses . . . . . . . . . . . . 35
3.7.3. NATFW Session Refresh . . . . . . . . . . . . . . . . 41 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . 42
3.7.4. Deleting Sessions . . . . . . . . . . . . . . . . . . 42 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 43
3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 44 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 44
3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 45 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 46
3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 48 3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 49
3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 50 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 51
3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 51 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 51
4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 52 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 53
4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 52 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 53
4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . 53 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 54 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 55
4.2.2. External Address Object . . . . . . . . . . . . . . . 54 4.2.2. External Address Object . . . . . . . . . . . . . . . 55
4.2.3. Extended Flow Information Object . . . . . . . . . . 55 4.2.3. Extended Flow Information Object . . . . . . . . . . 56
4.2.4. Information Code Object . . . . . . . . . . . . . . . 56 4.2.4. Information Code Object . . . . . . . . . . . . . . . 57
4.2.5. Nonce Object . . . . . . . . . . . . . . . . . . . . 59 4.2.5. Nonce Object . . . . . . . . . . . . . . . . . . . . 60
4.2.6. Message Sequence Number Object . . . . . . . . . . . 59 4.2.6. Message Sequence Number Object . . . . . . . . . . . 60
4.2.7. Data Terminal Information Object . . . . . . . . . . 60 4.2.7. Data Terminal Information Object . . . . . . . . . . 61
4.2.8. ICMP Types Object . . . . . . . . . . . . . . . . . . 61 4.2.8. ICMP Types Object . . . . . . . . . . . . . . . . . . 62
4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 62 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 63
4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . 63 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.2. EXTERNAL (EXT) . . . . . . . . . . . . . . . . . . . 63 4.3.2. EXTERNAL (EXT) . . . . . . . . . . . . . . . . . . . 64
4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . 64 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . 65
4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 65
5. Security Considerations . . . . . . . . . . . . . . . . . . . 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 67
5.1. Authorization Framework . . . . . . . . . . . . . . . . . 66 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 67
5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 66 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 67
5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 67 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 68
5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . 68 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . 69
5.2. Security Threats and Requirements . . . . . . . . . . . . 69 5.2. Security Threats and Requirements . . . . . . . . . . . . 70
5.2.1. Data Sender (DS) behind a firewall . . . . . . . . . 69 5.2.1. Data Sender (DS) behind a firewall . . . . . . . . . 70
5.2.2. Data Sender (DS) behind a NAT . . . . . . . . . . . . 70 5.2.2. Data Sender (DS) behind a NAT . . . . . . . . . . . . 71
5.2.3. Data Receiver (DR) behind a firewall . . . . . . . . 70 5.2.3. Data Receiver (DR) behind a firewall . . . . . . . . 71
5.2.4. Data Receiver (DR) behind a NAT . . . . . . . . . . . 72 5.2.4. Data Receiver (DR) behind a NAT . . . . . . . . . . . 73
5.2.5. NSLP Message Injection . . . . . . . . . . . . . . . 73 5.2.5. NSLP Message Injection . . . . . . . . . . . . . . . 74
5.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 74 5.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 75
5.3.1. Flooding with CREATE messages from outside . . . . . 74 5.3.1. Flooding with CREATE messages from outside . . . . . 75
5.3.2. Flooding with EXT messages from inside . . . . . . . 75 5.3.2. Flooding with EXT messages from inside . . . . . . . 76
5.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 75 5.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 76
5.5. Message Modification by non-NSIS on-path node . . . . . . 76 5.5. Message Modification by non-NSIS on-path node . . . . . . 77
5.6. Message Modification by malicious NSIS node . . . . . . . 76 5.6. Message Modification by malicious NSIS node . . . . . . . 77
5.7. Session Ownership . . . . . . . . . . . . . . . . . . . . 77 5.7. Signaling Session Ownership . . . . . . . . . . . . . . . 78
5.7.1. Misuse of Mobility in a NAT Handling Scenario . . . . 77 5.7.1. Misuse of Mobility in a NAT Handling Scenario . . . . 78
5.8. Misuse of unreleased sessions . . . . . . . . . . . . . . 78 5.8. Misuse of unreleased signaling sessions . . . . . . . . . 79
5.9. Data Traffic Injection . . . . . . . . . . . . . . . . . 80 5.9. Data Traffic Injection . . . . . . . . . . . . . . . . . 81
5.10. Eavesdropping and Traffic Analysis . . . . . . . . . . . 80 5.10. Eavesdropping and Traffic Analysis . . . . . . . . . . . 81
5.11. Security Framework for the NAT/Firewall NSLP . . . . . . 80 5.11. Security Framework for the NAT/Firewall NSLP . . . . . . 81
5.11.1. Security Protection between neighboring NATFW NSLP 5.11.1. Security Protection between neighboring NATFW NSLP
Nodes . . . . . . . . . . . . . . . . . . . . . . . . 81 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 82
5.11.2. Security Protection between non-neighboring NATFW 5.11.2. Security Protection between non-neighboring NATFW
NSLP Nodes . . . . . . . . . . . . . . . . . . . . . 81 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . 82
6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 84 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 85
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 87 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 88
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 89
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.1. Normative References . . . . . . . . . . . . . . . . . . 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 90
10.2. Informative References . . . . . . . . . . . . . . . . . 89 10.2. Informative References . . . . . . . . . . . . . . . . . 90
Appendix A. Selecting Signaling Destination Addresses for EXT . 92 Appendix A. Selecting Signaling Destination Addresses for EXT . 92
Appendix B. Applicability Statement on Data Receivers behind Appendix B. Applicability Statement on Data Receivers behind
Firewalls . . . . . . . . . . . . . . . . . . . . . 94 Firewalls . . . . . . . . . . . . . . . . . . . . . 93
Appendix C. Firewall and NAT Resources . . . . . . . . . . . . . 96 Appendix C. Firewall and NAT Resources . . . . . . . . . . . . . 95
C.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 96 C.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 95
C.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 96 C.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 95
C.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 97 C.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 96
C.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . 97 C.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . 96
Appendix D. Assigned Numbers for Testing . . . . . . . . . . . . 99 Appendix D. Assigned Numbers for Testing . . . . . . . . . . . . 98
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 99
Intellectual Property and Copyright Statements . . . . . . . . . 101 Intellectual Property and Copyright Statements . . . . . . . . . 100
1. Introduction 1. Introduction
Firewalls and Network Address Translators (NAT) have both been used Firewalls and Network Address Translators (NAT) have both been used
throughout the Internet for many years, and they will remain present throughout the Internet for many years, and they will remain present
for the foreseeable future. Firewalls are used to protect networks for the foreseeable future. Firewalls are used to protect networks
against certain types of attacks from internal networks and the against certain types of attacks from internal networks and the
Internet, whereas NATs provide a virtual extension of the IP address Internet, whereas NATs provide a virtual extension of the IP address
space. Both types of devices may be obstacles to some applications, space. Both types of devices may be obstacles to some applications,
since they only allow traffic created by a limited set of since they only allow traffic created by a limited set of
skipping to change at page 5, line 31 skipping to change at page 5, line 31
when they have additional functionality which attempts to restore the when they have additional functionality which attempts to restore the
transparency of the network. transparency of the network.
Several solutions to enable applications to traverse such entities Several solutions to enable applications to traverse such entities
have been proposed and are currently in use. Typically, application have been proposed and are currently in use. Typically, application
level gateways (ALG) have been integrated with the firewall or NAT to level gateways (ALG) have been integrated with the firewall or NAT to
configure the firewall or NAT dynamically. Another approach is configure the firewall or NAT dynamically. Another approach is
middlebox communication (MIDCOM). In this approach, ALGs external to middlebox communication (MIDCOM). In this approach, ALGs external to
the firewall or NAT configure the corresponding entity via the MIDCOM the firewall or NAT configure the corresponding entity via the MIDCOM
protocol [7]. Several other work-around solutions are available, protocol [7]. Several other work-around solutions are available,
such as STUN [19]. However, all of these approaches introduce other such as STUN [15]. However, all of these approaches introduce other
problems that are generally hard to solve, such as dependencies on problems that are generally hard to solve, such as dependencies on
the type of NAT implementation (full-cone, symmetric, etc), or the type of NAT implementation (full-cone, symmetric, etc), or
dependencies on certain network topologies. dependencies on certain network topologies.
NAT and firewall (NATFW) signaling shares a property with Quality of NAT and firewall (NATFW) signaling shares a property with Quality of
Service (QoS) signaling. The signaling of both must reach any device Service (QoS) signaling. The signaling of both must reach any device
on the data path that is involved in, respectively, NATFW or QoS on the data path that is involved in, respectively, NATFW or QoS
treatment of data packets. This means, that for both, NATFW and QoS, treatment of data packets. This means, that for both, NATFW and QoS,
it is convenient if signaling travels path-coupled, meaning that the it is convenient if signaling travels path-coupled, meaning that the
signaling messages follow exactly the same path that the data packets signaling messages follow exactly the same path that the data packets
take. RSVP [13] is an example of a current QoS signaling protocol take. RSVP [11] is an example of a current QoS signaling protocol
that is path-coupled. [26] proposes the use of RSVP as firewall that is path-coupled. [22] proposes the use of RSVP as firewall
signaling protocol but does not include NATs. signaling protocol but does not include NATs.
This memo defines a path-coupled signaling protocol for NAT and This memo defines a path-coupled signaling protocol for NAT and
firewall configuration within the framework of NSIS, called the NATFW firewall configuration within the framework of NSIS, called the NATFW
NSIS Signaling Layer Protocol (NSLP). The general requirements for NSIS Signaling Layer Protocol (NSLP). The general requirements for
NSIS are defined in [5] and the general framework of NSIS is outlined NSIS are defined in [5] and the general framework of NSIS is outlined
in [4]. It introduces the split between an NSIS transport layer and in [4]. It introduces the split between an NSIS transport layer and
an NSIS signaling layer. The transport of NSLP messages is handled an NSIS signaling layer. The transport of NSLP messages is handled
by an NSIS Network Transport Layer Protocol (NTLP, with General by an NSIS Network Transport Layer Protocol (NTLP, with General
Internet Signaling Transport (GIST) [2] being the implementation of Internet Signaling Transport (GIST) [2] being the implementation of
the abstract NTLP). The signaling logic for QoS and NATFW signaling the abstract NTLP). The signaling logic for QoS and NATFW signaling
is implemented in the different NSLPs. The QoS NSLP is defined in is implemented in the different NSLPs. The QoS NSLP is defined in
[6]. [6].
The NATFW NSLP is designed to request the dynamic configuration of The NATFW NSLP is designed to request the dynamic configuration of
NATs and/or firewalls along the data path. Dynamic configuration NATs and/or firewalls along the data path. Dynamic configuration
includes enabling data flows to traverse these devices without being includes enabling data flows to traverse these devices without being
obstructed, as well as blocking of particular data flows at upstream obstructed, as well as blocking of particular data flows at inbound
firewalls. Enabling data flows requires the loading of firewall firewalls. Enabling data flows requires the loading of firewall
rules with an action that allows the data flow packets to be rules with an action that allows the data flow packets to be
forwarded and creating NAT bindings. Blocking of data flows requires forwarded and creating NAT bindings. Blocking of data flows requires
the loading of firewalls rules with an action that will deny the loading of firewalls rules with an action that will deny
forwarding of the data flow packets. A simplified example for forwarding of the data flow packets. A simplified example for
enabling data flows: A source host sends a NATFW NSLP signaling enabling data flows: A source host sends a NATFW NSLP signaling
message towards its data destination. This message follows the data message towards its data destination. This message follows the data
path. Every NATFW NSLP-enabled NAT/firewall along the data path path. Every NATFW NSLP-enabled NAT/firewall along the data path
intercepts these messages, processes them, and configures itself intercepts these messages, processes them, and configures itself
accordingly. Thereafter, the actual data flow can traverse all these accordingly. Thereafter, the actual data flow can traverse all these
skipping to change at page 6, line 45 skipping to change at page 6, line 45
base assumption, if not otherwise noted. base assumption, if not otherwise noted.
2. Only one end host or region of the network is NSIS NATFW NSLP 2. Only one end host or region of the network is NSIS NATFW NSLP
aware, either data receiver or data sender. This scenario is aware, either data receiver or data sender. This scenario is
referred to as proxy mode. referred to as proxy mode.
The NATFW NSLP has two basic signaling messages which are sufficient The NATFW NSLP has two basic signaling messages which are sufficient
to cope with the various possible scenarios likely to be encountered to cope with the various possible scenarios likely to be encountered
before and after widespread deployment of NSIS: before and after widespread deployment of NSIS:
CREATE message: The basic mode for configuring a path downstream CREATE message: The basic message for configuring a path outbound
from a data sender to a data receiver. from a data sender to a data receiver.
EXTERNAL (EXT) message: Used to locate upstream NATs/firewalls and EXTERNAL (EXT) message: Used to locate inbound NATs/firewalls and
prime them to expect downstream signaling and at NATs to pre- prime them to expect outbound signaling and at NATs to pre-
allocate a public address. This is used for data receivers behind allocate a public address. This is used for data receivers behind
these devices to enable their reachability. these devices to enable their reachability.
CREATE and EXT messages are sent by the NSIS initiator (NI) towards CREATE and EXT messages are sent by the NSIS initiator (NI) towards
the NSIS responder (NR). Both type of messages are acknowledged by a the NSIS responder (NR). Both type of messages are acknowledged by a
subsequent RESPONSE message. This RESPONSE message is generated by subsequent RESPONSE message. This RESPONSE message is generated by
the NR if the requested configuration can be established, otherwise the NR if the requested configuration can be established, otherwise
the NR or any of the NSIS forwarders (NFs) can also generate such a the NR or any of the NSIS forwarders (NFs) can also generate such a
message if an error occurs. NFs and the NR can also generate message if an error occurs. NFs and the NR can also generate
asynchronous messages to notify the NI, the so called NOTIFY asynchronous messages to notify the NI, the so called NOTIFY
skipping to change at page 7, line 29 skipping to change at page 7, line 29
During the introduction of NSIS, it is likely that one or other of During the introduction of NSIS, it is likely that one or other of
the data sender and receiver will not be NSIS aware. In these cases, the data sender and receiver will not be NSIS aware. In these cases,
the NATFW NSLP can utilize NSIS aware middleboxes on the path between the NATFW NSLP can utilize NSIS aware middleboxes on the path between
the data sender and data receiver to provide proxy NATFW NSLP the data sender and data receiver to provide proxy NATFW NSLP
services (i.e., the proxy mode operation). Typically, these boxes services (i.e., the proxy mode operation). Typically, these boxes
will be at the boundaries of the realms in which the end hosts are will be at the boundaries of the realms in which the end hosts are
located. located.
The CREATE and EXT messages create NATFW NSLP and NTLP state in NSIS The CREATE and EXT messages create NATFW NSLP and NTLP state in NSIS
entities. NTLP state allows signaling messages to travel in the entities. NTLP state allows signaling messages to travel in the
forward (downstream) and the reverse (upstream) direction along the forward (outbound) and the reverse (inbound) direction along the path
path between a NAT/firewall NSLP sender and a corresponding receiver. between a NAT/firewall NSLP sender and a corresponding receiver.
This state is managed using a soft-state mechanism, i.e., it expires This state is managed using a soft-state mechanism, i.e., it expires
unless it is refreshed from time to time. The NAT bindings and unless it is refreshed from time to time. The NAT bindings and
firewall rules being installed during the state setup are bound to firewall rules being installed during the state setup are bound to
the particular signaling session. However, the exact local the particular signaling session. However, the exact local
implementation of the NAT bindings and firewall rules are NAT/ implementation of the NAT bindings and firewall rules are NAT/
firewall specific. firewall specific.
This memo is structured as follows. Section 2 describes the network This memo is structured as follows. Section 2 describes the network
environment for NATFW NSLP signaling. Section 3 defines the NATFW environment for NATFW NSLP signaling. Section 3 defines the NATFW
signaling protocol and Section 4 defines the message components and signaling protocol and Section 4 defines the message components and
the overall messages used in the protocol. The remaining parts of the overall messages used in the protocol. The remaining parts of
the main body of the document, covers security considerations the main body of the document, covers security considerations
Section 5, IAB considerations on UNilateral Self-Address Fixing Section 5, IAB considerations on UNilateral Self-Address Fixing
(UNSAF) [15] in Section 6 and IANA considerations in Section 7. (UNSAF) [12] in Section 6 and IANA considerations in Section 7.
Please note that readers familiar with firewalls and NATs and their Please note that readers familiar with firewalls and NATs and their
possible location within networks can safely skip Section 2. possible location within networks can safely skip Section 2.
1.1. Terminology and Abbreviations 1.1. Terminology and Abbreviations
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 [1]. document are to be interpreted as described in [1].
This document uses a number of terms defined in [5] and [4]. The This document uses a number of terms defined in [5] and [4]. The
following additional terms are used: following additional terms are used:
o Policy rule: A policy rule is "a basic building block of a policy- o Policy rule: A policy rule is "a basic building block of a policy-
based system. It is the binding of a set of actions to a set of based system. It is the binding of a set of actions to a set of
conditions - where the conditions are evaluated to determine conditions - where the conditions are evaluated to determine
whether the actions are performed" [20]. In the context of NSIS whether the actions are performed" [16]. In the context of NSIS
NATFW NSLP, the conditions are the specification of a set of NATFW NSLP, the conditions are the specification of a set of
packets to which the rule is applied. The set of actions always packets to which the rule is applied. The set of actions always
contains just a single element per rule, and is limited to either contains just a single element per rule, and is limited to either
action "deny" or action "allow". action "deny" or action "allow".
o Reserved policy rule: A policy rule stored at NATs or firewalls o Reserved policy rule: A policy rule stored at NATs or firewalls
for activation by a later, different signaling exchange. This for activation by a later, different signaling exchange. This
type of policy rule is kept in the NATFW NSLP and is not loaded type of policy rule is kept in the NATFW NSLP and is not loaded
into the firewall or NAT engine, i.e., it does not affect the data into the firewall or NAT engine, i.e., it does not affect the data
flow handling. flow handling.
skipping to change at page 8, line 45 skipping to change at page 8, line 45
o Network Address Translator: Network Address Translation is a o Network Address Translator: Network Address Translation is a
method by which IP addresses are mapped from one IP address realm method by which IP addresses are mapped from one IP address realm
to another, in an attempt to provide transparent routing between to another, in an attempt to provide transparent routing between
hosts (see [9]). Network Address Translators are devices that hosts (see [9]). Network Address Translators are devices that
perform this work by modifying packets passing through them. perform this work by modifying packets passing through them.
o Middlebox: "A middlebox is defined as any intermediate device o Middlebox: "A middlebox is defined as any intermediate device
performing functions other than the normal, standard functions of performing functions other than the normal, standard functions of
an IP router on the datagram path between a source host and a an IP router on the datagram path between a source host and a
destination host" [11]. In the context of this document, the term destination host" [10]. In the context of this document, the term
middlebox refers to firewalls and NATs only. Other types of middlebox refers to firewalls and NATs only. Other types of
middlebox are outside of the scope of this document. middlebox are outside of the scope of this document.
o Data Receiver (DR): The node in the network that is receiving the o Data Receiver (DR): The node in the network that is receiving the
data packets of a flow. data packets of a flow.
o Data Sender (DS): The node in the network that is sending the data o Data Sender (DS): The node in the network that is sending the data
packets of a flow. packets of a flow.
o NATFW NSLP peer or peer: An NSIS NATFW NSLP node with which an o NATFW NSLP peer or peer: An NSIS NATFW NSLP node with which an
skipping to change at page 11, line 42 skipping to change at page 11, line 42
such a way that NSIS NATFW signaling messages themselves are allowed such a way that NSIS NATFW signaling messages themselves are allowed
to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP
signaling is used to dynamically install additional policy rules in signaling is used to dynamically install additional policy rules in
all NATFW middleboxes along the data path that will allow all NATFW middleboxes along the data path that will allow
transmission of the application data flow(s). Firewalls are transmission of the application data flow(s). Firewalls are
configured to forward data packets matching the policy rule provided configured to forward data packets matching the policy rule provided
by the NSLP signaling. NATs are configured to translate data packets by the NSLP signaling. NATs are configured to translate data packets
matching the policy rule provided by the NSLP signaling. An matching the policy rule provided by the NSLP signaling. An
additional capability, that is an exception to the primary goal of additional capability, that is an exception to the primary goal of
NSIS NATFW signaling, is that the NATFW nodes can request blocking of NSIS NATFW signaling, is that the NATFW nodes can request blocking of
particular data flows instead of enabling these flows at upstream particular data flows instead of enabling these flows at inbound
firewalls. firewalls.
The basic high-level picture of NSIS usage is that end hosts are The basic high-level picture of NSIS usage is that end hosts are
located behind middleboxes, meaning that there is a middlebox on the located behind middleboxes, meaning that there is a middlebox on the
data path from the end host in a private network and the external data path from the end host in a private network and the external
network (NATFW in Figure 1). Applications located at these end hosts network (NATFW in Figure 1). Applications located at these end hosts
try to establish communication with corresponding applications on try to establish communication with corresponding applications on
other such end hosts. They trigger the NSIS entity at the local host other such end hosts. They trigger the NSIS entity at the local host
to control provisioning for middlebox traversal along the prospective to control provisioning for middlebox traversal along the prospective
data path (e.g., via an API call). The NSIS entity in turn uses NSIS data path (e.g., via an API call). The NSIS entity in turn uses NSIS
skipping to change at page 14, line 17 skipping to change at page 14, line 17
There are several very different ways to place firewalls in a network There are several very different ways to place firewalls in a network
topology. To distinguish firewalls located at network borders, such topology. To distinguish firewalls located at network borders, such
as administrative domains, from others located internally, the term as administrative domains, from others located internally, the term
edge-firewall is used. A similar distinction can be made for NATs, edge-firewall is used. A similar distinction can be made for NATs,
with an edge-NAT fulfilling the equivalent role. with an edge-NAT fulfilling the equivalent role.
2.2. NAT with two private Networks 2.2. NAT with two private Networks
Figure 3 shows a scenario with NATs at both ends of the network. Figure 3 shows a scenario with NATs at both ends of the network.
Therefore, each application instance, the NSIS initiator and the NSIS Therefore, each application instance, the NSIS initiator and the NSIS
responder, are behind NATs. The outermost NAT, known as the edge- responder, are behind NATs. The outermost NAT, known as the edge-NAT
NAT, at each side is connected to the public Internet. The NATs are (MB2 and MB3), at each side is connected to the public Internet. The
generically labeled as MB (for middlebox), since those devices NATs are generically labeled as MBX (for middlebox No. X), since
certainly implement NAT functionality, but can implement firewall those devices certainly implement NAT functionality, but can
functionality as well. implement firewall functionality as well.
Only two middleboxes MB are shown in Figure 3 at each side, but in Only two middleboxes MB are shown in Figure 3 at each side, but in
general, any number of MBs on each side must be considered. general, any number of MBs on each side must be considered.
+----+ +----+ //----\\ +----+ +----+ +----+ +----+ //----\\ +----+ +----+
NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR
+----+ +----+ \\----// +----+ +----+ +----+ +----+ \\----// +----+ +----+
private public private private public private
MB: Middlebox MB: Middlebox
NI: NSIS Initiator NI: NSIS Initiator
NR: NSIS Responder NR: NSIS Responder
Figure 3: NAT with two Private Networks Scenario Figure 3: NAT with two Private Networks Scenario
Signaling traffic from NI to NR has to traverse all the middleboxes Signaling traffic from NI to NR has to traverse all the middleboxes
on the path, and all the middleboxes must be configured properly to on the path (MB1 to MB4, in this order), and all the middleboxes must
allow NSIS signaling to traverse them. The NATFW signaling must be configured properly to allow NSIS signaling to traverse them. The
configure all middleboxes and consider any address translation that NATFW signaling must configure all middleboxes and consider any
will result from this configuration in further signaling. The sender address translation that will result from this configuration in
(NI) has to know the IP address of the receiver (NR) in advance, further signaling. The sender (NI) has to know the IP address of the
otherwise it will not be possible to send any NSIS signaling messages receiver (NR) in advance, otherwise it will not be possible to send
towards the responder. Note that this IP address is not the private any NSIS signaling messages towards the responder. Note that this IP
IP address of the responder. Instead a NAT binding (including a address is not the private IP address of the responder but the NAT's
public IP address) has to be previously installed on the NAT that public IP address (here MB3's IP address). Instead a NAT binding
subsequently allows packets reaching the NAT to be forwarded to the (including a public IP address) has to be previously installed on the
receiver within the private address realm. The receiver might have a NAT MB3. This NAT binding subsequently allows packets reaching the
number of ways to learn its public IP address and port number NAT to be forwarded to the receiver within the private address realm.
(including the NATFW NSLP) and might need to signal this information The receiver might have a number of ways to learn its public IP
to the sender using the application level signaling protocol. address and port number (including the NATFW NSLP) and might need to
signal this information to the sender using the application level
signaling protocol.
2.3. NAT with Private Network on Sender Side 2.3. NAT with Private Network on Sender Side
This scenario shows an application instance at the sending node that This scenario shows an application instance at the sending node that
is behind one or more NATs (shown as generic MB, see discussion in is behind one or more NATs (shown as generic MB, see discussion in
Section 2.2). The receiver is located in the public Internet. Section 2.2). The receiver is located in the public Internet.
+----+ +----+ //----\\ +----+ +----+ //----\\
NI --| MB |-----| MB |---| |--- NR NI --| MB |-----| MB |---| |--- NR
+----+ +----+ \\----// +----+ +----+ \\----//
skipping to change at page 16, line 25 skipping to change at page 16, line 25
Figure 5: NAT with Private Network on Receiver Scenario Figure 5: NAT with Private Network on Receiver Scenario
Initially, the NSIS responder must determine its publicly reachable Initially, the NSIS responder must determine its publicly reachable
IP address at the external middlebox and notify the NSIS initiator IP address at the external middlebox and notify the NSIS initiator
about this address. One possibility is that an application level about this address. One possibility is that an application level
protocol is used, meaning that the public IP address is signaled via protocol is used, meaning that the public IP address is signaled via
this protocol to the NI. Afterwards the NI can start its signaling this protocol to the NI. Afterwards the NI can start its signaling
towards the NR and therefore establish the path via the middleboxes towards the NR and therefore establish the path via the middleboxes
in the receiver side private network. in the receiver side private network.
This scenario describes the use case for the EXTERNAL mode of the This scenario describes the use case for the EXTERNAL message of the
NATFW NSLP. NATFW NSLP.
2.5. Both End Hosts behind twice-NATs 2.5. Both End Hosts behind twice-NATs
This is a special case, where the main problem arises from the need This is a special case, where the main problem arises from the need
to detect that both end hosts are logically within the same address to detect that both end hosts are logically within the same address
space, but are also in two partitions of the address realm on either space, but are also in two partitions of the address realm on either
side of a twice-NAT (see [9] for a discussion of twice-NAT side of a twice-NAT (see [9] for a discussion of twice-NAT
functionality). functionality).
skipping to change at page 17, line 42 skipping to change at page 17, line 42
NR. The configuration of those middleboxes may require other NR. The configuration of those middleboxes may require other
middlebox communication protocols, such as MIDCOM [7]. NSIS middlebox communication protocols, such as MIDCOM [7]. NSIS
signaling is not required in the twice-NAT only case, since signaling is not required in the twice-NAT only case, since
middleboxes of the twice-NAT type are normally configured by other middleboxes of the twice-NAT type are normally configured by other
means. Nevertheless, NSIS signaling might be useful when there are means. Nevertheless, NSIS signaling might be useful when there are
also firewalls on the path. In this case NSIS will not configure any also firewalls on the path. In this case NSIS will not configure any
policy rule at twice-NATs, but will configure policy rules at the policy rule at twice-NATs, but will configure policy rules at the
firewalls on the path. The NSIS signaling protocol must be at least firewalls on the path. The NSIS signaling protocol must be at least
robust enough to survive this scenario. This requires that twice- robust enough to survive this scenario. This requires that twice-
NATs must implement the NATFW NSLP also and participate in NATFW NATs must implement the NATFW NSLP also and participate in NATFW
sessions but they do not change the configuration of the NAT, i.e., signaling sessions but they do not change the configuration of the
they only read the address mapping information out of the NAT and NAT, i.e., they only read the address mapping information out of the
translate the Message Routing Information (MRI, [2]) within the NSLP NAT and translate the Message Routing Information (MRI, [2]) within
and NTLP accordingly. For more information see Appendix C.4 the NSLP and NTLP accordingly. For more information see Appendix C.4
2.6. Both End Hosts Behind Same NAT 2.6. Both End Hosts Behind Same NAT
When NSIS initiator and NSIS responder are behind the same NAT (thus When NSIS initiator and NSIS responder are behind the same NAT (thus
being in the same address realm, see Figure 7), they are most likely being in the same address realm, see Figure 7), they are most likely
not aware of this fact. As in Section 2.4 the NSIS responder must not aware of this fact. As in Section 2.4 the NSIS responder must
determine its public IP address in advance and transfer it to the determine its public IP address in advance and transfer it to the
NSIS initiator. Afterwards, the NSIS initiator can start sending the NSIS initiator. Afterwards, the NSIS initiator can start sending the
signaling messages to the responder's public IP address. During this signaling messages to the responder's public IP address. During this
process, a public IP address will be allocated for the NSIS initiator process, a public IP address will be allocated for the NSIS initiator
skipping to change at page 18, line 32 skipping to change at page 18, line 32
Figure 7: NAT to Public, Both Hosts Behind Same NAT Figure 7: NAT to Public, Both Hosts Behind Same NAT
2.7. Multihomed Network with NAT 2.7. Multihomed Network with NAT
The previous sub-sections sketched network topologies where several The previous sub-sections sketched network topologies where several
NATs and/or firewalls are ordered sequentially on the path. This NATs and/or firewalls are ordered sequentially on the path. This
section describes a multihomed scenario with two NATs placed on section describes a multihomed scenario with two NATs placed on
alternative paths to the public network. alternative paths to the public network.
+----+ +----+ //---\\
NI -------| MB |\ NI -------| MB |---| |
\ +----+ \ //---\\ \ +----+ \\-+-//
\ -| |-- NR \ |
\ \\---// \ +----- NR
\ +----+ | \ |
--| MB |-------+ \ +----+ //-+-\\
+----+ --| MB |---| |
+----+ \\---//
private public private public
MB: Middlebox MB: Middlebox
NI: NSIS Initiator NI: NSIS Initiator
NR: NSIS Responder NR: NSIS Responder
Figure 8: Multihomed Network with Two NATs Figure 8: Multihomed Network with Two NATs
Depending on the destination, either one or the other middlebox is Depending on the destination, either one or the other middlebox is
used for the data flow. Which middlebox is used, depends on local used for the data flow. Which middlebox is used, depends on local
policy or routing decisions. NATFW NSLP must be able to handle this policy or routing decisions. NATFW NSLP must be able to handle this
situation properly, see Section 3.7.2 for an extended discussion of situation properly, see Section 3.7.2 for an extended discussion of
this topic with respect to NATs. this topic with respect to NATs.
2.8. Multihomed Network with Firewall 2.8. Multihomed Network with Firewall
This section describes a multihomed scenario with two firewalls This section describes a multihomed scenario with two firewalls
placed on alternative paths to the public network (Figure 9). The placed on alternative paths to the public network (Figure 9). The
routing in the private and public network decides which firewall is routing in the private and public network decides which firewall is
being taken for data flows. Depending on the data flow's direction, being taken for data flows. Depending on the data flow's direction,
either outbound or inbound, a different firewall could be traversed. either outbound or inbound, a different firewall could be traversed.
This is a challenge for the EXT mode of the NATFW NSLP where the NSIS This is a challenge for the EXT message of the NATFW NSLP where the
responder is located behind these firewalls within the private NSIS responder is located behind these firewalls within the private
network. The EXT mode is used to block a particular data flow on an network. The EXT message is used to block a particular data flow on
upstream firewall. NSIS must route the EXT mode message upstream an inbound firewall. NSIS must route the EXT message inbound from NR
from NR to NI probably without knowing which path the data traffic to NI probably without knowing which path the data traffic will take
will take from NI to NR (see also Appendix B). from NI to NR (see also Appendix B).
+----+ +----+
NR -------| MB |\ NR -------| MB |\
\ +----+ \ //---\\ \ +----+ \ //---\\
\ -| |-- NI \ -| |-- NI
\ \\---// \ \\---//
\ +----+ | \ +----+ |
--| MB |-------+ --| MB |-------+
+----+ +----+
private private
skipping to change at page 20, line 12 skipping to change at page 20, line 12
Figure 9: Multihomed Network with two Firewalls Figure 9: Multihomed Network with two Firewalls
3. Protocol Description 3. Protocol Description
This section defines messages, objects, and protocol semantics for This section defines messages, objects, and protocol semantics for
the NATFW NSLP. the NATFW NSLP.
3.1. Policy Rules 3.1. Policy Rules
Policy rules, bound to a session, are the building blocks of Policy rules, bound to a NATFW NSLP signaling session, are the
middlebox devices considered in the NATFW NSLP. For firewalls the building blocks of middlebox devices considered in the NATFW NSLP.
policy rule usually consists of a 5-tuple, source/destination For firewalls the policy rule usually consists of a 5-tuple, source/
addresses, transport protocol, and source/destination port numbers, destination addresses, transport protocol, and source/destination
plus an action, such as allow or deny. For NATs the policy rule port numbers, plus an action, such as allow or deny. For NATs the
consists of the action 'translate this address' and further mapping policy rule consists of the action 'translate this address' and
information, that might be, in the simplest case, internal IP address further mapping information, that might be, in the simplest case,
and external IP address. internal IP address and external IP address.
The NATFW NSLP carries, in conjunction with the NTLP's Message The NATFW NSLP carries, in conjunction with the NTLP's Message
Routing Information (MRI), the policy rules to be installed at NATFW Routing Information (MRI), the policy rules to be installed at NATFW
peers. This policy rule is an abstraction with respect to the real peers. This policy rule is an abstraction with respect to the real
policy rule to be installed at the respective firewall or NAT. It policy rule to be installed at the respective firewall or NAT. It
conveys the initiator's request and must be mapped to the possible conveys the initiator's request and must be mapped to the possible
configuration on the particular used NAT and/or firewall in use. For configuration on the particular used NAT and/or firewall in use. For
pure firewalls one or more filter rules must be created and for pure pure firewalls one or more filter rules must be created and for pure
NATs one or more NAT bindings must be created. In mixed firewall and NATs one or more NAT bindings must be created. In mixed firewall and
NAT boxes, the policy rule must be mapped to filter rules and NAT boxes, the policy rule must be mapped to filter rules and
skipping to change at page 21, line 31 skipping to change at page 21, line 31
same host, this specification does not rule out scenarios where the same host, this specification does not rule out scenarios where the
DS and NI reside on different hosts, the so-called proxy mode (see DS and NI reside on different hosts, the so-called proxy mode (see
Section 3.7.6.) Section 3.7.6.)
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR |
| |--->| NF1 |--->| NF2 |--->| | | |--->| NF1 |--->| NF2 |--->| |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
========================================> ========================================>
Data Traffic Direction (downstream) Data Traffic Direction (outbound)
---> : NATFW NSLP request signaling ---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling ~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSIS forwarder 1 MB1 : Middlebox 1 and NSIS forwarder 1
MB2 : Middlebox 2 and NSIS forwarder 2 MB2 : Middlebox 2 and NSIS forwarder 2
Figure 10: General NSIS signaling Figure 10: General NSIS signaling
The following list shows the normal sequence of NSLP events without The following list shows the normal sequence of NSLP events without
detailing the interaction with the NTLP and the interactions on the detailing the interaction with the NTLP and the interactions on the
the NTLP level. the NTLP level.
o NSIS initiators generate NATFW NSLP CREATE/EXT messages and send o NSIS initiators generate NATFW NSLP CREATE/EXT messages and send
these towards the NSIS responder. This CREATE/EXT message is the these towards the NSIS responder. This CREATE/EXT message is the
initial message which creates a new signaling session. The NI and initial message which creates a new NATFW NSLP signaling session.
the NR will most likely already share an application session The NI and the NR will most likely already share an application
before they start the NATFW NSLP signaling session. Note the session before they start the NATFW NSLP signaling session. Note
difference between both sessions. the difference between both sessions.
o NSLP CREATE/EXT messages are processed each time a NF with NATFW o NSLP CREATE/EXT messages are processed each time a NF with NATFW
NSLP support is traversed. Each NF that is intercepting a CREATE/ NSLP support is traversed. Each NF that is intercepting a CREATE/
EXT message and is accepting it for further treatment is joining EXT message and is accepting it for further treatment is joining
the particular signaling session. These nodes process the the particular NATFW NSLP signaling session. These nodes process
message, check local policies for authorization and the message, check local policies for authorization and
authentication, possibly create policy rules, and forward the authentication, possibly create policy rules, and forward the
signaling message to the next NSIS node. The request message is signaling message to the next NSIS node. The request message is
forwarded until it reaches the NSIS responder. forwarded until it reaches the NSIS responder.
o NSIS responders will check received messages and process them if o NSIS responders will check received messages and process them if
applicable. NSIS responders generate RESPONSE messages and send applicable. NSIS responders generate RESPONSE messages and send
them hop-by-hop back to the NI via the same chain of NFs them hop-by-hop back to the NI via the same chain of NFs
(traversal of the same NF chain is guaranteed through the (traversal of the same NF chain is guaranteed through the
established reverse message routing state in the NTLP). The NR is established reverse message routing state in the NTLP). The NR is
also joining the signaling session if the CREATE/EXT message is also joining the NATFW NSLP signaling session if the CREATE/EXT
accepted. message is accepted.
o The RESPONSE message is processed at each NF that has been o The RESPONSE message is processed at each NF that has been
included in the prior signaling session setup. included in the prior NATFW NSLP signaling session setup.
o If the NI has received a successful RESPONSE message and if the o If the NI has received a successful RESPONSE message and if the
signaling session started with a CREATE message, the data sender signaling NATFW NSLP session started with a CREATE message, the
can start sending its data flow to the data receiver. If the Ni data sender can start sending its data flow to the data receiver.
has received a successful RESPONSE message and if the signaling If the Ni has received a successful RESPONSE message and if the
session started with a EXT message, the data receiver is ready to signaling NATFW NSLP session started with a EXT message, the data
receive further CREATE messages. receiver is ready to receive further CREATE messages.
Because NATFW NSLP signaling follows the data path from DS to DR, Because NATFW NSLP signaling follows the data path from DS to DR,
this immediately enables communication between both hosts for this immediately enables communication between both hosts for
scenarios with only firewalls on the data path or NATs on the sender scenarios with only firewalls on the data path or NATs on the sender
side. For scenarios with NATs on the receiver side certain problems side. For scenarios with NATs on the receiver side certain problems
arise, as described in Section 2.4. arise, as described in Section 2.4.
When the NR and the NI are located in different address realms and When the NR and the NI are located in different address realms and
the NR is located behind a NAT, the NI cannot signal to the NR the NR is located behind a NAT, the NI cannot signal to the NR
address directly. The DR/NR are not reachable from the NIs using the address directly. The DR/NR are not reachable from the NIs using the
private address of the NR and thus NATFW signaling messages cannot be private address of the NR and thus NATFW signaling messages cannot be
sent to the NR/DR's address. Therefore, the NR must first obtain a sent to the NR/DR's address. Therefore, the NR must first obtain a
NAT binding that provides an address that is reachable for the NI. NAT binding that provides an address that is reachable for the NI.
Once the NR has acquired a public IP address, it forwards this Once the NR has acquired a public IP address, it forwards this
information to the DS via a separate protocol. This application information to the DS via a separate protocol. This application
layer signaling, which is out of scope of the NATFW NSLP, may involve layer signaling, which is out of scope of the NATFW NSLP, may involve
third parties that assist in exchanging these messages. third parties that assist in exchanging these messages.
The same holds partially true for NRs located behind firewalls that The same holds partially true for NRs located behind firewalls that
block all traffic by default. In this case, NR must tell its block all traffic by default. In this case, NR must tell its inbound
upstream firewalls of inbound NATFW NSLP signaling and corresponding firewalls of inbound NATFW NSLP signaling and corresponding data
data traffic. Once the NR has informed the upstream firewalls, it traffic. Once the NR has informed the inbound firewalls, it can
can start its application level signaling to initiate communication start its application level signaling to initiate communication with
with the NI. This application layer signaling, which is out of scope the NI. This application layer signaling, which is out of scope of
of the NATFW NSLP, may involve third parties that assist in the NATFW NSLP, may involve third parties that assist in exchanging
exchanging these messages. This mechanism can be used by machines these messages. This mechanism can be used by machines hosting
hosting services behind firewalls as well. In this case, the NR services behind firewalls as well. In this case, the NR informs the
informs the upstream firewalls as described, but does not need to inbound firewalls as described, but does not need to communicate this
communicate this to the NIs. to the NIs.
NATFW NSLP signaling supports this scenario by using the EXT mode of NATFW NSLP signaling supports this scenario by using the EXT message
operation
1. The DR acquires a public address by signaling on the reverse path 1. The DR acquires a public address by signaling on the reverse path
(DR towards DS) and thus making itself available to other hosts. (DR towards DS) and thus making itself available to other hosts.
This process of acquiring public addresses is called reservation. This process of acquiring public addresses is called reservation.
During this process the DR reserves publicly reachable addresses During this process the DR reserves publicly reachable addresses
and ports suitable for further usage in application level and ports suitable for further usage in application level
signaling and the publicly reachable address for further NATFW signaling and the publicly reachable address for further NATFW
NSLP signaling. However, the data traffic will not be allowed to NSLP signaling. However, the data traffic will not be allowed to
use this address/port initially (see next point). In the process use this address/port initially (see next point). In the process
of reservation the DR becomes the NI for the messages necessary of reservation the DR becomes the NI for the messages necessary
to obtain the publicly reachable IP address, i.e., the NI for to obtain the publicly reachable IP address, i.e., the NI for
this specific signaling session. this specific NATFW NSLP signaling session.
2. Now on the side of DS, the NI creates a new signaling session and 2. Now on the side of DS, the NI creates a new NATFW NSLP signaling
signals directly to the public IP address of DR. This public IP session and signals directly to the public IP address of DR.
address is used as NR's address., as the NI would do if there is This public IP address is used as NR's address, as the NI would
no NAT in between, and creates policy rules at middleboxes. do if there is no NAT in between, and creates policy rules at
Note, that the reservation mode will only allow forwarding of middleboxes. Note, that the reservation will only allow
signaling messages, but not data flow packets. Policy rules forwarding of signaling messages, but not data flow packets.
allowing forwarding of data flow packets set up by the prior EXT Policy rules allowing forwarding of data flow packets set up by
mode signaling will be activated when the signaling from NI the prior EXT message signaling will be activated when the
towards NR is confirmed with a positive RESPONSE message. The signaling from NI towards NR is confirmed with a positive
EXTERNAL (EXT) mode of operation is detailed inSection 3.7.2. RESPONSE message. The EXTERNAL (EXT) message is described
inSection 3.7.2.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| DS/NI |<~~~| MB1/ |<~~~| NR | | DR | | DS/NI |<~~~| MB1/ |<~~~| NR | | DR |
| |--->| NF1 |--->| | | | | |--->| NF1 |--->| | | |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
========================================> ========================================>
Data Traffic Direction (downstream) Data Traffic Direction (outbound)
---> : NATFW NSLP request signaling ---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling ~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSIS forwarder 1 MB1 : Middlebox 1 and NSIS forwarder 1
MB2 : Middlebox 2 and NSIS forwarder 2 MB2 : Middlebox 2 and NSIS forwarder 2
Figure 11: A NSIS proxy mode signaling Figure 11: A NSIS proxy mode signaling
skipping to change at page 24, line 37 skipping to change at page 24, line 37
described in Section 3.7.6; the proxy mode operation also supports described in Section 3.7.6; the proxy mode operation also supports
scenarios with a data sender that does not support NSIS, i.e. the scenarios with a data sender that does not support NSIS, i.e. the
data receiver must act to enable data flows towards itself. data receiver must act to enable data flows towards itself.
The basic functionality of the NATFW NSLP provides for opening The basic functionality of the NATFW NSLP provides for opening
firewall pin holes and creating NAT bindings to enable data flows to firewall pin holes and creating NAT bindings to enable data flows to
traverse these devices. Firewalls are normally expected to work on a traverse these devices. Firewalls are normally expected to work on a
'deny-all' policy, meaning that traffic not explicitly matching any 'deny-all' policy, meaning that traffic not explicitly matching any
firewall filter rule will be blocked. Similarly, the normal behavior firewall filter rule will be blocked. Similarly, the normal behavior
of NATs is to block all traffic that does not match any already of NATs is to block all traffic that does not match any already
configured/installed binding or session. However, some scenarios configured/installed binding or NATFW NSLP session. However, some
require support of firewalls having 'allow-all' policies, allowing scenarios require support of firewalls having 'allow-all' policies,
data traffic to traverse the firewall unless it is blocked allowing data traffic to traverse the firewall unless it is blocked
explicitly. Data receivers can utilize NATFW NSLP's EXT message with explicitly. Data receivers can utilize NATFW NSLP's EXT message with
action set to 'deny' to install policy rules at upstream firewalls to action set to 'deny' to install policy rules at inbound firewalls to
block unwanted traffic. block unwanted traffic.
The protocol works on a soft-state basis, meaning that whatever state The protocol works on a soft-state basis, meaning that whatever state
is installed or reserved on a middlebox will expire, and thus be de- is installed or reserved on a middlebox will expire, and thus be de-
installed or forgotten after a certain period of time. To prevent installed or forgotten after a certain period of time. To prevent
premature removal of state that is needed for ongoing communication, premature removal of state that is needed for ongoing communication,
the NATFW NI involved will have to specifically request a session the NATFW NI involved will have to specifically request a NATFW NSLP
extension. An explicit NATFW NSLP state deletion capability is also signaling session extension. An explicit NATFW NSLP state deletion
provided by the protocol. capability is also provided by the protocol.
If the actions requested by a NATFW NSLP message cannot be carried If the actions requested by a NATFW NSLP message cannot be carried
out, NFs and the NR must return a failure, such that appropriate out, NFs and the NR must return a failure, such that appropriate
actions can be taken. They can do this either during a the request actions can be taken. They can do this either during a the request
message handling (synchronously) by sending an error RESPONSE message handling (synchronously) by sending an error RESPONSE
message, or at any time (asynchronously) by sending a notification message, or at any time (asynchronously) by sending a notification
message. message.
The next sections define the NATFW NSLP message types and formats, The next sections define the NATFW NSLP message types and formats,
protocol operations, and policy rule operations. protocol operations, and policy rule operations.
3.2.1. Message Types 3.2.1. Message Types
The protocol uses four messages types: The protocol uses four messages types:
o CREATE: a request message used for creating, changing, refreshing, o CREATE: a request message used for creating, changing, refreshing,
and deleting NATFW NSLP signaling sessions, i.e., open the data and deleting NATFW NSLP signaling sessions, i.e., open the data
path from DS to DR. path from DS to DR.
o EXTERNAL (EXT): a request message used for reserving, changing, o EXTERNAL (EXT): a request message used for reserving, changing,
refreshing, and deleting EXT NATFW NSLP sessions. EXT messages refreshing, and deleting EXT NATFW NSLP signaling sessions. EXT
are forwarded to the edge-NAT or edge-firewall and allow inbound messages are forwarded to the edge-NAT or edge-firewall and allow
CREATE messages to be forwarded to the NR. Additionally, EXT inbound CREATE messages to be forwarded to the NR. Additionally,
messages reserve an external address and, if applicable, port EXT messages reserve an external address and, if applicable, port
number at an edge-NAT. number at an edge-NAT.
o NOTIFY: an asynchronous message used by NATFW peers to alert o NOTIFY: an asynchronous message used by NATFW peers to alert
upstream NATFW peers about specific events (especially failures). inbound NATFW peers about specific events (especially failures).
o RESPONSE: used as a response to CREATE and EXT request messages. o RESPONSE: used as a response to CREATE and EXT request messages.
3.2.2. Classification of RESPONSE Messages 3.2.2. Classification of RESPONSE Messages
RESPONSE messages will be generated synchronously to CREATE and EXT RESPONSE messages will be generated synchronously to CREATE and EXT
messages by NSIS Forwarders and Responders to report success or messages by NSIS Forwarders and Responders to report success or
failure of operations or some information relating to the session or failure of operations or some information relating to the NATFW NSLP
a node. RESPONSE messages MUST NOT be generated for any other signaling session or a node. RESPONSE messages MUST NOT be generated
message, such as NOTIFY and RESPONSE. for any other message, such as NOTIFY and RESPONSE.
All RESPONSE messages MUST carry a NATFW_INFO object which contains a All RESPONSE messages MUST carry a NATFW_INFO object which contains a
severity class code and a response code (see Section 4.2.4). This severity class code and a response code (see Section 4.2.4). This
section defines terms for groups of RESPONSE messages depending on section defines terms for groups of RESPONSE messages depending on
the severity class. the severity class.
o Successful RESPONSE: Messages carrying NATFW_INFO with severity o Successful RESPONSE: Messages carrying NATFW_INFO with severity
class 'Success' (0x2). class 'Success' (0x2).
o Informational RESPONSE: Messages carrying NATFW_INFO with severity o Informational RESPONSE: Messages carrying NATFW_INFO with severity
class 'Informational' (0x1) (only used with NOTIFY messages). class 'Informational' (0x1) (only used with NOTIFY messages).
o Error RESPONSE: Messages carrying NATFW_INFO with severity class o Error RESPONSE: Messages carrying NATFW_INFO with severity class
other than 'Success' or 'Informational'. other than 'Success' or 'Informational'.
3.2.3. NATFW NSLP Signaling Sessions 3.2.3. NATFW NSLP Signaling Sessions
A signaling session defines an association between the NI, NFs, and A NATFW NSLP signaling session defines an association between the NI,
the NR related to a data flow. This association is created when the NFs, and the NR related to a data flow. This association is created
initial CREATE or EXT message is successfully received at the NFs or when the initial CREATE or EXT message is successfully received at
the NR. There is signaling session state stored at the NTLP layer the NFs or the NR. There is signaling NATFW NSLP session state
and at the NATFW NSLP level. The signaling session state for the stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP
NATFW NSLP comprises NSLP state and the associated policy rules at a signaling session state for the NATFW NSLP comprises NSLP state and
middlebox. the associated policy rules at a middlebox.
The signaling session is identified by the session ID (plus other The NATFW NSLP signaling session is identified by the session ID
information at the NTLP level). The session ID is generated by the (plus other information at the NTLP level). The session ID is
NI before the initial CREATE or EXT message is sent. The value of generated by the NI before the initial CREATE or EXT message is sent.
the session ID MUST generated in a random way, i.e., the output MUST The value of the session ID MUST generated in a random way, i.e., the
NOT be easily guessable by third parties. The session ID is not output MUST NOT be easily guessable by third parties. The session ID
stored in any NATFW NSLP message but passed on to the NTLP. is not stored in any NATFW NSLP message but passed on to the NTLP.
A NATFW NSLP signaling session can conceptually be in different A NATFW NSLP signaling session can conceptually be in different
states, implementations may use other or even more states. The states, implementations may use other or even more states. The
signaling session can have these states at a node: signaling session can have these states at a node:
o Pending: The signaling session has been created and the node is o Pending: The NATFW NSLP signaling session has been created and the
waiting for a RESPONSE message to the CREATE or EXT message. A node is waiting for a RESPONSE message to the CREATE or EXT
signaling session in state 'Pending' MUST be marked as 'Dead' if message. A NATFW NSLP signaling session in state 'Pending' MUST
no corresponding RESPONSE message has been received within the be marked as 'Dead' if no corresponding RESPONSE message has been
time of the locally granted session lifetime of the forwarded received within the time of the locally granted NATFW NSLP
CREATE or EXT message (as described in Section 3.4). signaling session lifetime of the forwarded CREATE or EXT message
(as described in Section 3.4).
o Established: The signaling session is established, i.e, the o Established: The NATFW NSLP signaling session is established, i.e,
signaling has been successfully performed. A signaling session in the signaling has been successfully performed and the lifetime of
state 'Established' MUST be marked as 'Dead' if no refresh message NATFW NSLP signaling session is counted from now on. A NATFW NSLP
has been received within the time of the locally granted session signaling session in state 'Established' MUST be marked as 'Dead'
lifetime of the RESPONSE message (as described in Section 3.4). if no refresh message has been received within the time of the
locally granted NATFW NSLP signaling session lifetime of the
RESPONSE message (as described in Section 3.4).
o Dead: Either the signaling session is timed out or the node has o Dead: Either the NATFW NSLP signaling session is timed out or the
received an error RESPONSE message for the signaling session and node has received an error RESPONSE message for the NATFW NSLP
the signaling session can be deleted. signaling session and the NATFW NSLP signaling session can be
deleted.
o Transit: The node has received an asynchronous message, i.e., a o Transit: The node has received an asynchronous message, i.e., a
NOTIFY, and can delete the signaling session if needed. When a NOTIFY, and can delete the NATFW NSLP signaling session if needed.
node has received a NOTIFY message (for instance, indicating a When a node has received a NOTIFY message (for instance,
route change) it marks it as 'Transit' and deletes this session if indicating a route change) it marks it as 'Transit' and deletes
it is unused for some time specific to the local node. This idle this NATFW NSLP signaling session if it is unused for some time
time does not need to be fixed, since it can depend on the node specific to the local node. This idle time does not need to be
local maintenance cycle, i.e., the session could be deleted if the fixed, since it can depend on the node local maintenance cycle,
i.e., the NATFW NSLP signaling session could be deleted if the
node runs it garbage collection cycle. node runs it garbage collection cycle.
3.3. Basic Message Processing 3.3. Basic Message Processing
All NATFW messages are subject to some basic message processing when All NATFW messages are subject to some basic message processing when
received at a node, independent of message type. Initially, the received at a node, independent of message type. Initially, the
syntax of the NSLP message is checked and a RESPONSE message with an syntax of the NSLP message is checked and a RESPONSE message with an
appropriate error of class 'Protocol error' (0x1) code is generated appropriate error of class 'Protocol error' (0x1) code is generated
if any problem is detected. If a message is delivered to the NATFW if any problem is detected. If a message is delivered to the NATFW
NSLP, this implies that the NTLP layer has been able to correlate it NSLP, this implies that the NTLP layer has been able to correlate it
skipping to change at page 27, line 44 skipping to change at page 27, line 49
mechanism. Each signaling session is assigned a signaling session mechanism. Each signaling session is assigned a signaling session
lifetime and the signaling session is kept alive as long as the lifetime and the signaling session is kept alive as long as the
lifetime is valid. After the expiration of the signaling session lifetime is valid. After the expiration of the signaling session
lifetime, signaling sessions and policy rules MUST be removed lifetime, signaling sessions and policy rules MUST be removed
automatically and resources bound to them MUST be freed as well. automatically and resources bound to them MUST be freed as well.
Signaling session lifetime is handled at every NATFW NSLP node. The Signaling session lifetime is handled at every NATFW NSLP node. The
NSLP forwarders and NSLP responder MUST NOT trigger signaling session NSLP forwarders and NSLP responder MUST NOT trigger signaling session
lifetime extension refresh messages (see Section 3.7.3): this is the lifetime extension refresh messages (see Section 3.7.3): this is the
task of the NSIS initiator. task of the NSIS initiator.
The NSIS initiator MUST choose a signaling session lifetime value The NSIS initiator MUST choose a NATFW NSLP signaling session
(expressed in seconds) before sending any message, including the lifetime value (expressed in seconds) before sending any message,
initial message which creates the session, to other NSLP nodes. The including the initial message which creates the NATFW NSLP signaling
signaling session lifetime value is calculated based on: session, to other NSLP nodes. The NATFW NSLP signaling session
lifetime value is calculated based on:
o the number of lost refresh messages that NFs should cope with; o the number of lost refresh messages that NFs should cope with;
o the end-to-end delay between the NI and NR; o the end-to-end delay between the NI and NR;
o network vulnerability due to session hijacking ([8]), session o network vulnerability due to NATFW NSLP signaling session
hijacking is made easier when the NI does not explicitly remove hijacking ([8]), NATFW NSLP signaling session hijacking is made
the session); easier when the NI does not explicitly remove the NATFW NSLP
signaling session);
o the user application's data exchange duration, in terms of time o the user application's data exchange duration, in terms of time
and networking needs. This duration is modeled as M x R, with R and networking needs. This duration is modeled as M x R, with R
the message refresh period (in seconds) and M as a multiplier for the message refresh period (in seconds) and M as a multiplier for
R; R;
o the load on the signalling plane. Short lifetimes imply more o the load on the signalling plane. Short lifetimes imply more
frequent signaling messages. frequent signaling messages.
o the acceptable time for a signaling session to be present after it o the acceptable time for a NATFW NSLP signaling session to be
is no longer actually needed. For example, if the existence of present after it is no longer actually needed. For example, if
the signaling session implies a monetary cost and teardown cannot the existence of the NATFW NSLP signaling session implies a
be guaranteed, shorter lifetimes would be preferable. monetary cost and teardown cannot be guaranteed, shorter lifetimes
would be preferable.
The RSVP specification [13] provides an appropriate algorithm for o the lease time of the NI's IP address. The chosen NATFW NSLP
calculating the signaling session lifetime as well as means to avoid signaling session lifetime must be larger than the lease time,
refresh message synchronization between sessions. [13] recommends: otherwise the IP address can be re-assigned to a different node.
This node may receive unwanted traffic, although it never has
requested a NAT/firewall configuration, which might be an issue in
mobile environments.
The RSVP specification [11] provides an appropriate algorithm for
calculating the NATFW NSLP signaling session lifetime as well as
means to avoid refresh message synchronization between NATFW NSLP
signaling sessions. [11] recommends:
1. The refresh message timer to be randomly set to a value in the 1. The refresh message timer to be randomly set to a value in the
range [0.5R, 1.5R]. range [0.5R, 1.5R].
2. To avoid premature loss of state, lt (with lt being the signaling 2. To avoid premature loss of state, lt (with lt being the NATFW
session lifetime) must satisfy lt >= (K + 0.5)*1.5*R, where K is NSLP signaling session lifetime) must satisfy lt >= (K +
a small integer. Then in the worst case, K-1 successive messages 0.5)*1.5*R, where K is a small integer. Then in the worst case,
may be lost without state being deleted. Currently K = 3 is K-1 successive messages may be lost without state being deleted.
suggested as the default. However, it may be necessary to set a Currently K = 3 is suggested as the default. However, it may be
larger K value for hops with high loss rate. Other algorithms necessary to set a larger K value for hops with high loss rate.
could be used to define the relation between the signaling Other algorithms could be used to define the relation between the
session lifetime and the refresh message period; the algorithm NATFW NSLP signaling session lifetime and the refresh message
provided is only given as an example. period; the algorithm provided is only given as an example.
This requested signaling session lifetime value lt is stored in the This requested NATFW NSLP signaling session lifetime value lt is
NATFW_LT object of the NSLP message. stored in the NATFW_LT object of the NSLP message.
NSLP forwarders can execute the following behavior with respect to NSLP forwarders can execute the following behavior with respect to
the lifetime handling: the lifetime handling:
Requested signaling session lifetime acceptable: Requested signaling session lifetime acceptable:
No changes to the signaling session lifetime values are needed. No changes to the NATFW NSLP signaling session lifetime values are
The CREATE or EXT message is forwarded. needed. The CREATE or EXT message is forwarded.
Signaling session lifetime can be lowered: Signaling session lifetime can be lowered:
The NSLP responder MAY also lower the requested signaling session The NSLP responder MAY also lower the requested NATFW NSLP
lifetime to an acceptable value (based on its local policies). If signaling session lifetime to an acceptable value (based on its
an NF changes the signaling session lifetime value, it MUST store local policies). If an NF changes the NATFW NSLP signaling
the new value in the NATFW_LT object. The CREATE or EXT message session lifetime value, it MUST store the new value in the
is forwarded. NATFW_LT object. The CREATE or EXT message is forwarded.
Requested signaling session lifetime is too big: Requested signaling session lifetime is too big:
The NSLP responder MAY reject the requested signaling session The NSLP responder MAY reject the requested NATFW NSLP signaling
lifetime value as being too big and MUST generate an error session lifetime value as being too big and MUST generate an error
RESPONSE message of class 'Signaling session failures' (0x6) with RESPONSE message of class 'Signaling session failures' (0x6) with
response code 'Requested lifetime is too big' (0x02) upon response code 'Requested lifetime is too big' (0x02) upon
rejection. Lowering the lifetime is preferred instead of rejection. Lowering the lifetime is preferred instead of
generating an error message. generating an error message.
Requested signaling session lifetime is too small: Requested signaling session lifetime is too small:
The NSLP responder MAY reject the requested signaling session The NSLP responder MAY reject the requested NATFW NSLP signaling
lifetime value as being to small and MUST generate an error session lifetime value as being to small and MUST generate an
RESPONSE message of class 'Signaling session failures' (0x6) with error RESPONSE message of class 'Signaling session failures' (0x6)
response code 'Requested lifetime is too small' (0x10) upon with response code 'Requested lifetime is too small' (0x10) upon
rejection. rejection.
NFs MUST NOT increase the signaling session lifetime value. Messages NFs MUST NOT increase the NATFW NSLP signaling session lifetime
can be rejected on the basis of the signaling session lifetime being value. Messages can be rejected on the basis of the NATFW NSLP
too long when a session is first created and also on refreshes. signaling session lifetime being too long when a NATFW NSLP signaling
session is first created and also on refreshes.
The NSLP responder generates a successful RESPONSE for the received The NSLP responder generates a successful RESPONSE for the received
CREATE or EXT message, sets the signaling session lifetime value in CREATE or EXT message, sets the NATFW NSLP signaling session lifetime
the NATFW_LT object to the above granted lifetime and sends the value in the NATFW_LT object to the above granted lifetime and sends
message back towards NSLP initiator. 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 signaling session lifetime value. The forwarders MUST the granted NATFW NSLP signaling session lifetime value. The
accept the granted signaling session lifetime, as long as this value forwarders MUST accept the granted NATFW NSLP signaling session
is less than or equal to the acceptable value. The acceptable value lifetime, as long as this value is less than or equal to the
refers to the value accepted by the NSLP forwarder when processing acceptable value. The acceptable value refers to the value accepted
the CREATE or EXT message. For received values greater than the by the NSLP forwarder when processing the CREATE or EXT message. For
acceptable value, NSLP forwarders MUST generate a RESPONSE message of received values greater than the acceptable value, NSLP forwarders
class 'Signaling session failures' (0x6) with response code
'Requested lifetime is too big' (0x02). For received values lower
than the values acceptable by the node local policy, NSLP forwarders
MUST generate a RESPONSE message of class 'Signaling session MUST generate a RESPONSE message of class 'Signaling session
failures' (0x6) with response code 'Requested lifetime is too small' failures' (0x6) with response code 'Requested lifetime is too big'
(0x10). Figure 12 shows the procedure with an example, where an (0x02). For received values lower than the values acceptable by the
initiator requests 60 seconds lifetime in the CREATE message and the node local policy, NSLP forwarders MUST generate a RESPONSE message
lifetime is shortened along the path by the forwarder to 20 seconds of class 'Signaling session failures' (0x6) with response code
and by the responder to 15 seconds. When the NSLP forwarder receives 'Requested lifetime is too small' (0x10). Figure 12 shows the
the RESPONSE message with a signaling session lifetime value of 15 procedure with an example, where an initiator requests 60 seconds
seconds it checks whether this value is lower or equal to the lifetime in the CREATE message and the lifetime is shortened along
acceptable value. the path by the forwarder to 20 seconds and by the responder to 15
seconds. When the NSLP forwarder receives the RESPONSE message with
a NATFW NSLP signaling session lifetime value of 15 seconds it checks
whether this value is lower or equal to the acceptable value.
+-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+
| |---------------->| NSLP |---------------->| | | |---------------->| NSLP |---------------->| |
| NI | | forwarder | | NR | | NI | | forwarder | | NR |
| |<----------------| check 15<20 |<----------------| | | |<----------------| check 15<20 |<----------------| |
+-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+
lt = lifetime lt = lifetime
Figure 12: Signaling Session Lifetime Setting Example Figure 12: Signaling Session Lifetime Setting Example
skipping to change at page 30, line 36 skipping to change at page 31, line 5
time. Messages can be lost along the path or duplicated. So all time. Messages can be lost along the path or duplicated. So all
NATFW NSLP nodes should be able to identify either old messages that NATFW NSLP nodes should be able to identify either old messages that
have been received before (duplicated), or the case that messages have been received before (duplicated), or the case that messages
have been lost before (loss). For message replay protection it is have been lost before (loss). For message replay protection it is
necessary to keep information about messages that have already been necessary to keep information about messages that have already been
received and requires every NATFW NSLP message to carry a message received and requires every NATFW NSLP message to carry a message
sequence number (MSN), see also Section 4.2.6. sequence number (MSN), see also Section 4.2.6.
The MSN MUST be set by the NI and MUST NOT be set or modified by any The MSN MUST be set by the NI and MUST NOT be set or modified by any
other node. The initial value for the MSN MUST be generated randomly other node. The initial value for the MSN MUST be generated randomly
and MUST be unique only within the session for which it is used. The and MUST be unique only within the NATFW NSLP signaling session for
NI MUST increment the MSN by one for every message sent. Once the which it is used. The NI MUST increment the MSN by one for every
MSN has reached the maximum value, the next value it takes is zero. message sent. Once the MSN has reached the maximum value, the next
All NATFW NSLP nodes MUST use the algorithm defined in [3] to detect value it takes is zero. All NATFW NSLP nodes MUST use the algorithm
MSN wrap-arounds. defined in [3] to detect MSN wrap-arounds.
NSIS forwarders and the responder store the MSN from the initial NSIS forwarders and the responder store the MSN from the initial
CREATE or EXT packet which creates the session as the start value for CREATE or EXT packet which creates the NATFW NSLP signaling session
the session. NFs and NRs MUST include the received MSN value in the as the start value for the NATFW NSLP signaling session. NFs and NRs
corresponding RESPONSE message that they generate. MUST include the received MSN value in the corresponding RESPONSE
message that they generate.
When receiving a CREATE or EXT message, a NATFW NSLP node uses the When receiving a CREATE or EXT message, a NATFW NSLP node uses the
MSN given in the message to determine whether the state being MSN given in the message to determine whether the state being
requested is different to the state already installed. The message requested is different to the state already installed. The message
MUST be discarded if the received MSN value is equal to or lower than MUST be discarded if the received MSN value is equal to or lower than
the stored MSN value. Such a received MSN value can indicate a the stored MSN value. Such a received MSN value can indicate a
duplicated and delayed message or replayed message. If the received duplicated and delayed message or replayed message. If the received
MSN value is greater than the already stored MSN value, the NATFW MSN value is greater than the already stored MSN value, the NATFW
NSLP MUST update its stored state accordingly, if permitted by all NSLP MUST update its stored state accordingly, if permitted by all
security checks (see Section 3.6), and stores the updated MSN value security checks (see Section 3.6), and stores the updated MSN value
skipping to change at page 31, line 32 skipping to change at page 31, line 49
The requirements on authentication and authorization are quite The requirements on authentication and authorization are quite
different between these use cases. While a home gateway, or an different between these use cases. While a home gateway, or an
Internet cafe, using NSIS may well be happy with a "NATFW signaling Internet cafe, using NSIS may well be happy with a "NATFW signaling
coming from inside the network" policy for authorization of coming from inside the network" policy for authorization of
signaling, enterprise networks are likely to require more strongly signaling, enterprise networks are likely to require more strongly
authenticated/authorized signaling. This enterprise scenario may authenticated/authorized signaling. This enterprise scenario may
require the use of an infrastructure and administratively assigned require the use of an infrastructure and administratively assigned
identities to operate the NATFW NSLP. identities to operate the NATFW NSLP.
Once the NI is authenticated and authorized, another step is Once the NI is authenticated and authorized, another step is
performed. The requested policy rule for the session is checked performed. The requested policy rule for the NATFW NSLP signaling
against a set of policy rules, i.e., whether the requesting NI is session is checked against a set of policy rules, i.e., whether the
allowed to request the policy rule to be loaded in the device. If requesting NI is allowed to request the policy rule to be loaded in
this fails the NF or NR must send an error RESPONSE of class the device. If this fails the NF or NR must send an error RESPONSE
'Permanent failure' (0x5) and with response code 'Authorization of class 'Permanent failure' (0x5) and with response code
failed' (0x02). 'Authorization failed' (0x02).
3.7. Protocol Operations 3.7. Protocol Operations
This section defines the protocol operations including, how to create This section defines the protocol operations including, how to create
sessions, maintain them, and how to reserve addresses. NATFW NSLP signaling sessions, maintain them, and how to reserve
addresses.
3.7.1. Creating Sessions 3.7.1. Creating Signaling Sessions
Allowing two hosts to exchange data even in the presence of Allowing two hosts to exchange data even in the presence of
middleboxes is realized in the NATFW NSLP by use of the CREATE middleboxes is realized in the NATFW NSLP by use of the CREATE
message. The NI (either the data sender or a proxy) generates a message. The NI (either the data sender or a proxy) generates a
CREATE message as defined in Section 4.3.1 and hands it to the NTLP. CREATE message as defined in Section 4.3.1 and hands it to the NTLP.
The NTLP forwards the whole message on the basis of the message The NTLP forwards the whole message on the basis of the message
routing information (MRI) towards the NR. Each NSIS forwarder along routing information (MRI) towards the NR. Each NSIS forwarder along
the path that implements NATFW NSLP, processes the NSLP message. the path that implements NATFW NSLP, processes the NSLP message.
Forwarding is thus managed NSLP hop-by-hop but may pass transparently Forwarding is thus managed NSLP hop-by-hop but may pass transparently
through NSIS forwarders which do not contain NATFW NSLP functionality through NSIS forwarders which do not contain NATFW NSLP functionality
skipping to change at page 32, line 34 skipping to change at page 33, line 5
| | RESPONSE | | | RESPONSE |
| RESPONSE |<---------------------------| | RESPONSE |<---------------------------|
|<-----------------------------| | |<-----------------------------| |
| | | | | |
| | | | | |
Figure 13: CREATE message flow with success RESPONSE Figure 13: CREATE message flow with success RESPONSE
There are several processing rules for a NATFW peer when generating There are several processing rules for a NATFW peer when generating
and receiving CREATE messages, since this message type is used for and receiving CREATE messages, since this message type is used for
creating new signaling sessions, updating existing, extending the creating new NATFW NSLP signaling session, updating existing,
lifetime and deleting signaling session. The three latter functions extending the lifetime and deleting NATFW NSLP signaling session.
operate in the same way for all kinds of CREATE message, and are The three latter functions operate in the same way for all kinds of
therefore described in separate sections: CREATE message, and are therefore described in separate sections:
o Extending the lifetime of signaling sessions is described in o Extending the lifetime of NATFW NSLP signaling sessions is
Section 3.7.3. described in Section 3.7.3.
o Deleting signaling sessions is described in Section 3.7.4. o Deleting NATFW NSLP signaling sessions is described in
Section 3.7.4.
o Updating policy rules is described in Section 3.10. o Updating policy rules is described in Section 3.10.
For an initial CREATE message creating a new NATFW NSLP session, the For an initial CREATE message creating a new NATFW NSLP signaling
processing of CREATE messages is different for every NATFW node type: session, the 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 CREATE them over to the NTLP. The NI should never receive CREATE
messages and MUST discard it. messages and MUST discard it.
o NATFW NSLP forwarder: NFs that are unable to forward the CREATE o NATFW NSLP forwarder: NFs that are unable to forward the CREATE
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' (0x07). 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
skipping to change at page 34, line 32 skipping to change at page 34, line 49
o NSLP initiator: After receiving a successful RESPONSE, the data o NSLP initiator: After receiving a successful RESPONSE, the data
path is configured and the DS can start sending its data to the path is configured and the DS can start sending its data to the
DR. After receiving an error RESPONSE message, the NI MAY try to DR. After receiving an error RESPONSE message, the NI MAY try to
generate the CREATE message again or give up and report the generate the CREATE message again or give up and report the
failure to the application, depending on the error condition. failure to the application, depending on the error condition.
o NSLP forwarder: NFs install the remembered policy rules, if a o NSLP forwarder: NFs install the remembered policy rules, if a
successful RESPONSE message with matching SID and MSN is received. successful RESPONSE message with matching SID and MSN is received.
If an ERROR RESPONSE message with matching SID and MSN is If an ERROR RESPONSE message with matching SID and MSN is
received, the session is marked as dead, no policy rule is received, the NATFW NSLP session is marked as dead, no policy rule
installed and the remembered rule is discarded. is installed and the remembered rule is discarded.
o NSIS responder: The NR should never receive RESPONSE messages and o NSIS responder: The NR should never receive RESPONSE messages and
MUST silently drop any such messages received. MUST silently drop any such messages received.
3.7.2. Reserving External Addresses 3.7.2. Reserving External Addresses
NSIS signaling is intended to travel end-to-end, even in the presence NSIS signaling is intended to travel end-to-end, even in the presence
of NATs and firewalls on-path. This works well in cases where the of NATs and firewalls on-path. This works well in cases where the
data sender is itself behind a NAT or a firewall as described in data sender is itself behind a NAT or a firewall as described in
Section 3.7.1. For scenarios where the data receiver is located Section 3.7.1. For scenarios where the data receiver is located
behind a NAT or a firewall and it needs to receive data flows from behind a NAT or a firewall and it needs to receive data flows from
outside its own network (usually referred to as inbound flows, see outside its own network (usually referred to as inbound flows, see
Figure 5) the problem is more troublesome. Figure 5) the problem is more troublesome.
NSIS signaling, as well as subsequent data flows, are directed to a NSIS signaling, as well as subsequent data flows, are directed to a
particular destination IP address that must be known in advance and particular destination IP address that must be known in advance and
reachable. Data receivers must tell the local NSIS infrastructure reachable. Data receivers must tell the local NSIS infrastructure
(i.e., the upstream firewalls/NATs) about incoming NATFW NSLP (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP
signaling and data flows before they can receive these flows. It is signaling and data flows before they can receive these flows. It is
necessary to differentiate between data receivers behind NATs and necessary to differentiate between data receivers behind NATs and
behind firewalls for understanding the further NATFW procedures. behind firewalls for understanding the further NATFW procedures.
Data receivers that are only behind firewalls already have a public Data receivers that are only behind firewalls already have a public
IP address and they need only to be reachable for NATFW signaling. IP address and they need only to be reachable for NATFW signaling.
Unlike data receivers behind just firewalls, data receivers behind Unlike data receivers behind just firewalls, data receivers behind
NATs do not have public IP addresses; consequently they are not NATs do not have public IP addresses; consequently they are not
reachable for NATFW signaling by entities outside their addressing reachable for NATFW signaling by entities outside their addressing
realm. realm.
The preceding discussion addresses the situation where a DR node that The preceding discussion addresses the situation where a DR node that
wants to be reachable is unreachable because the NAT lacks a suitable wants to be reachable is unreachable because the NAT lacks a suitable
rule with the 'allow' action which would forward inbound data. rule with the 'allow' action which would forward inbound data.
However, in certain scenarios, a node situated behind upstream However, in certain scenarios, a node situated behind inbound
firewalls that do not block inbound data traffic (firewalls with firewalls that do not block inbound data traffic (firewalls with
"default to allow") unless requested might wish to prevent traffic "default to allow") unless requested might wish to prevent traffic
being sent to it from specified addresses. In this case, NSIS NATFW being sent to it from specified addresses. In this case, NSIS NATFW
signaling can be used to achieve this by installing a policy rule signaling can be used to achieve this by installing a policy rule
with its action set to 'deny' using the same mechanisms as for with its action set to 'deny' using the same mechanisms as for
'allow' rules. 'allow' rules.
The required result is obtained by sending a EXTERNAL (EXT) message The required result is obtained by sending a EXTERNAL (EXT) message
in the upstream direction of the intended data flow. When using this in the inbound direction of the intended data flow. When using this
functionality the NSIS initiator for the 'Reserve External Address' functionality the NSIS initiator for the 'Reserve External Address'
signaling is typically the node that will become the DR for the signaling is typically the node that will become the DR for the
eventual data flow. To distinguish this initiator from the usual eventual data flow. To distinguish this initiator from the usual
case where the NI is associated with the DS, the NI is denoted by NI+ case where the NI is associated with the DS, the NI is denoted by NI+
and the NSIS responder is similarly denoted by NR+. and the NSIS responder is similarly denoted by NR+.
Public Internet Private Address Public Internet Private Address
Space Space
Edge Edge
skipping to change at page 37, line 15 skipping to change at page 37, line 15
Basically, there are two different signaling scenarios. Either Basically, there are two different signaling scenarios. Either
1. the DR behind the NAT/firewall knows the IP address of the DS in 1. the DR behind the NAT/firewall knows the IP address of the DS in
advance, advance,
2. or the address of DS is not known in advance. 2. or the address of DS is not known in advance.
Case 1 requires the NATFW NSLP to request the path-coupled message Case 1 requires the NATFW NSLP to request the path-coupled message
routing method (PC-MRM) from the NTLP. The EXT message MUST be sent routing method (PC-MRM) from the NTLP. The EXT message MUST be sent
with PC-MRM (see Section 5.8.1 in [2]) with the direction set to with PC-MRM (see Section 5.8.1 in [2]) with the direction set to
'upstream'. The handling of case 2 depends on the situation of DR: 'upstream' (inbound). The handling of case 2 depends on the
If DR is solely located behind a firewall, the EXT message MUST be situation of DR: If DR is solely located behind a firewall, the EXT
sent with the PC-MRM, direction 'upstream', and data flow source IP message MUST be sent with the PC-MRM, direction 'upstream' (inbound),
address set to wildcard. If DR is located behind a NAT, the EXT and data flow source IP address set to wildcard. If DR is located
message MUST be sent with the loose-end message routing method (LE- behind a NAT, the EXT message MUST be sent with the loose-end message
MRM, see Section 5.8.2 in [2]), the destination-address set to the routing method (LE-MRM, see Section 5.8.2 in [2]), the destination-
signaling destination address (SDA, see also Appendix A). For address set to the signaling destination address (SDA, see also
scenarios with DR being behind a firewall, special conditions apply Appendix A). For scenarios with DR being behind a firewall, special
(applicability statement, Appendix B). The data receiver is conditions apply (applicability statement, Appendix B). The data
challenged to determine whether it is solely located behind firewalls receiver is challenged to determine whether it is solely located
or NATs, for choosing the right message routing method. This behind firewalls or NATs, for choosing the right message routing
decision can depend on a local configuration parameter, possibly method. This decision can depend on a local configuration parameter,
given through DHCP, or it could be discovered through other non-NSLP possibly given through DHCP, or it could be discovered through other
related testing of the network configuration. non-NSLP related testing of the network configuration.
For case 2 with NAT, the NI+ (which could be on the data receiver DR For case 2 with NAT, the NI+ (which could be on the data receiver DR
or on any other host within the private network) sends the EXT or on any other host within the private network) sends the EXT
message targeted to the signaling destination address. The message message targeted to the signaling destination address. The message
routing for the EXT message is in the reverse direction to the normal routing for the EXT message is in the reverse direction to the normal
message routing used for path-coupled signaling where the signaling message routing used for path-coupled signaling where the signaling
is sent downstream (as opposed to upstream in this case). When is sent outbound (as opposed to inbound in this case). When
establishing NAT bindings (and an NSIS session) the signaling establishing NAT bindings (and an NATFW NSLP signaling session) the
direction does not matter since the data path is modified through signaling direction does not matter since the data path is modified
route pinning due to the external IP address at the NAT. Subsequent through route pinning due to the external IP address at the NAT.
NSIS messages (and also data traffic) will travel through the same Subsequent NSIS messages (and also data traffic) will travel through
NAT boxes. However, this is only valid for the NAT boxes, but not the same NAT boxes. However, this is only valid for the NAT boxes,
for any intermediate firewall. That is the reason for having a but not for any intermediate firewall. That is the reason for having
separate CREATE message enabling the reservations made with EXT at a separate CREATE message enabling the reservations made with EXT at
the NATs and either enabling prior reservations or creating new the NATs and either enabling prior reservations or creating new
pinholes at the firewalls which are encountered on the downstream pinholes at the firewalls which are encountered on the outbound path
path depending on whether the upstream and downstream routes depending on whether the inbound and outbound routes coincide.
coincide.
The EXT signaling message creates an NSIS NATFW session at any The EXT signaling message creates an NSIS NATFW signaling session at
intermediate NSIS NATFW peer(s) encountered, independent of the any intermediate NSIS NATFW peer(s) encountered, independent of the
message routing method used. Furthermore, it has to be ensured that message routing method used. Furthermore, it has to be ensured that
the edge-NAT or edge-firewall device is discovered as part of this the edge-NAT or edge-firewall device is discovered as part of this
process. The end host cannot be assumed to know this device - process. The end host cannot be assumed to know this device -
instead the NAT or firewall box itself is assumed to know that it is instead the NAT or firewall box itself is assumed to know that it is
located at the outer perimeter of the network. Forwarding of the EXT located at the outer perimeter of the network. Forwarding of the EXT
message beyond this entity is not necessary, and MUST be prohibited message beyond this entity is not necessary, and MUST be prohibited
as it may provide information on the capabilities of internal hosts. as it may provide information on the capabilities of internal hosts.
It should be noted, that it is the outermost NAT or firewall that is It should be noted, that it is the outermost NAT or firewall that is
the edge-device that must be found during this discovery process. the edge-device that must be found during this discovery process.
For instance, when there are a NAT and afterwards a firewall on the For instance, when there are a NAT and afterwards a firewall on the
outbound path at the network border, the firewall is the edge- outbound path at the network border, the firewall is the edge-
firewall. All messages must be forwarded to the topology-wise firewall. All messages must be forwarded to the topology-wise
outermost edge-device, to ensure that this devices knows about the outermost edge-device, to ensure that this devices knows about the
signaling sessions for incoming CREATE messages. However, the NAT is NATFW NSLP signaling sessions for incoming CREATE messages. However,
still the edge-NAT because it has a public globally routable IP the NAT is still the edge-NAT because it has a public globally
address on its public side: this is not affected by any firewall routable IP address on its public side: this is not affected by any
between the edge-NAT and the public network. firewall between the edge-NAT and the public network.
Possible edge arrangements are: Possible edge arrangements are:
Public Net ----------------- Private net -------------- Public Net ----------------- Private net --------------
| Public Net|--|Edge-FW|--|FW|...|FW|--|DR| | Public Net|--|Edge-FW|--|FW|...|FW|--|DR|
| Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR| | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR|
| Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR| | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR|
The edge-NAT or edge-firewall device closest to the public realm The edge-NAT or edge-firewall device closest to the public realm
responds to the EXT message with a successful RESPONSE message. An responds to the EXT message with a successful RESPONSE message. An
edge-NAT includes an NATFW_EXT_IP object (see Section 4.2.2), edge-NAT includes an NATFW_EXT_IP object (see Section 4.2.2),
carrying the public reachable IP address, and if applicable port carrying the public reachable IP address, and if applicable port
number. number.
There are several processing rules for a NATFW peer when generating There are several processing rules for a NATFW peer when generating
and receiving EXT messages, since this message type is used for and receiving EXT messages, since this message type is used for
creating new reserve signaling sessions, updating existing, extending creating new reserve NATFW NSLP signaling sessions, updating
the lifetime and deleting signaling session. The three latter existing, extending the lifetime and deleting NATFW NSLP signaling
functions operate in the same way for all kinds of CREATE and EXT session. The three latter functions operate in the same way for all
messages, and are therefore described in separate sections: kinds of CREATE and EXT messages, and are therefore described in
separate sections:
o Extending the lifetime of signaling sessions is described in o Extending the lifetime of NATFW NSLP signaling sessions is
Section 3.7.3. described in Section 3.7.3.
o Deleting signaling sessions is described in Section 3.7.4. o Deleting NATFW NSLP signaling sessions is described in
Section 3.7.4.
o Updating policy rules is described in Section 3.10. o Updating policy rules is described in Section 3.10.
The NI+ MAY include a NATFW_DTINFO object in the EXT message when The NI+ MUST include a NATFW_DTINFO object in the EXT message when
using the LE-MRM. The LE-MRM does not include enough information for using the LE-MRM. The LE-MRM does not include enough information for
some types of NATs (basically, those NATs which also translate port some types of NATs (basically, those NATs which also translate port
numbers) to perform the address translation. This information is numbers) to perform the address translation. This information is
provided in the NATFW_DTINFO (see Section 4.2.7). This information provided in the NATFW_DTINFO (see Section 4.2.7). This information
SHOULD include at least the 'dst port number' and 'protocol' fields, MUST include at least the 'dst port number' and 'protocol' fields, in
in the DTInfo object as these may be required by en-route NATs, the NATFW_DTINFO object as these may be required by en-route NATs,
depending on the type of the NAT. All other fields MAY be set by the depending on the type of the NAT. All other fields MAY be set by the
NI+ to restrict the set of possible NIs. An edge-NAT will use the NI+ to restrict the set of possible NIs. An edge-NAT will use the
information provided in the NATFW_DTINFO object to allow only NATFW information provided in the NATFW_DTINFO object to allow only NATFW
CREATE message with the MRI matching ('src IPv4/v6 address', 'src CREATE message with the MRI matching ('src IPv4/v6 address', 'src
port number', 'protocol') to be forwarded. A NAT requiring port number', 'protocol') to be forwarded. A NAT requiring
information carried in the NATFW_DTINFO can generate a number of information carried in the NATFW_DTINFO can generate a number of
error RESPONSE messages of class 'Signaling session failures' (0x6): error RESPONSE messages of class 'Signaling session failures' (0x6):
o 'Requested policy rule denied due to policy conflict' (0x04) o 'Requested policy rule denied due to policy conflict' (0x04)
o 'DTINFO object is required' (0x07) o 'NATFW_DTINFO object is required' (0x07)
o 'Requested value in sub_ports field in NATFW_EFI not permitted' o 'Requested value in sub_ports field in NATFW_EFI not permitted'
(0x08) (0x08)
o 'Requested IP protocol not supported' (0x09) o 'Requested IP protocol not supported' (0x09)
o 'Plain IP policy rules not permitted -- need transport layer o 'Plain IP policy rules not permitted -- need transport layer
information' (0x0A) information' (0x0A)
o 'source IP address range is too large' (0x0C) o 'source IP address range is too large' (0x0C)
o 'destination IP address range is too large' (0x0D) o 'destination IP address range is too large' (0x0D)
o 'source L4-port range is too large' (0x0E) o 'source L4-port range is too large' (0x0E)
o 'destination L4-port range is too large' (0x0F) o 'destination L4-port range is too large' (0x0F)
Processing of EXT messages is specific to the NSIS node type: Processing of EXT messages is specific to the NSIS node type:
o NSLP initiator: NI+ only generate EXT messages. When the data o NSLP initiator: NI+ only generate EXT messages. When the data
sender's address information is known in advance the NI+ MAY sender's address information is known in advance the NI+ can
include a NATFW_DTINFO object in the EXT message (as described include a NATFW_DTINFO object in the EXT message, if not anyway
above). When the data sender's IP address is not known, the NI+ required to do so (see above). When the data sender's IP address
MUST NOT include a NATFW_DTINFO object. The NI should never is not known, the NI+ MUST NOT include a NATFW_DTINFO object. The
receive EXT messages and MUST silently discard it. NI should never receive EXT messages and MUST silently discard it.
o NSLP forwarder: The NSLP message processing at NFs depends on the o NSLP forwarder: The NSLP message processing at NFs depends on the
middlebox type: middlebox type:
* NAT: NATs check whether the message is received at the external * NAT: NATs check whether the message is received at the external
(public in most cases) address or at the internal (private) (public in most cases) address or at the internal (private)
address. If received at the external address a NF MUST address. If received at the external an NF MUST generate an
generate an error RESPONSE of class 'Protocol error' (0x3) with error RESPONSE of class 'Protocol error' (0x3) with response
response code 'Received EXT request message on external side' code 'Received EXT request message on external side' (0x0B).
(0x0B) MUST be generated. If received at the internal (private If received at the internal (private address) and the NATFW_EFI
address) and the NATFW_EFI object contains the action 'deny', object contains the action 'deny', an error RESPONSE of class
an error RESPONSE of class 'Protocol error' (0x3) with response 'Protocol error' (0x3) with response code 'Requested rule
code 'Requested rule action not applicable' (0x06) MUST be action not applicable' (0x06) MUST be generated. If received
generated. If received at the internal address, an IP address, at the internal address, an IP address, and if applicable one
and if applicable a port, is reserved. If it is an edge-NAT or more ports, are reserved. If it is an edge-NAT and there is
and there is no edge-firewall beyond, the NSLP message is not no edge-firewall beyond, the NSLP message is not forwarded any
forwarded any further and a successful RESPONSE message is further and a successful RESPONSE message is generated
generated containing an NATFW_EXT_IP object holding the containing an NATFW_EXT_IP object holding the translated
translated address, and if applicable port, information in the address, and if applicable port, information from the binding
binding reserved as a result of the EXT message. The RESPONSE reserved as a result of the EXT message. The RESPONSE message
message is sent back towards the NI+. If it is not an edge- is sent back towards the NI+. If it is not an edge-NAT, the
NAT, the NSLP message is forwarded further using the translated NSLP message is forwarded further using the translated IP
IP address as signaling source address and including the address as signaling source address in the LE-MRM and
translated IP address/port in the MRI. The edge-NAT or any translated port in the NATFW_DTINFO object in the field 'DR
other NAT MAY reject EXT messages not carrying a NATFW_DTINFO port number', i.e., the NATFW_DTINFO object is updated to
object or if the address information within this object is reflect the translated port number. The edge-NAT or any other
invalid or is not compliant with local policies (e.g., the NAT MUST reject EXT messages not carrying a NATFW_DTINFO object
information provided relates to a range of addresses or if the address information within this object is invalid or
('wildcarded') but the edge-NAT requires exact information is not compliant with local policies (e.g., the information
about DS' IP address and port) with the above mentioned provided relates to a range of addresses ('wildcarded') but the
response codes. edge-NAT requires exact information about DS' IP address and
port) with the above mentioned response codes.
* Firewall: Non edge-firewalls remember the requested policy * Firewall: Non edge-firewalls remember the requested policy
rule, keep session state, and forward the message. Edge- rule, keep NATFW NSLP signaling session state, and forward the
firewalls stop forwarding the EXT message. The policy rule is message. Edge-firewalls stop forwarding the EXT message. The
immediately loaded if the action in the NATFW_EFI object is set policy rule is immediately loaded if the action in the
to 'deny' and the node is an edge-firewall. The policy rule is NATFW_EFI object is set to 'deny' and the node is an edge-
remembered, but not activated, if the action in the NATFW_EFI firewall. The policy rule is remembered, but not activated, if
object is set to 'allow'. In both cases, a successful RESPONSE the action in the NATFW_EFI object is set to 'allow'. In both
message is generated. cases, a successful RESPONSE message is generated. If the
action is 'allow', and the NATFW_DTINFO object is included, and
the MRM is set to LE-MRM in the request, additionally an
NATFW_EXT_IP object is included in the RESPONSE message,
holding the translated address, and if applicable port,
information. This information is obtained from the
NATFW_DTINFO object's 'DR port number' and the source-address
of the LE-MRM.
* 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'
(0x06). (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 NATFW NSLP signaling sessions. If the response contains an
can use IP address and port pairs carried for further application NATFW_EXT_IP object, the NI can use IP address and port pairs
signaling. After receiving a error RESPONSE message, the NI+ MAY carried for further application signaling. After receiving a
try to generate the EXT message again or give up and report the error RESPONSE message, the NI+ MAY try to generate the EXT
failure to the application, depending on the error condition. message again or give up and report the failure to the
application, depending on the error condition.
o NSLP forwarder: NFs simply forward this message as long as they o NSLP forwarder: NFs simply forward this message as long as they
keep state for the requested reservation, if the RESPONSE message keep state for the requested reservation, if the RESPONSE message
contains NATFW_INFO object with class set to 'Success' (0x2). If contains NATFW_INFO object with class set to 'Success' (0x2). If
the RESPONSE message contains NATFW_INFO object with class set not the RESPONSE message contains NATFW_INFO object with class set not
to 'Success' (0x2), the session is marked as dead. to 'Success' (0x2), the NATFW NSLP signaling session is marked as
dead.
o NSIS responder: This type of message should never be received by o NSIS responder: This type of message should never be received by
any NR+. The NF should never receive response messages and MUST any NR+. The NF should never receive response messages and MUST
silently discard it. silently discard it.
Reservations with action 'allow' made with EXT MUST be enabled by a Reservations with action 'allow' made with EXT MUST be enabled by a
subsequent CREATE message. A reservation made with EXT (independent subsequent CREATE message. A reservation made with EXT (independent
of selected action) is kept alive as long as the NI+ refreshes the of selected action) is kept alive as long as the NI+ refreshes the
particular signaling session and it can be reused for multiple, particular NATFW NSLP signaling session and it can be reused for
different CREATE messages. An NI+ may decide to teardown a multiple, different CREATE messages. An NI+ may decide to teardown a
reservation immediately after receiving a CREATE message. Without reservation immediately after receiving a CREATE message. This
using CREATE Section 3.7.1 or EXT in proxy mode Section 3.7.6 no data implies that a new NATFW NSLP signaling session must be created for
traffic will be forwarded to DR beyond the edge-NAT or edge-firewall. each new CREATE message. The CREATE message does not re-use the
The only function of EXT is to ensure that subsequent CREATE messages NATFW NSLP signaling session created by REA.
traveling towards the NR will be forwarded across the public-private
boundary towards the DR. Correlation of incoming CREATE messages to
EXT reservation states is described in Section 3.8.
3.7.3. NATFW Session Refresh Without using CREATE Section 3.7.1 or EXT in proxy mode Section 3.7.6
no data traffic will be forwarded to DR beyond the edge-NAT or edge-
firewall. The only function of EXT is to ensure that subsequent
CREATE messages traveling towards the NR will be forwarded across the
public-private boundary towards the DR. Correlation of incoming
CREATE messages to EXT reservation states is described in
Section 3.8.
NATFW NSLP sessions are maintained on a soft-state basis. After a 3.7.3. NATFW NSLP Signaling Session Refresh
specified timeout, sessions and corresponding policy rules are
removed automatically by the middlebox, if they are not refreshed. NATFW NSLP signaling sessions are maintained on a soft-state basis.
Soft-state is created by CREATE and EXT and the maintenance of this After a specified timeout, sessions and corresponding policy rules
state must be done by these messages. State created by CREATE must are removed automatically by the middlebox, if they are not
be maintained by CREATE, state created by EXT must be maintained by refreshed. Soft-state is created by CREATE and EXT and the
EXT. Refresh messages, are messages carrying the same session ID as maintenance of this state must be done by these messages. State
the initial message and a NATFW_LT lifetime object with a lifetime created by CREATE must be maintained by CREATE, state created by EXT
greater than zero. Messages with the same SID but carrying a must be maintained by EXT. Refresh messages, are messages carrying
different MRI are treated as updates of the policy rules and are the same session ID as the initial message and a NATFW_LT lifetime
processed as defined in Section 3.10. Every refresh CREATE or EXT object with a lifetime greater than zero. Messages with the same SID
message MUST be acknowledged by an appropriate response message but carrying a different MRI are treated as updates of the policy
generated by the NR. Upon reception by each NSIS forwarder, the rules and are processed as defined in Section 3.10. Every refresh
state for the given session ID is extended by the session refresh CREATE or EXT message MUST be acknowledged by an appropriate response
period, a period of time calculated based on a proposed refresh message generated by the NR. Upon reception by each NSIS forwarder,
message period. The lifetime extension of a session is calculated as the state for the given session ID is extended by the NATFW NSLP
current local time plus proposed lifetime value (session refresh signaling session refresh period, a period of time calculated based
on a proposed refresh message period. The lifetime extension of a
NATFW NSLP signaling session is calculated as current local time plus
proposed lifetime value (NATFW NSLP signaling session refresh
period). Section 3.4 defines the process of calculating lifetimes in period). Section 3.4 defines the process of calculating lifetimes in
detail. detail.
NI Public Internet NAT Private address NR NI Public Internet NAT Private address NR
| | space | | | space |
| CREATE[lifetime > 0] | | | CREATE[lifetime > 0] | |
|----------------------------->| | |----------------------------->| |
| | | | | |
skipping to change at page 42, line 25 skipping to change at page 42, line 47
| |--------------------------->| | |--------------------------->|
| | | | | |
| | RESPONSE[Success/Error] | | | RESPONSE[Success/Error] |
| RESPONSE[Success/Error] |<---------------------------| | RESPONSE[Success/Error] |<---------------------------|
|<-----------------------------| | |<-----------------------------| |
| | | | | |
| | | | | |
Figure 16: Successful Refresh Message Flow, CREATE as example Figure 16: Successful Refresh Message Flow, CREATE as example
Processing of session refresh CREATE and EXT messages is different Processing of NATFW NSLP signaling session refresh CREATE and EXT
for every NSIS node type: messages is different for every NSIS node type:
o NSLP initiator: The NI/NI+ can generate session refresh CREATE/EXT o NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling
messages before the session times out. The rate at which the session refresh CREATE/EXT messages before the NATFW NSLP
refresh CREATE/EXT messages are sent and their relation to the signaling session times out. The rate at which the refresh
session state lifetime is discussed further in Section 3.4. CREATE/EXT messages are sent and their relation to the NATFW NSLP
signaling session state lifetime is discussed further in
Section 3.4.
o NSLP forwarder: Processing of this message is independent of the o NSLP forwarder: Processing of this message is independent of the
middlebox type and is as described in Section 3.4. middlebox type and is as described in Section 3.4.
o NSLP responder: NRs accepting a session refresh CREATE/EXT message o NSLP responder: NRs accepting a NATFW NSLP signaling session
generate a successful RESPONSE message, including the granted refresh CREATE/EXT message generate a successful RESPONSE message,
lifetime value of Section 3.4 in a NATFW_LT object. including the granted lifetime value of Section 3.4 in a NATFW_LT
object.
3.7.4. Deleting Sessions 3.7.4. Deleting Signaling Sessions
NATFW NSLP sessions can be deleted at any time. NSLP initiators can NATFW NSLP signaling sessions can be deleted at any time. NSLP
trigger this deletion by using a CREATE or EXT messages with a initiators can trigger this deletion by using a CREATE or EXT
lifetime value set to 0, as shown in Figure 17. Whether a CREATE or messages with a lifetime value set to 0, as shown in Figure 17.
EXT message type is used, depends on how the session was created. Whether a CREATE or EXT message type is used, depends on how the
NATFW NSLP signaling session was created.
NI Public Internet NAT Private address NR NI Public Internet NAT Private address NR
| | space | | | space |
| CREATE[lifetime=0] | | | CREATE[lifetime=0] | |
|----------------------------->| | |----------------------------->| |
| | | | | |
| | CREATE[lifetime=0] | | | CREATE[lifetime=0] |
| |--------------------------->| | |--------------------------->|
| | | | | |
Figure 17: Delete message flow, CREATE as example Figure 17: Delete message flow, CREATE as example
NSLP nodes receiving this message delete the session immediately. NSLP nodes receiving this message delete the NATFW NSLP signaling
Policy rules associated with this particular session MUST be also session immediately. Policy rules associated with this particular
deleted immediately. This message is forwarded until it reaches the NATFW NSLP signaling session MUST be also deleted immediately. This
final NR. The CREATE/EXT message with a lifetime value of 0, does message is forwarded until it reaches the final NR. The CREATE/EXT
not generate any response, neither positive nor negative, since there message with a lifetime value of 0, does not generate any response,
is no NSIS state left at the nodes along the path. neither positive nor negative, since there is no NSIS state left at
the nodes along the path.
NSIS initiators can use CREATE/EXT message with lifetime set to zero NSIS initiators can use CREATE/EXT message with lifetime set to zero
in an aggregated way, such that a single CREATE or EXT message is in an aggregated way, such that a single CREATE or EXT message is
terminating multiple signaling sessions. NIs can follow this terminating multiple NATFW NSLP signaling sessions. NIs can follow
procedure if the like to aggregate session deletion requests: The NI this procedure if the like to aggregate NATFW NSLP signaling session
uses the CREATE or EXT message with the session ID set to zero and deletion requests: The NI uses the CREATE or EXT message with the
the MRI's source-address set to its used IP address. All other session ID set to zero and the MRI's source-address set to its used
fields of the respective sessions to be terminated are set as well, IP address. All other fields of the respective NATFW NSLP signaling
otherwise these fields are completely wildcarded. The NSLP message sessions to be terminated are set as well, otherwise these fields are
is transferred to the NTLP requesting 'explicit routing' as described completely wildcarded. The NSLP message is transferred to the NTLP
in Sections 5.2.1 and 7.1.4. in [2]. requesting 'explicit routing' as described in Sections 5.2.1 and
7.1.4. in [2].
The downstream NF receiving such an aggregated CREATE or EXT message The outbound NF receiving such an aggregated CREATE or EXT message
MUST reject it with an error RESPONSE of class 'Permanent failure' MUST reject it with an error RESPONSE of class 'Permanent failure'
(0x5) with response code 'Authentication failed' (0x01) if the (0x5) with response code 'Authentication failed' (0x01) if the
authentication fails and with an error RESPONSE of class 'Permanent authentication fails and with an error RESPONSE of class 'Permanent
failure' (0x5) with response code 'Authorization failed' (0x02) if failure' (0x5) with response code 'Authorization failed' (0x02) if
the authorization fails. Per session proof of ownership, as it is the authorization fails. Per NATFW NSLP signaling session proof of
defined in this memo, is not possible anymore when using this ownership, as it is defined in this memo, is not possible anymore
aggregated mode. However, the downstream NF can use the relationship when using this aggregated way. However, the outbound NF can use the
between the information of the received CREATE or EXT message and the relationship between the information of the received CREATE or EXT
GIST messaging association where the request has been received. The message and the GIST messaging association where the request has been
downstream NF MUST only accept this aggregated CREATE or EXT message received. The outbound NF MUST only accept this aggregated CREATE or
through already established GIST messaging associations with the NI. EXT message through already established GIST messaging associations
The downstream NF MUST NOT propagate this aggregated CREATE or EXT with the NI. The outbound NF MUST NOT propagate this aggregated
message but it MAY generate and forward per session CREATE or EXT CREATE or EXT message but it MAY generate and forward per NATFW NSLP
messages. signaling session CREATE or EXT messages.
3.7.5. Reporting Asynchronous Events 3.7.5. Reporting Asynchronous Events
NATFW NSLP forwarders and NATFW NSLP responders must have the ability NATFW NSLP forwarders and NATFW NSLP responders must have the ability
to report asynchronous events to other NATFW NSLP nodes, especially to report asynchronous events to other NATFW NSLP nodes, especially
to allow reporting back to the NATFW NSLP initiator. Such to allow reporting back to the NATFW NSLP initiator. Such
asynchronous events may be premature session termination, changes in asynchronous events may be premature NATFW NSLP signaling session
local policies, route change or any other reason that indicates termination, changes in local policies, route change or any other
change of the NATFW NSLP session state. Currently, asynchronous reason that indicates change of the NATFW NSLP signaling session
session termination, re-authorization required and route change state.
detected (see Section 3.9) are the only events that are defined, but
other events may be defined in later revisions of this memo.
NFs and NRs may generate NOTIFY messages upon asynchronous events, NFs and NRs may generate NOTIFY messages upon asynchronous events,
with a NATFW_INFO object indicating the reason for event. These with a NATFW_INFO object indicating the reason for event. These
reasons can be carried in the NATFW_INFO object (class MUST be set to reasons can be carried in the NATFW_INFO object (class MUST be set to
'Informational' (0x1)) within the NOTIFY message. This list shows 'Informational' (0x1)) within the NOTIFY message. This list shows
the response codes and the associated actions to take at NFs and the the response codes and the associated actions to take at NFs and the
NI: NI:
o 'Route change: possible route change on the downstream path' o 'Route change: possible route change on the outbound path' (0x01):
(0x01): Follow instructions in Section 3.9. Follow instructions in Section 3.9. This MUST be sent inbound.
o 'Re-authentication required' (0x02): The NI should re-send the o 'Re-authentication required' (0x02): The NI should re-send the
authentication. authentication. This MUST be sent inbound.
o 'NATFW node is going down soon' (0x03): The NI and other NFs o 'NATFW node is going down soon' (0x03): The NI and other NFs
should be prepared for a service interruption at any time. should be prepared for a service interruption at any time. This
message MAY be sent inbound and outbound.
NOTIFY messages are sent hop-by-hop upstream towards NI until they o 'NATFW signaling session lifetime expired' (0x04): The NATFW
reach NI. signaling session has been expired and the signaling session is
invalid now. NFs MUST mark the signaling session as 'Dead'. This
message MAY be sent inbound and outbound.
NOTIFY messages are always sent hop-by-hop inbound towards NI until
they reach NI or outbound towards the NR as indicated in the list
above.
The initial processing when receiving a NOTIFY message is the same The initial processing when receiving a NOTIFY message is the same
for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages
through already established NTLP messaging associations. The further through already established NTLP messaging associations. The further
processing is different for each NATFW NSLP node type and depends on processing is different for each NATFW NSLP node type and depends on
the events notified: the events notified:
o NSLP initiator: NIs analyze the notified event and behave o NSLP initiator: NIs analyze the notified event and behave
appropriately based on the event type. NIs MUST NOT generate appropriately based on the event type. NIs MUST NOT generate
NOTIFY messages. NOTIFY messages.
o NSLP forwarder: NFs analyze the notified event and behave based on o NSLP forwarder: NFs analyze the notified event and behave based on
the above description per response code. NFs SHOULD generate the above description per response code. NFs SHOULD generate
NOTIFY messages upon asynchronous events and forward them upstream NOTIFY messages upon asynchronous events and forward them inbound
towards the NI. towards the NI or outbound towards the NR, depending on the
received direction, i.e., inbound messages MUST be forwarded
further inbound and outbound messages MUST be forwarded further
inbound. NFs MUST silently discard NOTIFY messages that have been
received outbound but are only allowed to be sent inbound, e.g.
'Re-authentication required' (0x02).
o NSLP responder: NRs SHOULD generate NOTIFY messages upon o NSLP responder: NRs SHOULD generate NOTIFY messages upon
asynchronous events including a response code based on the asynchronous events including a response code based on the
reported event. The NR should never receive NOTIFY messages and reported event. The NR MUST silently discard NOTIFY messages that
MUST silently discard it. have been received outbound but are only allowed to be sent
inbound, e.g. 'Re-authentication required' (0x02),
NATFW NSLP forwarders, keeping multiple signaling sessions at the NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions
same time, can experience problems when shutting down service at the same time, can experience problems when shutting down service
suddenly. This sudden shutdown can be result of node local failure, suddenly. This sudden shutdown can be result of node local failure,
for instance, due to a hardware failure. This NF generates NOTIFY for instance, due to a hardware failure. This NF generates NOTIFY
messages for each of the signaling sessions and tries to send them messages for each of the NATFW NSLP signaling sessions and tries to
upstream. Due to the number of NOTIFY messages to be sent, the send them inbound. Due to the number of NOTIFY messages to be sent,
shutdown of the node may be unnecessarily prolonged, since not all the shutdown of the node may be unnecessarily prolonged, since not
messages can be sent at the same time. This case can be described as all messages can be sent at the same time. This case can be
a NOTIFY storm, if a multitude of signaling sessions is involved. described as a NOTIFY storm, if a multitude of NATFW NSLP signaling
sessions is involved.
To avoid the need of generating per signaling session NOTIFY messages To avoid the need of generating per NATFW NSLP signaling session
in such a scenario described or similar cases, NFs SHOULD follow this NOTIFY messages in such a scenario described or similar cases, NFs
procedure: The NF uses the NOTIFY message with the session ID in the SHOULD follow this procedure: The NF uses the NOTIFY message with the
NTLP set to zero, with the MRI completely wildcarded, using the session ID in the NTLP set to zero, with the MRI completely
'explicit routing' as described in Sections 5.2.1 and 7.1.4. in [2]. wildcarded, using the 'explicit routing' as described in Sections
The upstream NF receiving this type of NOTIFY immediately regards all 5.2.1 and 7.1.4. in [2]. The inbound NF receiving this type of
signaling sessions from that peer matching the MRI as void. This NOTIFY immediately regards all NATFW NSLP signaling sessions from
message will typically result in multiple NOTIFY messages at the that peer matching the MRI as void. This message will typically
upstream NF, i.e., the NF can generate per terminated session a result in multiple NOTIFY messages at the inbound NF, i.e., the NF
NOTIFY message. However, a NF MAY aggregate again the NOTIFY can generate per terminated NATFW NSLP signaling session a NOTIFY
messages as described here. message. However, a NF MAY aggregate again the NOTIFY messages as
described here.
3.7.6. Proxy Mode of Operation 3.7.6. Proxy Mode of Operation
Some migration scenarios need specialized support to cope with cases Some migration scenarios need specialized support to cope with cases
where NSIS is only deployed in same areas of the Internet. End-to- where NSIS is only deployed in same areas of the Internet. End-to-
end signaling is going to fail without NSIS support at or near both end signaling is going to fail without NSIS support at or near both
data sender and data receiver terminals. A proxy mode of operation data sender and data receiver terminals. A proxy mode of operation
is needed. This proxy mode of operation must terminate the NATFW is needed. This proxy mode of operation must terminate the NATFW
NSLP signaling as topologically close to the terminal for which it is NSLP signaling as topologically close to the terminal for which it is
proxying and proxy all messages. This NATFW NSLP node doing the proxying and proxy all messages. This NATFW NSLP node doing the
proxying of the signaling messages becomes either the NI or the NR proxying of the signaling messages becomes either the NI or the NR
for the particular signaling session, depending on whether it is the for the particular NATFW NSLP signaling session, depending on whether
DS or DR that does not support NSIS. Typically, the edge-NAT or the it is the DS or DR that does not support NSIS. Typically, the edge-
edge-firewall would be used to proxy NATFW NSLP messages. NAT or the edge-firewall would be used to proxy NATFW NSLP messages.
This proxy mode operation does not require any new CREATE or EXT This proxy mode operation does not require any new CREATE or EXT
message type, but relies on extended CREATE and EXT message types. message type, but relies on extended CREATE and EXT message types.
They are called respectively CREATE-PROXY and EXT-PROXY and are They are called respectively CREATE-PROXY and EXT-PROXY and are
distinguished by setting the P flag in the NSLP header to P=1. This distinguished by setting the P flag in the NSLP header to P=1. This
flag instructs edge-NATs and edge-firewalls receiving them to operate flag instructs edge-NATs and edge-firewalls receiving them to operate
in proxy mode for the session in question. The semantics of the in proxy mode for the NATFW NSLP signaling session in question. The
CREATE and EXT message types are not changed and the behavior of the semantics of the CREATE and EXT message types are not changed and the
various node types is as defined in Section 3.7.1 and Section 3.7.2, behavior of the various node types is as defined in Section 3.7.1 and
except for the proxying node. The following paragraphs describe the Section 3.7.2, except for the proxying node. The following
proxy mode operation for data receivers behind middleboxes and data paragraphs describe the proxy mode operation for data receivers
senders behind middleboxes. behind middleboxes and data senders behind middleboxes.
3.7.6.1. Proxying for a Data Sender 3.7.6.1. Proxying for a Data Sender
The NATFW NSLP gives the NR the ability to install state on the The NATFW NSLP gives the NR the ability to install state on the
upstream path towards the data sender for downstream data packets, inbound path towards the data sender for outbound data packets, even
even when only the receiving side is running NSIS (as shown in when only the receiving side is running NSIS (as shown in Figure 18).
Figure 18). The goal of the method described is to trigger the edge- The goal of the method described is to trigger the edge-NAT/
NAT/edge-firewall to generate a CREATE message on behalf of the data edge-firewall to generate a CREATE message on behalf of the data
receiver. In this case, an NR can signal towards the network border receiver. In this case, an NR can signal towards the network border
as it is performed in the standard EXT message handling scenario as as it is performed in the standard EXT message handling scenario as
in Section 3.7.2. The message is forwarded until the edge-NAT/ in Section 3.7.2. The message is forwarded until the edge-NAT/
edge-firewall is reached. A public IP address and port number is edge-firewall is reached. A public IP address and port number is
reserved at an edge-NAT/edge-firewall. As shown in Figure 18, unlike reserved at an edge-NAT/edge-firewall. As shown in Figure 18, unlike
the standard EXT message handling case, the edge-NAT/edge-firewall is the standard EXT message handling case, the edge-NAT/edge-firewall is
triggered to send a CREATE message on a new reverse path which triggered to send a CREATE message on a new reverse path which
traverse several firewalls or NATs. The new reverse path for CREATE traverse several firewalls or NATs. The new reverse path for CREATE
is necessary to handle routing asymmetries between the edge-NAT/ is necessary to handle routing asymmetries between the edge-NAT/
edge-firewall and DR. It must be stressed that the semantics of the edge-firewall and DR. It must be stressed that the semantics of the
skipping to change at page 47, line 14 skipping to change at page 47, line 46
o NSLP initiator (NI+): The NI+ MUST choose a random value and place o NSLP initiator (NI+): The NI+ MUST choose a random value and place
it in the NATFW_NONCE object. it in the NATFW_NONCE object.
o NSLP forwarder being either edge-NAT or edge-firewall: When the NF o NSLP forwarder being either edge-NAT or edge-firewall: When the NF
accepts a EXT_PROXY message, it generates a successful RESPONSE accepts a EXT_PROXY message, it generates a successful RESPONSE
message as if it were the NR and additionally, it generates a message as if it were the NR and additionally, it generates a
CREATE message as defined in Section 3.7.1 and includes a CREATE message as defined in Section 3.7.1 and includes a
NATFW_NONCE object having the same value as of the received NATFW_NONCE object having the same value as of the received
NATFW_NONCE object. The NF MUST not generate a CREATE-PROXY NATFW_NONCE object. The NF MUST not generate a CREATE-PROXY
message. The NF MUST refresh the CREATE message session only if a message. The NF MUST refresh the CREATE message signaling session
EXT-PROXY refresh message has been received first. only if a EXT-PROXY refresh message has been received first. This
also includes tearing down signaling sessions, i.e., the NF must
teardown the CREATE signaling session only if a EXT-PROXY message
with lifetime set to 0 has been received first.
The scenario described in this section challenges the data receiver The scenario described in this section challenges the data receiver
because it must make a correct assumption about the data sender's because it must make a correct assumption about the data sender's
ability to use NSIS NATFW NSLP signaling. It is possible for the DR ability to use NSIS NATFW NSLP signaling. It is possible for the DR
to make the wrong assumption in two different ways: to make the wrong assumption in two different ways:
a) the DS is NSIS unaware but the DR assumes the DS to be NSIS a) the DS is NSIS unaware but the DR assumes the DS to be NSIS
aware and aware and
b) the DS is NSIS aware but the DR assumes the DS to be NSIS b) the DS is NSIS aware but the DR assumes the DS to be NSIS
unaware. unaware.
Case a) will result in middleboxes blocking the data traffic, since Case a) will result in middleboxes blocking the data traffic, since
DS will never send the expected CREATE message. Case b) will result DS will never send the expected CREATE message. Case b) will result
in the DR successfully requesting proxy mode support by the edge-NAT in the DR successfully requesting proxy mode support by the edge-NAT
or edge-firewall. The edge-NAT/edge-firewall will send CREATE or edge-firewall. The edge-NAT/edge-firewall will send CREATE
messages and DS will send CREATE messages as well. Both CREATE messages and DS will send CREATE messages as well. Both CREATE
messages are handled as separated sessions and therefore the common messages are handled as separated NATFW NSLP signaling sessions and
rules per session apply; the NATFW_NONCE object is used to therefore the common rules per NATFW NSLP signaling session apply;
differentiate CREATE messages generated by the edge-NAT/edge-firewall the NATFW_NONCE object is used to differentiate CREATE messages
from NI initiated CREATE messages. It is the NR's responsibility to generated by the edge-NAT/edge-firewall from NI initiated CREATE
decide whether to teardown the EXT-PROXY sessions in the case where messages. It is the NR's responsibility to decide whether to
the data sender's side is NSIS aware, but was incorrectly assumed not teardown the EXT-PROXY signaling sessions in the case where the data
to be so by the DR. It is RECOMMENDED that a DR behind NATs uses the sender's side is NSIS aware, but was incorrectly assumed not to be so
proxy mode of operation by default, unless the DR knows that the DS by the DR. It is RECOMMENDED that a DR behind NATs uses the proxy
is NSIS aware. The DR MAY cache information about data senders which mode of operation by default, unless the DR knows that the DS is NSIS
it has found to be NSIS aware in past sessions. aware. The DR MAY cache information about data senders which it has
found to be NSIS aware in past NATFW NSLP signaling sessions.
There is a possible race condition between the RESPONSE message to There is a possible race condition between the RESPONSE message to
the EXT-PROXY and the CREATE message generated by the edge-NAT. The the EXT-PROXY and the CREATE message generated by the edge-NAT. The
CREATE message can arrive earlier than the RESPONSE message. An NI+ CREATE message can arrive earlier than the RESPONSE message. An NI+
MUST accept CREATE messages generated by the edge-NAT even if the MUST accept CREATE messages generated by the edge-NAT even if the
RESPONSE message to the EXT-PROXY was not received. RESPONSE message to the EXT-PROXY was not received.
3.7.6.2. Proxying for a Data Receiver 3.7.6.2. Proxying for a Data Receiver
As with data receivers behind middleboxes, data senders behind As with data receivers behind middleboxes, data senders behind
skipping to change at page 50, line 37 skipping to change at page 51, line 10
Table entries marked with (w) can be wildcarded and entries marked Table entries marked with (w) can be wildcarded and entries marked
with (n/u) are not used for the matching. with (n/u) are not used for the matching.
Table 1 Table 1
3.9. Reacting to Route Changes 3.9. Reacting to Route Changes
The NATFW NSLP needs to react to route changes in the data path. The NATFW NSLP needs to react to route changes in the data path.
This assumes the capability to detect route changes, to perform NAT This assumes the capability to detect route changes, to perform NAT
and firewall configuration on the new path and possibly to tear down and firewall configuration on the new path and possibly to tear down
session state on the old path. The detection of route changes is NATFW NSLP signaling session state on the old path. The detection of
described in Section 7 of [2] and the NATFW NSLP relies on route changes is described in Section 7 of [2] and the NATFW NSLP
notifications about route changes by the NTLP. This notification relies on notifications about route changes by the NTLP. This
will be conveyed by the API between NTLP and NSLP, which is out of notification will be conveyed by the API between NTLP and NSLP, which
scope of this memo. is out of scope of this memo.
A NATFW NSLP node other than the NI or NI+ detecting a route change, A NATFW NSLP node other than the NI or NI+ detecting a route change,
by means described in the NTLP specification or others, generates a by means described in the NTLP specification or others, generates a
NOTIFY message indicating this change and sends this upstream towards NOTIFY message indicating this change and sends this inbound towards
NI. Intermediate NFs on the way to the NI can use this information NI. Intermediate NFs on the way to the NI can use this information
to decide later if their session can be deleted locally, if they do to decide later if their NATFW NSLP signaling session can be deleted
not receive an update within a certain time period, as described in locally, if they do not receive an update within a certain time
Section 3.2.3. It is important to consider the transport limitations period, as described in Section 3.2.3. It is important to consider
of NOTIFY messages as mandated in Section 3.7.5. the transport limitations of NOTIFY messages as mandated in
Section 3.7.5.
The NI receiving this NOTIFY message MAY generate a new CREATE or EXT The NI receiving this NOTIFY message MAY generate a new CREATE or EXT
message and sends it towards the session's NI as for the initial message and sends it towards the NATFW NSLP signaling session's NI as
message using the same session ID. All the remaining processing and for the initial message using the same session ID. All the remaining
message forwarding, such as NSLP next hop discovery, is subject to processing and message forwarding, such as NSLP next hop discovery,
regular NSLP processing as described in the particular sections. is subject to regular NSLP processing as described in the particular
Normal routing will guide the new CREATE or EXT message to the sections. Normal routing will guide the new CREATE or EXT message to
correct NFs along the changed route. NFs that were on the original the correct NFs along the changed route. NFs that were on the
path receiving these new CREATE or EXT messages (see also original path receiving these new CREATE or EXT messages (see also
Section 3.10), can use the session ID to update the existing session, Section 3.10), can use the session ID to update the existing NATFW
whereas NFs that were not on the original path will create new state NSLP signaling session, whereas NFs that were not on the original
for this session. The next section describes how policy rules are path will create new state for this NATFW NSLP signaling session.
updated. The next section describes how policy rules are updated.
3.10. Updating Policy Rules 3.10. Updating Policy Rules
NSIS initiators can request an update of the installed/reserved NSIS initiators can request an update of the installed/reserved
policy rules at any time within a signaling session. Updates to policy rules at any time within a NATFW NSLP signaling session.
policy rules can be required due to node mobility (NI is moving from Updates to policy rules can be required due to node mobility (NI is
one IP address to another), route changes (this can result in a moving from one IP address to another), route changes (this can
different NAT mapping at a different NAT device), or the wish of the result in a different NAT mapping at a different NAT device), or the
NI to simply change the rule. NIs can update policy rules in wish of the NI to simply change the rule. NIs can update policy
existing signaling sessions by sending an appropriate CREATE or EXT rules in existing NATFW NSLP signaling sessions by sending an
message (similar to Section 3.4) with modified message routing appropriate CREATE or EXT message (similar to Section 3.4) with
information (MRI) as compared with that installed previously, but modified message routing information (MRI) as compared with that
using the existing session ID to identify the intended target of the installed previously, but using the existing session ID to identify
update. With respect to authorization and authentication, this the intended target of the update. With respect to authorization and
update CREATE or EXT message is treated in exactly the same way as authentication, this update CREATE or EXT message is treated in
any initial message. Therefore, any node along in the signaling exactly the same way as any initial message. Therefore, any node
session can reject the update with an error RESPONSE message, as along in the NATFW NSLP signaling session can reject the update with
defined in the previous sections. an error RESPONSE message, as defined in the previous sections.
The message processing and forwarding is executed as defined in the The message processing and forwarding is executed as defined in the
particular sections. A NF or the NR receiving an update, simply particular sections. A NF or the NR receiving an update, simply
replaces the installed policy rules installed in the firewall/NAT. replaces the installed policy rules installed in the firewall/NAT.
The local procedures on how to update the MRI in the firewall/NAT is The local procedures on how to update the MRI in the firewall/NAT is
out of scope of this memo out of scope of this memo
4. NATFW NSLP Message Components 4. NATFW NSLP Message Components
A NATFW NSLP message consists of a NSLP header and one or more A NATFW NSLP message consists of a NSLP header and one or more
skipping to change at page 55, line 44 skipping to change at page 56, line 44
o 0x0002: Deny: A policy rule with this action blocks data traffic o 0x0002: Deny: A policy rule with this action blocks data traffic
from traversing the middlebox and the NATFW NSLP MUST NOT allow from traversing the middlebox and the NATFW NSLP MUST NOT allow
NSLP signaling to be forwarded. NSLP signaling to be forwarded.
If the 'rule action' field contains neither 0x0001 nor 0x0002, an If the 'rule action' field contains neither 0x0001 nor 0x0002, an
error RESPONSE of class 'Signaling session error' (0x6) with response error RESPONSE of class 'Signaling session error' (0x6) with response
code 'Unknown policy rule action' (0x05) MUST be generated. code 'Unknown policy rule action' (0x05) MUST be generated.
The 'sub_ports' field contains the number of contiguous transport The 'sub_ports' field contains the number of contiguous transport
layer ports to which this rule applies. The default value of this layer ports to which this rule applies. The default value of this
field is 0, i.e., only the port specified in the NTLP's MRM is used field is 0, i.e., only the port specified in the NTLP's MRM or
for the policy rule. A value of 1 indicates that additionally to the NATFW_DTINFO object is used for the policy rule. A value of 1
port specified in the NTLP's MRM (port1), a second port (port2) is indicates that additionally to the port specified in the NTLP's MRM
used. This value of port 2 is calculated as: port2 = port1 + 1. (port1), a second port (port2) is used. This value of port 2 is
Other values than 0 or 1 MUST NOT be used in this field and an error calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT
RESPONSE of class 'Signaling session error' (0x6) with response code be used in this field and an error RESPONSE of class 'Signaling
'Requested value in sub_ports field in NATFW_EFI not permitted' session error' (0x6) with response code 'Requested value in sub_ports
(0x08) MUST be generated. Further version of this memo may allow field in NATFW_EFI not permitted' (0x08) MUST be generated. Further
other values for the 'sub_ports' field. This two contiguous port version of this memo may allow other values for the 'sub_ports'
numbered ports, can be used by legacy voice over IP equipment. This field. This two contiguous port numbered ports, can be used by
legacy equipment assumes that two adjacent port numbers for its RTP/ legacy voice over IP equipment. This legacy equipment assumes that
RTCP flows respectively. two adjacent port numbers for its RTP/RTCP flows respectively.
4.2.4. Information Code Object 4.2.4. Information Code Object
This object carries the response code, which may be indications for This object carries the response code, which may be indications for
either a successful or failed CREATE or EXT message depending on the either a successful or failed CREATE or EXT message depending on the
value of the 'response code' field. value of the 'response code' field.
Type: NATFW_INFO (IANA-TBD) Type: NATFW_INFO (IANA-TBD)
Length: 1 Length: 1
skipping to change at page 57, line 6 skipping to change at page 58, line 6
o 0x4: Transient failure o 0x4: Transient failure
o 0x5: Permanent failure o 0x5: Permanent failure
o 0x6: Signaling session failures o 0x6: Signaling session failures
Within each severity class a number of responses values are defined Within each severity class a number of responses values are defined
o Informational: o Informational:
* 0x01: Route change: possible route change on the downstream * 0x01: Route change: possible route change on the outbound path.
path.
* 0x02: Re-authentication required. * 0x02: Re-authentication required.
* 0x03: NATFW node is going down soon. * 0x03: NATFW node is going down soon.
o Success: o Success:
* 0x01: All successfully processed. * 0x01: All successfully processed.
o Protocol error: o Protocol error:
skipping to change at page 58, line 40 skipping to change at page 59, line 40
* 0x03: No reservation found matching the MRI of the CREATE * 0x03: No reservation found matching the MRI of the CREATE
request. request.
* 0x04: Requested policy rule denied due to policy conflict. * 0x04: Requested policy rule denied due to policy conflict.
* 0x05: Unknown policy rule action. * 0x05: Unknown policy rule action.
* 0x06: Requested rule action not applicable. * 0x06: Requested rule action not applicable.
* 0x07: DTINFO object is required. * 0x07: NATFW_DTINFO object is required.
* 0x08: Requested value in sub_ports field in NATFW_EFI not * 0x08: Requested value in sub_ports field in NATFW_EFI not
permitted. permitted.
* 0x09: Requested IP protocol not supported. * 0x09: Requested IP protocol not supported.
* 0x0A: Plain IP policy rules not permitted -- need transport * 0x0A: Plain IP policy rules not permitted -- need transport
layer information. layer information.
* 0x0B: ICMP type value not permitted. * 0x0B: ICMP type value not permitted.
skipping to change at page 62, line 37 skipping to change at page 63, line 37
reception. reception.
4.3. Message Formats 4.3. Message Formats
This section defines the content of each NATFW NSLP message type. This section defines the content of each NATFW NSLP message type.
The message types are defined in Section 4.1. The message types are defined in Section 4.1.
Basically, each message is constructed of NSLP header and one or more Basically, each message is constructed of NSLP header and one or more
NSLP objects. The order of objects is not defined, meaning that NSLP objects. The order of objects is not defined, meaning that
objects may occur in any sequence. Objects are marked either with objects may occur in any sequence. Objects are marked either with
mandatory [M] or optional [O]. Where [M] implies that this mandatory (M) or optional (O). Where (M) implies that this
particular object MUST be included within the message and where [O] particular object MUST be included within the message and where (O)
implies that this particular object is OPTIONAL within the message. implies that this particular object is OPTIONAL within the message.
Objects defined in this memo carry always the flag combination AB=00 Objects defined in this memo carry always the flag combination AB=00
in the NSLP object header. An error RESPONSE message of class in the NSLP object header. An error RESPONSE message of class
'Protocol error' (0x3) with response code 'Mandatory object missing' 'Protocol error' (0x3) with response code 'Mandatory object missing'
(0x02) MUST be generated if a mandatory declared object is missing. (0x02) MUST be generated if a mandatory declared object is missing.
An error RESPONSE message of class 'Protocol error' (0x3) with An error RESPONSE message of class 'Protocol error' (0x3) with
response code 'Illegal object present' (0x05) MUST be generated if an response code 'Illegal object present' (0x05) MUST be generated if an
object was present which must not be used in a message of this type. object was present which must not be used in a message of this type.
An error RESPONSE message of class 'Protocol error' (0x3) with An error RESPONSE message of class 'Protocol error' (0x3) with
response code 'Duplicate object present' (0x0A) MUST be generated if response code 'Duplicate object present' (0x0A) MUST be generated if
an object appears more than once in a message. an object appears more than once in a message.
Each section elaborates the required settings and parameters to be Each section elaborates the required settings and parameters to be
set by the NSLP for the NTLP, for instance, how the message routing set by the NSLP for the NTLP, for instance, how the message routing
information is set. information is set.
4.3.1. CREATE 4.3.1. CREATE
The CREATE message is used to create NSLP sessions and to create The CREATE message is used to create NATFW NSLP signaling sessions
policy rules. Furthermore, CREATE messages are used to refresh and to create policy rules. Furthermore, CREATE messages are used to
sessions and to delete them. refresh NATFW NSLP signaling sessions and to delete them.
The CREATE message carries these objects: The CREATE message carries these objects:
o Signaling Session Lifetime object [M] o Signaling Session Lifetime object (M)
o Extended flow information object [M] o Extended flow information object (M)
o Message sequence number object [M] o Message sequence number object (M)
o Nonce object [M] if P flag set to 1 in the NSLP header, otherwise o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise
[O] (O)
o ICMP Types Object [O] o ICMP Types Object (O)
The message routing information in the NTLP MUST be set to DS as The message routing information in the NTLP MUST be set to DS as
source address and DR as destination address. All other parameters source address and DR as destination address. All other parameters
MUST be set according the required policy rule. CREATE messages MUST MUST be set according the required policy rule. CREATE messages MUST
be transported by using the path-coupled MRM with direction set to be transported by using the path-coupled MRM with direction set to
downstream. 'downstream' (outbound).
4.3.2. EXTERNAL (EXT) 4.3.2. EXTERNAL (EXT)
The EXTERNAL (EXT) message is used to a) reserve an external IP The EXTERNAL (EXT) message is used to a) reserve an external IP
address/port at NATs, b) to notify firewalls about NSIS capable DRs, address/port at NATs, b) to notify firewalls about NSIS capable DRs,
or c) to block incoming data traffic at upstream firewalls. or c) to block incoming data traffic at inbound firewalls.
The EXT message carries these objects: The EXT message carries these objects:
o Signaling Session Lifetime object [M] o Signaling Session Lifetime object (M)
o Message sequence number object [M] o Message sequence number object (M)
o Extended flow information object [M] o Extended flow information object (M)
o Data terminal information object [M] o Data terminal information object (M)
o Nonce object [M if P flag set to 1 in the NSLP header, otherwise o Nonce object [M if P flag set to 1 in the NSLP header, otherwise
[O] (O)
o ICMP Types Object [O] o ICMP Types Object (O)
The selected message routing method of the EXT message depends on a The selected message routing method of the EXT message depends on a
number of considerations. Section 3.7.2 describes it exhaustively number of considerations. Section 3.7.2 describes it exhaustively
how to select the correct method. EXT messages can be transported how to select the correct method. EXT messages can be transported
via the path-coupled message routing method (PC-MRM) or via the via the path-coupled message routing method (PC-MRM) or via the
loose-end message routing method (LE-MRM). In the case of PC-MRM, loose-end message routing method (LE-MRM). In the case of PC-MRM,
the source-address is set to DS' address and the destination address the source-address is set to DS' address and the destination address
is set to DR's address, the direction is set to upstream. In the is set to DR's address, the direction is set to inbound. In the case
case of LE-MRM, the destination-address is set to DR's address or to of LE-MRM, the destination-address is set to DR's address or to the
the signaling destination address. The source-address is set to DS's signaling destination address. The source-address is set to DS's
address. address.
4.3.3. RESPONSE 4.3.3. RESPONSE
RESPONSE messages are responses to CREATE and EXT messages. RESPONSE RESPONSE messages are responses to CREATE and EXT messages. RESPONSE
messages MUST NOT be generated for any other message, such as NOTIFY messages MUST NOT be generated for any other message, such as NOTIFY
and RESPONSE. and RESPONSE.
The RESPONSE message for the class 'Success' (0x2) carries these The RESPONSE message for the class 'Success' (0x2) carries these
objects: objects:
o Signaling Session Lifetime object [M] o Signaling Session Lifetime object (M)
o Message sequence number object [M] o Message sequence number object (M)
o Information code object [M] o Information code object (M)
o External address object [O] o External 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)
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 EXT message. same as MRM used by the corresponding CREATE or EXT 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:
o Information code object [M]. o Information code object (M).
The NOTIFY message is routed towards the NI hop-by-hop using the The NOTIFY message is routed towards the NI hop-by-hop using the
existing upstream node messaging association entry within the node's existing inbound node messaging association entry within the node's
Message Routing State table. The MRM used for this message MUST be Message Routing State table. The MRM used for this message MUST be
the same as MRM used by the corresponding CREATE or EXT message. the same as MRM used by the corresponding CREATE or EXT message.
5. Security Considerations 5. Security Considerations
Security is of major concern particularly in case of firewall Security is of major concern particularly in case of firewall
traversal. This section provides security considerations for the traversal. This section provides security considerations for the
NAT/firewall traversal and is organized as follows. NAT/firewall traversal and is organized as follows.
In Section 5.1 we describe the participating entities relate to each In Section 5.1 we describe the participating entities relate to each
skipping to change at page 66, line 36 skipping to change at page 67, line 36
5.1. Authorization Framework 5.1. Authorization Framework
The NATFW NSLP is a protocol which may involve a number of NSIS nodes The NATFW NSLP is a protocol which may involve a number of NSIS nodes
and is, as such, not a two-party protocol. Figure 1 and Figure 2 of and is, as such, not a two-party protocol. Figure 1 and Figure 2 of
[8] already depict the possible set of communication patterns. In [8] already depict the possible set of communication patterns. In
this section we will re-evaluate these communication patters with this section we will re-evaluate these communication patters with
respect to the NATFW NSLP protocol interaction. respect to the NATFW NSLP protocol interaction.
The security solutions for providing authorization have a direct The security solutions for providing authorization have a direct
impact on the treatment of different NSLPs. As it can be seen from impact on the treatment of different NSLPs. As it can be seen from
the QoS NSLP [6] and the corresponding Diameter QoS work [24] the QoS NSLP [6] and the corresponding Diameter QoS work [20]
accounting and charging seems to play an important role for QoS accounting and charging seems to play an important role for QoS
reservations, whereas monetary aspects might only indirectly effect reservations, whereas monetary aspects might only indirectly effect
authorization decisions for NAT and firewall signaling. Hence, there authorization decisions for NAT and firewall signaling. Hence, there
are differences in the semantic of authorization handling between QoS are differences in the semantic of authorization handling between QoS
and NATFW signaling. A NATFW aware node will most likely want to and NATFW signaling. A NATFW aware node will most likely want to
authorize the entity (e.g., user or machine) requesting the authorize the entity (e.g., user or machine) requesting the
establishment of pinholes or NAT bindings. The outcome of the establishment of pinholes or NAT bindings. The outcome of the
authorization decision is either allowed or disallowed whereas a QoS authorization decision is either allowed or disallowed whereas a QoS
authorization decision might indicate that a different set of QoS authorization decision might indicate that a different set of QoS
parameters is authorization (see [24] as an example). parameters is authorization (see [20] as an example).
5.1.1. Peer-to-Peer Relationship 5.1.1. Peer-to-Peer Relationship
Starting with the simplest scenario, it is assumed that neighboring Starting with the simplest scenario, it is assumed that neighboring
nodes are able to authenticate each other and to establish keying nodes are able to authenticate each other and to establish keying
material to protect the signaling message communication. The nodes material to protect the signaling message communication. The nodes
will have to authorize each other, additionally to the will have to authorize each other, additionally to the
authentication. We use the term 'Security Context' as a placeholder authentication. We use the term 'Security Context' as a placeholder
for referring to the entire security procedure, the necessary for referring to the entire security procedure, the necessary
infrastructure that needs to be in place in order for this to work infrastructure that needs to be in place in order for this to work
skipping to change at page 73, line 35 skipping to change at page 74, line 35
sender is allowed to traverse the NAT in order to be forwarded to sender is allowed to traverse the NAT in order to be forwarded to
DR's address. DR's address.
5.2.5. NSLP Message Injection 5.2.5. NSLP Message Injection
Malicious hosts, located either off-path or on-path, could inject Malicious hosts, located either off-path or on-path, could inject
arbitrary NATFW NSLP messages into the signaling path. These arbitrary NATFW NSLP messages into the signaling path. These
problems apply when no proper authorization and authentication scheme problems apply when no proper authorization and authentication scheme
is available. is available.
By injecting a bogus CREATE message with signaling session lifetime By injecting a bogus CREATE message with NATFW NSLP signaling session
set to zero, a malicious host could try to teardown NATFW NSLP lifetime set to zero, a malicious host could try to teardown NATFW
session state partially or completely on a data path, causing a NSLP signaling session state partially or completely on a data path,
service interruption. causing a service interruption.
By injecting a bogus responses or NOTIFY message, for instance, By injecting a bogus responses or NOTIFY message, for instance, NATFW
session timeout, a malicious host could try to teardown NATFW NSLP NSLP signaling session timeout, a malicious host could try to
session state as well. This could affect the data path partially or teardown NATFW NSLP signaling session state as well. This could
totally, causing a service interruption. affect the data path partially or totally, causing a service
interruption.
SECURITY REQUIREMENT: Messages, such as NOTIFY, can be misused by SECURITY REQUIREMENT: Messages, such as NOTIFY, can be misused by
malicious hosts, and therefore MUST be authorized by the malicious hosts, and therefore MUST be authorized by the
respective NATFW NLSP entities. respective NATFW NLSP entities.
5.3. Denial-of-Service Attacks 5.3. Denial-of-Service Attacks
In this section we describe several ways how an adversary could In this section we describe several ways how an adversary could
launch a Denial of service (DoS) attack on networks running NSIS for launch a Denial of service (DoS) attack on networks running NSIS for
middlebox configuration to exhaust their resources. middlebox configuration to exhaust their resources.
skipping to change at page 74, line 21 skipping to change at page 75, line 21
5.3.1. Flooding with CREATE messages from outside 5.3.1. Flooding with CREATE messages from outside
5.3.1.1. Attacks due to NSLP state 5.3.1.1. Attacks due to NSLP state
A CREATE message requests the NSLP to store state information such as A CREATE message requests the NSLP to store state information such as
a NAT binding or a policy rule. a NAT binding or a policy rule.
The policy rules requested in the CREATE message will be installed at The policy rules requested in the CREATE message will be installed at
the arrival of a confirmation from the Data Receiver with a success the arrival of a confirmation from the Data Receiver with a success
RESPONSE message. A successful RESPONSE message includes the session RESPONSE message. A successful RESPONSE message includes the session
ID. So the NSLP looks up the NSIS session and installs the requested ID. So the NSLP looks up the NATFW NSLP signaling session and
policy rules. installs the requested policy rules.
An adversary could launch a DoS attack with an arbitrary number of An adversary could launch a DoS attack with an arbitrary number of
CREATE messages. For each of these messages the middlebox needs to CREATE messages. For each of these messages the middlebox needs to
store state information such as the policy rules to be loaded, i.e., store state information such as the policy rules to be loaded, i.e.,
the middlebox could run out of memory. This kind of attack is also the middlebox could run out of memory. This kind of attack is also
mentioned in [8] Section 4.8. mentioned in [8] Section 4.8.
SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the
establishment of state information. establishment of state information.
skipping to change at page 77, line 8 skipping to change at page 78, line 8
o NATs need to modify the source/destination of the data flow in the o NATs need to modify the source/destination of the data flow in the
'create session' message. 'create session' message.
o Each middlebox along the path may change the requested lifetime in o Each middlebox along the path may change the requested lifetime in
the CREATE message to fit their needs and/or local policy. the CREATE message to fit their needs and/or local policy.
SECURITY REQUIREMENT: Malicious NSIS NATs and firewalls will not be SECURITY REQUIREMENT: Malicious NSIS NATs and firewalls will not be
addressed by this specification. addressed by this specification.
5.7. Session Ownership 5.7. Signaling Session Ownership
Section 4.10 in [8] describes a threat where an adversary is able to Section 4.10 in [8] describes a threat where an adversary is able to
modify or delete previously installed state information at NATFW NSLP modify or delete previously installed state information at NATFW NSLP
nodes along the path. An adversary therefore needs to know session nodes along the path. An adversary therefore needs to know NATFW
specific information, such as the session identifier and MRI NSLP signaling session specific information, such as the NATFW NSLP
information. signaling session identifier and MRI information.
SECURITY REQUIREMENT: Off-path adversaries MUST NOT be able to SECURITY REQUIREMENT: Off-path adversaries MUST NOT be able to
modify or delete sessions without proper authorization. modify or delete sessions without proper authorization.
5.7.1. Misuse of Mobility in a NAT Handling Scenario 5.7.1. Misuse of Mobility in a NAT Handling Scenario
Another kind of session modification is related to mobility Another kind of NATFW NSLP signaling session modification is related
scenarios. The NSIS protocol suite offers interworking with mobility to mobility scenarios. The NSIS protocol suite offers interworking
protocol and a mobile node might need to update state along NATFW with mobility protocol and a mobile node might need to update state
NSLP nodes. along NATFW NSLP nodes.
Whenever a host behind a NAT initiates a data transfer, it is Whenever a host behind a NAT initiates a data transfer, it is
assigned an external IP and port number. In typical mobility assigned an external IP and port number. In typical mobility
scenarios, the DR might also obtain a new address according to the scenarios, the DR might also obtain a new address according to the
topology and it should convey its new IP address to the NAT. The NAT topology and it should convey its new IP address to the NAT. The NAT
is assumed to modify these NAT bindings based on the new IP address is assumed to modify these NAT bindings based on the new IP address
conveyed by the end host. conveyed by the end host.
Public Private Address Public Private Address
Internet space Internet space
skipping to change at page 78, line 39 skipping to change at page 79, line 39
| Data Traffic | | | Data Traffic | |
|--------->----------+-------->------------| |--------->----------+-------->------------|
| | | | | |
Figure 40: Connection Hijacking Figure 40: Connection Hijacking
SECURITY REQUIREMENT: A NAT/FW signaling message MUST be SECURITY REQUIREMENT: A NAT/FW signaling message MUST be
authenticated, integrity and replay protected between neighboring authenticated, integrity and replay protected between neighboring
NAT/FW NSLP nodes. The NSIS NATFW NSLP aware NAT MUST authorize NAT/FW NSLP nodes. The NSIS NATFW NSLP aware NAT MUST authorize
the end host to insure that the messages are indeed belonging to the end host to insure that the messages are indeed belonging to
the previously established session. the previously established NATFW NSLP signaling session.
5.8. Misuse of unreleased sessions 5.8. Misuse of unreleased signaling sessions
Assume that DS (N1) initiates NSIS session with DR (N2) through a Assume that DS (N1) initiates NATFW NSLP signaling session with DR
series of middleboxes as in Figure 41. When the DS is sending data (N2) through a series of middleboxes as in Figure 41. When the DS is
to DR, it might happen that the DR disconnects from the network sending data to DR, it might happen that the DR disconnects from the
(crashes or moves out of the network in mobility scenarios). In such network (crashes or moves out of the network in mobility scenarios).
cases, it is possible that another node N3 (which recently entered In such cases, it is possible that another node N3 (which recently
the network protected by the same firewall) is assigned the same IP entered the network protected by the same firewall) is assigned the
address that was previously allocated to N2. The DS could take same IP address that was previously allocated to N2. The DS could
advantage of the firewall policies installed already, if the refresh take advantage of the firewall policies installed already, if the
interval time is very high. The DS can flood the node (N3), which refresh interval time is very high. The DS can flood the node (N3),
will consume the access network resources of the victim forcing it to which will consume the access network resources of the victim forcing
pay for unwanted traffic as shown in Figure 42. Note that here we it to pay for unwanted traffic as shown in Figure 42. Note that here
make the assumption that the data receiver has to pay for receiving we make the assumption that the data receiver has to pay for
data packets. receiving data packets.
Public Internet Public Internet
+--------------------------+ +--------------------------+
| | | |
+-------+ CREATE +---+-----+ +-------+ | +-------+ CREATE +---+-----+ +-------+ |
| |-------------->------| |---->---| | | | |-------------->------| |---->---| | |
| N1 |--------------<------| FW |----<---| N2 | | | N1 |--------------<------| FW |----<---| N2 | |
| | successful RESPONSE | | | | | | | successful RESPONSE | | | | |
| |==============>======| |====>===| | | | |==============>======| |====>===| | |
+-------+ Data Traffic +---+-----+ +-------+ | +-------+ Data Traffic +---+-----+ +-------+ |
skipping to change at page 80, line 20 skipping to change at page 81, line 20
practice by itself represents a security weakness. Using IP spoofing practice by itself represents a security weakness. Using IP spoofing
an adversary is able to reach the target machines if they match, an adversary is able to reach the target machines if they match,
using the existing firewall rules. using the existing firewall rules.
The adversary is able to inject its own data traffic in conformance The adversary is able to inject its own data traffic in conformance
with the firewall policies simultaneously along with the genuine DS. with the firewall policies simultaneously along with the genuine DS.
SECURITY REQUIREMENT: Since IP spoofing is a general limitation of SECURITY REQUIREMENT: Since IP spoofing is a general limitation of
non-cryptographic packet filters no countermeasures need to be non-cryptographic packet filters no countermeasures need to be
taken by the NAT/FW NSLP. Techniques such as ingress filtering taken by the NAT/FW NSLP. Techniques such as ingress filtering
(see [23]) and, if necessary, data origin authentication (such as (see [19]) and, if necessary, data origin authentication (such as
provided with IPsec based VPNs) can help mitigate this threat. provided with IPsec based VPNs) can help mitigate this threat.
This aspect is, however, outside the scope of this document. This aspect is, however, outside the scope of this document.
5.10. Eavesdropping and Traffic Analysis 5.10. Eavesdropping and Traffic Analysis
By collecting NSLP messages, an adversary is able to learn policy By collecting NSLP messages, an adversary is able to learn policy
rules for packet filters and knows which ports are open. It can use rules for packet filters and knows which ports are open. It can use
this information to inject its own data traffic due to the IP this information to inject its own data traffic due to the IP
spoofing capability already mentioned in Section 5.9. An on-path spoofing capability already mentioned in Section 5.9. An on-path
adversary could also observe the data traffic and he could conclude adversary could also observe the data traffic and he could conclude
that it is possible to traverse a firewall. that it is possible to traverse a firewall.
An adversary could learn authorization tokens included in CREATE An adversary could learn authorization tokens included in CREATE
messages and use them to launch replay-attacks or to create a session messages and use them to launch replay-attacks or to create a NATFW
with its own address as source address. This threat is discussed in NSLP signaling session with its own address as source address. This
the respective document suggesting the usage of authorization token threat is discussed in the respective document suggesting the usage
in the NSIS protocol suite. of authorization token in the NSIS protocol suite.
SECURITY REQUIREMENT: The threat of eavesdropping itself does not SECURITY REQUIREMENT: The threat of eavesdropping itself does not
mandate the usage of confidentiality protection since an adversary mandate the usage of confidentiality protection since an adversary
can also eavesdrop on data traffic. In the context of a can also eavesdrop on data traffic. In the context of a
particular security solutions (e.g., authorization tokens) it MAY particular security solutions (e.g., authorization tokens) it MAY
be necessary to offer confidentiality protection. The latter be necessary to offer confidentiality protection. The latter
aspect is outside the scope of this document. aspect is outside the scope of this document.
5.11. Security Framework for the NAT/Firewall NSLP 5.11. Security Framework for the NAT/Firewall NSLP
skipping to change at page 81, line 35 skipping to change at page 82, line 35
is desired then the usage of C-MODE for the delivery of data packets is desired then the usage of C-MODE for the delivery of data packets
and the usage of D-MODE only to discover the next NATFW NSLP aware and the usage of D-MODE only to discover the next NATFW NSLP aware
node along the path is demanded. Almost all security threats at the node along the path is demanded. Almost all security threats at the
NATFW NSLP layer can be prevented by using a mutually authenticated NATFW NSLP layer can be prevented by using a mutually authenticated
Transport Layer secured connection and by relying on authorization by Transport Layer secured connection and by relying on authorization by
the neighboring NATFW NSLP entities. the neighboring NATFW NSLP entities.
The NATFW NSLP relies an established security association between The NATFW NSLP relies an established security association between
neighboring peers to prevent unauthorized nodes to modify or delete neighboring peers to prevent unauthorized nodes to modify or delete
installed state. Between non-neighboring nodes the session ID (SID) installed state. Between non-neighboring nodes the session ID (SID)
carried in the NTLP is used to show ownership of a session. The carried in the NTLP is used to show ownership of a NATFW NSLP
session ID MUST be generated in a random way and thereby prevent an signaling session. The session ID MUST be generated in a random way
off-path adversary to mount targeted attacks. Hence, an adversary and thereby prevent an off-path adversary to mount targeted attacks.
would have to learn the randomly generated Session ID to perform an Hence, an adversary would have to learn the randomly generated
attack. In a mobility environment a former on-path node that is now Session ID to perform an attack. In a mobility environment a former
off-path can perform an attack. The cost-benefit tradeoff to counter on-path node that is now off-path can perform an attack. The cost-
this attack does not seem to be high enough to provide a solution. benefit tradeoff to counter this attack does not seem to be high
Messages for a particular session are handled by the NTLP to the enough to provide a solution. Messages for a particular NATFW NSLP
NATFW NSLP for further processing. Messages carrying a different signaling session are handled by the NTLP to the NATFW NSLP for
session ID not associated with any NATFW NSLP are subject to the further processing. Messages carrying a different session ID not
regular processing for new NATFW NSLP sessions. associated with any NATFW NSLP are subject to the regular processing
for new NATFW NSLP signaling sessions.
5.11.2. Security Protection between non-neighboring NATFW NSLP Nodes 5.11.2. Security Protection between non-neighboring NATFW NSLP Nodes
Based on the security threats and the listed requirements it was Based on the security threats and the listed requirements it was
noted that some threats also demand authentication and authorization noted that some threats also demand authentication and authorization
of a NATFW signaling entity (including the initiator) towards a non- of a NATFW signaling entity (including the initiator) towards a non-
neighboring node. This mechanism mainly demands entity neighboring node. This mechanism mainly demands entity
authentication. Additionally, security protection of certain authentication. Additionally, security protection of certain
payloads may be required between non-neighboring signaling entities payloads may be required between non-neighboring signaling entities
and the Cryptographic Message Syntax (CMS) [17] migh be a potential and the Cryptographic Message Syntax (CMS) [14] migh be a potential
solution. Payload protection using CMS is not described in this solution. Payload protection using CMS is not described in this
document. The most important information exchanged at the NATFW NSLP document. The most important information exchanged at the NATFW NSLP
is information related to the establishment for firewall pinholes and is information related to the establishment for firewall pinholes and
NAT bindings. This information can, however, not be protected over NAT bindings. This information can, however, not be protected over
multiple NSIS NATFW NSLP hops since this information might change multiple NSIS NATFW NSLP hops since this information might change
depending on the capability of each individual NATFW NSLP node. depending on the capability of each individual NATFW NSLP node.
Some scenarios might also benefit from the usage of authorization Some scenarios might also benefit from the usage of authorization
tokens. Their purpose is to associate two different signaling tokens. Their purpose is to associate two different signaling
protocols (e.g., SIP and NSIS) and their authorization decision. protocols (e.g., SIP and NSIS) and their authorization decision.
These tokens are obtained by non-NSIS protocols, such as SIP or as These tokens are obtained by non-NSIS protocols, such as SIP or as
part of network access authentication. When a NAT or firewall along part of network access authentication. When a NAT or firewall along
the path receives the token it might be verified locally or passed to the path receives the token it might be verified locally or passed to
the AAA infrastructure. Examples of authorization tokens can be the AAA infrastructure. Examples of authorization tokens can be
found in RFC 3520 [21] and RFC 3521 [22]. Figure 43 shows an example found in RFC 3520 [17] and RFC 3521 [18]. Figure 43 shows an example
of this protocol interaction. of this protocol interaction.
An authorization token is provided by the SIP proxy, which acts as An authorization token is provided by the SIP proxy, which acts as
the assertion generating entity and gets delivered to the end host the assertion generating entity and gets delivered to the end host
with proper authentication and authorization. When the NATFW with proper authentication and authorization. When the NATFW
signaling message is transmitted towards the network, the signaling message is transmitted towards the network, the
authorization token is attached to the signaling messages to refer to authorization token is attached to the signaling messages to refer to
the previous authorization decision. The assertion verifying entity the previous authorization decision. The assertion verifying entity
needs to process the token or it might be necessary to interact with needs to process the token or it might be necessary to interact with
the assertion granting entity using HTTP (or other protocols). As a the assertion granting entity using HTTP (or other protocols). As a
skipping to change at page 83, line 34 skipping to change at page 84, line 34
| | assertion | | ----------------------- | | Entity | | | | assertion | | ----------------------- | | Entity | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| Entity Alice | <---------------------- | Entity Bob | | Entity Alice | <---------------------- | Entity Bob |
+----------------+ RESPONSE +----------------+ +----------------+ RESPONSE +----------------+
Figure 43: Authorization Token Usage Figure 43: Authorization Token Usage
Threats against the usage of authorization tokens have been mentioned Threats against the usage of authorization tokens have been mentioned
in [8] and also in Section 5.2. Hence, it is required to provide in [8] and also in Section 5.2. Hence, it is required to provide
confidentiality protection to avoid allowing an eavesdropper to learn confidentiality protection to avoid allowing an eavesdropper to learn
the token and to use it in another session (replay attack). The the token and to use it in another NATFW NSLP signaling session
token itself also needs to be protected against tempering. (replay attack). The token itself also needs to be protected against
tempering.
To harmonize the usage of authorization tokens in NSLPs a separate To harmonize the usage of authorization tokens in NSLPs a separate
document is available, see [25]. document is available, see [21].
6. IAB Considerations on UNSAF 6. IAB Considerations on UNSAF
UNilateral Self-Address Fixing (UNSAF) is described in [15] as a UNilateral Self-Address Fixing (UNSAF) is described in [12] as a
process at originating endpoints that attempt to determine or fix the process at originating endpoints that attempt to determine or fix the
address (and port) by which they are known to another endpoint. address (and port) by which they are known to another endpoint.
UNSAF proposals, such as STUN [RFC3489] are considered as a general UNSAF proposals, such as STUN [15] are considered as a general class
class of workarounds for NAT traversal and as solutions for scenarios of workarounds for NAT traversal and as solutions for scenarios with
with no middlebox communication. no middlebox communication.
This memo specifies a path-coupled middlebox communication protocol, This memo specifies a path-coupled middlebox communication protocol,
i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are
not intended as a short-term workaround, but more as a long-term not intended as a short-term workaround, but more as a long-term
solution for middlebox communication. In NSIS, endpoints are solution for middlebox communication. In NSIS, endpoints are
involved in allocating, maintaining, and deleting addresses and ports involved in allocating, maintaining, and deleting addresses and ports
at the middlebox. However, the full control of addresses and ports at the middlebox. However, the full control of addresses and ports
at the middlebox is at the NATFW NSLP daemon located to the at the middlebox is at the NATFW NSLP daemon located to the
respective NAT. respective NAT.
Therefore, this document addresses the UNSAF considerations in Therefore, this document addresses the UNSAF considerations in [12]
[RFC3424] by proposing a long-term alternative solution. by proposing a long-term alternative solution.
7. IANA Considerations 7. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the Authority (IANA) regarding registration of values related to the
NATFW NSLP, in accordance with BCP 26 RFC 2434 [16]. NATFW NSLP, in accordance with BCP 26 RFC 2434 [13].
The NATFW NSLP requires IANA to create a number of new registries. The NATFW NSLP requires IANA to create a number of new registries.
These registries may require further coordination with the registries These registries may require further coordination with the registries
of the NTLP [2] and the QoS NSLP [6]. of the NTLP [2] and the QoS NSLP [6].
NATFW NSLP Message Type Registry NATFW NSLP Message Type Registry
The NATFW NSLP Message Type is a 8 bit value. The allocation of The NATFW NSLP Message Type is a 8 bit value. The allocation of
values for new message types requires standards action. Updates and values for new message types requires standards action. Updates and
deletion of values from the registry is not possible. This deletion of values from the registry is not possible. This
skipping to change at page 85, line 52 skipping to change at page 86, line 52
1024-1999: Specification Required 1024-1999: Specification Required
2000-2047: Private/Experimental Use 2000-2047: Private/Experimental Use
2048-4095: Reserved 2048-4095: Reserved
When a new object is defined, the extensbility bits (A/B) must also When a new object is defined, the extensbility bits (A/B) must also
be defined.] be defined.]
This document defines 9 objects for the NATFW NSLP: NATFW_LT, This document defines 8 objects for the NATFW NSLP: NATFW_LT,
NATFW_EXT_IP, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, NATFW_EXT_IP, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN,
NATFW_DTINFO, NATFW_CREDENTIAL, NATFW_ICMP_TYPES. IANA is request to NATFW_DTINFO, NATFW_ICMP_TYPES. IANA is request to assigned values
assigned values for them from NSLP Object Type registry and to for them from NSLP Object Type registry and to replace the
replace the corresponding IANA-TBD tags with the numeric values. corresponding IANA-TBD tags with the numeric values.
NSLP Response Code Registry NSLP Response Code Registry
In addition it defines a number of Response Codes for the NATFW NSLP. In addition it defines a number of Response Codes for the NATFW NSLP.
These can be found in Section 4.2.4 and are to be assigned values These can be found in Section 4.2.4 and are to be assigned values
from NSLP Response Code registry. The allocation of values for from NSLP Response Code registry. The allocation of values for
Response Codes Codes requires standards action. IANA is request to Response Codes Codes requires standards action. IANA is request to
assigned values for them from NSLP Response Code registry. assigned values for them from NSLP Response Code registry.
Furthermore, IANA is requested to add a new value to the NSLP Furthermore, IANA is requested to add a new value to the NSLP
skipping to change at page 89, line 9 skipping to change at page 90, line 9
NAT/firewall threats draft, NAT/firewall threats draft,
o Henning Peters for his comments and suggestions, o Henning Peters for his comments and suggestions,
o and the NSIS working group. o and the NSIS working group.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Schulzrinne, H. and R. Hancock, "GIST: General Internet [2] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-11 (work in Signaling Transport", draft-ietf-nsis-ntlp-11 (work in
progress), August 2006. progress), August 2006.
[3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
10.2. Informative References 10.2. Informative References
[4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005. June 2005.
[5] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, [5] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004. April 2004.
[6] Manner, J., "NSLP for Quality-of-Service Signaling", [6] Manner, J., "NSLP for Quality-of-Service Signaling",
draft-ietf-nsis-qos-nslp-11 (work in progress), June 2006. draft-ietf-nsis-qos-nslp-12 (work in progress), October 2006.
[7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
Rayhan, "Middlebox communication architecture and framework", Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002. RFC 3303, August 2002.
[8] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next [8] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
Steps in Signaling (NSIS)", RFC 4081, June 2005. Steps in Signaling (NSIS)", RFC 4081, June 2005.
[9] Srisuresh, P. and M. Holdrege, "IP Network Address Translator [9] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999. (NAT) Terminology and Considerations", RFC 2663, August 1999.
[10] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - [10] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002. RFC 3234, February 2002.
[12] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, [11] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"DNS extensions to Network Address Translators (DNS_ALG)",
RFC 2694, September 1999.
[13] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[14] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [12] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Herzog, S., and R. Hess, "Identity Representation for RSVP",
RFC 3182, October 2001.
[15] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002. RFC 3424, November 2002.
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[17] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, [14] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
August 2002. July 2004.
[18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[19] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [15] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[20] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., [16] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and
S. Waldbusser, "Terminology for Policy-Based Management", S. Waldbusser, "Terminology for Policy-Based Management",
RFC 3198, November 2001. RFC 3198, November 2001.
[21] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session [17] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session
Authorization Policy Element", RFC 3520, April 2003. Authorization Policy Element", RFC 3520, April 2003.
[22] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session [18] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session
Set-up with Media Authorization", RFC 3521, April 2003. Set-up with Media Authorization", RFC 3521, April 2003.
[23] Ferguson, P. and D. Senie, "Network Ingress Filtering: [19] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[24] Alfano, F., "Diameter Quality of Service Application", [20] Alfano, F., "Diameter Quality of Service Application",
draft-alfano-aaa-qosprot-05 (work in progress), October 2005. draft-alfano-aaa-qosprot-05 (work in progress), October 2005.
[25] Manner, J., "Authorization for NSIS Signaling Layer Protocols", [21] Manner, J., "Authorization for NSIS Signaling Layer Protocols",
draft-manner-nsis-nslp-auth-01 (work in progress), June 2006. draft-manner-nsis-nslp-auth-02 (work in progress),
October 2006.
[26] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as [22] 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.
Appendix A. Selecting Signaling Destination Addresses for EXT Appendix A. Selecting Signaling Destination Addresses for EXT
As with all other message types, EXT messages need a reachable final As with all other message types, EXT messages need a reachable IP
destination IP address. But as many applications do not provide a address of the data sender on the GIST level. For the path-coupled
destination IP address in the first place, there is a need to choose MRM the source-address of GIST is the reachable IP address (i.e., the
a destination address for EXT messages. This destination address can real IP address of the data sender, or a wildcard). While this is
be the final target, but for applications which do not provide an straight forward, it is not necessarily so for the loose-end MRM.
upfront address, the destination address has to be chosen Many applications do not provide the IP address of the communication
independently. Choosing the 'correct' destination IP address may be counterpart, i.e., either the data sender or both a data sender and
difficult and it is possible there is no 'right answer'. receiver. For the EXT messages, the case of data sender is of
interest only. The rest of this section is giving informational
1. Public IP address of the data sender: guidance about determining a good destination-address of the LE-MRM
in GIST for EXT messages.
* Assumption:
+ The data receiver already learned the IP address of the
data sender (e.g., via a third party).
* Problems:
+ The data sender might also be behind a NAT. In this case
the public IP address of the data receiver is the IP
address allocated at this NAT.
+ Due to routing asymmetry it might be possible that the
routes taken by a) the data sender and the application
server b) the data sender and NAT B might be different. As
a consequence it might be necessary to advertise a new (and
different) external IP address within the application
(which may or may not allow that) after using NSIS to
establish a NAT binding.
2. Public IP address of the data receiver:
* Assumption:
+ The data receiver already learned his externally visible IP
address (e.g., based on the third party communication).
* Problems:
+ Communication with a third party is required.
3. IP address of the Application Server:
* Assumption:
+ An application server (or a different third party) is
available.
* Problems: This signaling destination address (SDA, the destination-address in
GIST) can be the data sender, but for applications which do not
provide an address upfront, the destination address has to be chosen
independently, as it is unknown at the time when the NATFW NSLP
signaling has to start. Choosing the 'correct' destination IP
address may be difficult and it is possible that there is no 'right
answer' for all applications relying on the NATFW NSLP.
+ If the NSIS signaling message is not terminated at the NAT Whenever possible it is RECOMMENDED to chose the data sender's IP
of the local network then an NSIS unaware application address as SDA. It necessary to differentiate between the received
server might discard the message. IP addresses on the data sender. Some application level signaling
protocols (e.g., SIP) have the ability to transfer multiple contact
IP addresses of the data sender. For instance, private IP address,
public IP address at NAT, and public IP address at a relay. It is
RECOMMENDED to use all non-private IP addresses as SDAs.
+ Routing might not be optimal since the route between a) the A different SDA must be chosen, should the IP address of the data
data receiver and the application server b) the data sender be unknown. This can have multiple reasons: The application
receiver and the data sender might be different. level signaling protocol cannot determine any data sender IP address
at this point of time or the data receiver is server behind a NAT,
i.e., accepting inbound packets from any host. In this case, the
NATFW NSLP can be instructed to use the public IP address of an
application server or any other node. Choosing the SDA in this case
is out of the scope of the NATFW NSLP and depends on the
application's choice. The local network can provide a network-SDA,
i.e., a SDA which is only meaningful to the local network. This will
ensure that GIST packets with destination-address set to this
network-SDA are going to be routed to a edge-NAT or edge-firewall.
Appendix B. Applicability Statement on Data Receivers behind Firewalls Appendix B. Applicability Statement on Data Receivers behind Firewalls
Section 3.7.2 describes how data receivers behind middleboxes can Section 3.7.2 describes how data receivers behind middleboxes can
instruct upstream firewalls/NATs to forward NATFW NSLP signaling instruct inbound firewalls/NATs to forward NATFW NSLP signaling
towards them. Finding an upstream edge-NAT in address environment towards them. Finding an inbound edge-NAT in address environment
with NAT'ed addresses is quite easy. It is only required to find with NAT'ed addresses is quite easy. It is only required to find
some edge-NAT, as the data traffic will be route-pinned to the NAT, some edge-NAT, as the data traffic will be route-pinned to the NAT,
which is done with the LE-MRM. Locating the appropriate edge- which is done with the LE-MRM. Locating the appropriate edge-
firewall with the PC-MRM, sent upstream is difficult. For cases with firewall with the PC-MRM, sent inbound is difficult. For cases with
a single, symmetric route from the Internet to the data receiver, it a single, symmetric route from the Internet to the data receiver, it
is quite easy; simply follow the default route in the upstream is quite easy; simply follow the default route in the inbound
direction. direction.
+------+ Data Flow +------+ Data Flow
+-------| EFW1 +----------+ <=========== +-------| EFW1 +----------+ <===========
| +------+ ,--+--. | +------+ ,--+--.
+--+--+ / \ +--+--+ / \
NI+-----| FW1 | (Internet )----NR+/NI/DS NI+-----| FW1 | (Internet )----NR+/NI/DS
NR +--+--+ \ / NR +--+--+ \ /
| +------+ `--+--' | +------+ `--+--'
+-------| EFW2 +----------+ +-------| EFW2 +----------+
skipping to change at page 99, line 38 skipping to change at page 98, line 38
o NATFW_EFI: 0x00F3 o NATFW_EFI: 0x00F3
o NATFW_INFO: 0x00F4 o NATFW_INFO: 0x00F4
o NATFW_NONCE: 0x00F5 o NATFW_NONCE: 0x00F5
o NATFW_MSN: 0x00F6 o NATFW_MSN: 0x00F6
o NATFW_DTINFO: 0x00F7 o NATFW_DTINFO: 0x00F7
o NATFW_CREDENTIAL: 0x00F8
o NATFW_ICMP_TYPES: 0x00F9 o NATFW_ICMP_TYPES: 0x00F9
1345 1345
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
skipping to change at page 100, line 28 skipping to change at page 99, line 28
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich 81739 Munich 81739
Germany Germany
Phone: Phone:
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Cedric Aoun Cedric Aoun
Ecole Nationale Superieure des Telecommunications
Paris Paris
France France
Email: cedric@caoun.net Email: cedric@caoun.net
Elwyn Davies Elwyn Davies
Folly Consulting Folly Consulting
Soham Soham
UK UK
Phone: +44 7889 488 335 Phone: +44 7889 488 335
Email: elwynd@dial.pipex.com Email: elwynd@dial.pipex.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 219 change blocks. 
771 lines changed or deleted 804 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/