wdiff draft-ietf-nsis-nslp-natfw-02.txt draft-ietf-nsis-nslp-natfw-03.txt

NSIS Working Group M. Stiemerling
Internet-Draft NEC
Expires: November 19, 2004 January 17, 2005 H. Tschofenig
Siemens
M. Martin
NEC
C. Aoun
Nortel Networks
May 21,
July 19, 2004

NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
draft-ietf-nsis-nslp-natfw-02
draft-ietf-nsis-nslp-natfw-03

Status of this Memo

This document is an Internet-Draft and is in full conformance with subject to all provisions
of Section 10 section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of RFC2026.
which he or she become aware will be disclosed, in accordance with
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

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
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 19, 2004. January 17, 2005.

Abstract

This memo defines the NSIS Signaling Layer Protocol (NSLP) for
Network Address Translators and Firewalls. This NSLP allows hosts to
signal along a data path for Network Address Translators and
Firewalls to be configured according to the data flow needs. The
network scenarios, problems and solutions for path-coupled Network
Address Translator and Firewall signaling are described. The overall
architecture is given by the framework and requirements defined by
the Next Steps in Signaling (NSIS) working group. This is one of two
NSIS Signaling Layer Protocols (NSLPs) the working group will address
during its work.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 5
1.1 Terminology and Abbreviations . . . . . . . . . . . . . . 5 6
1.2 Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 7 8
1.3 General Scenario for NATFW Traversal Non-Goals . . . . . . . . . . . 8

2. Network Environment . . . . . . . . . . . . . 9
1.4 General Scenario for NATFW Traversal . . . . . . . . 10
2.1 . . . 9

2. Network Deployment Scenarios for Protocol Functionality using NATFW NSLP . . . . . . . 10
2.1.1 . 11
2.1 Firewall traversal Traversal . . . . . . . . . . . . . . . . . . 10
2.1.2 . . 11
2.2 NAT with two private Networks . . . . . . . . . . . . 11
2.1.3 . . 12
2.3 NAT with private network Private Network on sender side Sender Side . . . . . . . . . 12
2.1.4
2.4 NAT with private network Private Network on receiver side . . Receiver Side Scenario . . . . 12
2.1.5 13
2.5 Both End Hosts behind twice-NATs . . . . . . . . . . . 13
2.1.6 . . 14
2.6 Both End Hosts behind same Behind Same NAT . . . . . . . . . . . . 14
2.1.7 . . 15
2.7 IPv4/v6 NAT with two private networks Private Networks . . . . . . . . . . 15
2.1.8
2.8 Multihomed Network with NAT . . . . . . . . . . . . . . . 16
2.2 Trust Relationship and Authorization

3. Protocol Description . . . . . . . . . . . 17
2.2.1 Peer-to-Peer Trust Relationship . . . . . . . . . . 18
3.1 Policy Rules . . . . . . . . . . . . 17
2.2.2 Intra-Domain Trust Relationship . . . . . . . . . . . 18
2.2.3 End-to-Middle Trust Relationship
3.2 Basic protocol overview . . . . . . . . . . . 19

3. Protocol Description . . . . . . 18
3.3 Protocol Operations . . . . . . . . . . . . . . . 21
3.1 Basic protocol overview . . . . 20
3.3.1 Creating Sessions . . . . . . . . . . . . . . . . . . 21
3.2 Protocol Operations
3.3.2 Reserving External Addresses . . . . . . . . . . . . . 23
3.3.3 NATFW Session refresh . . . . . . 23
3.2.1 Creating . . . . . . . . . . 27
3.3.4 Deleting Sessions . . . . . . . . . . . . . . . . . . 23
3.2.2 Reserving External Addresses 28
3.3.5 Reporting Asynchronous Events . . . . . . . . . . . . 29
3.3.6 QUERY capabilities within the NATFW NSLP protocol . . 30
3.3.7 QUERY Message semantics . . . . . . . . . . . . . . . 31
3.4 NATFW NSLP proxy mode of operation . . . . . . . . 25
3.2.3 . . . . 32
3.4.1 Reserving External Addresses and triggering Create Session
messages . . . 28
3.2.4 Prolonging Sessions . . . . . . . . . . . . . . . . . 28
3.2.5 Deleting Sessions . . . 32
3.4.2 Using CREATE messages to Trigger Reverse Path
CREATE Messages . . . . . . . . . . . . . . . 29
3.2.6 Authorization . . . . 35
3.4.2.1 CREATE Responses Sent on Previously Pinned
Down Reverse Path . . . . . . . . . . . . . . . . 30
3.2.7 Calculation of Lifetimes 35
3.4.2.2 CREATE Responses Sent on Separately
Established Reverse Path . . . . . . . . . . . . . 36
3.5 Calculation of Session Lifetime . . . . . . 30
3.2.8 . . . . . . . 37
3.6 Middlebox Resource . . . . . . . . . . . . . . . . . . 31
3.2.9 . . 39
3.7 De-Multiplexing at NATs . . . . . . . . . . . . . . . 31
3.2.10 . . 39
3.8 Selecting Destination IP addresses Opportunistic Addresses for REA . . . . . . 32
3.3 . . 40

4. NATFW NSLP Messages Components NTLP Requirements . . . . . . . . . . . . . . 33
3.3.1 . . . 42

5. NATFW NSLP Header Message Components . . . . . . . . . . . . . . . . 43
5.1 NSLP Header . . . . . 33
3.3.2 NSLP message types . . . . . . . . . . . . . . . . . . 34
3.3.3 43
5.2 NSLP Objects message types . . . . . . . . . . . . . . . . . . . . 43
5.3 NSLP Objects . 34
3.3.3.1 Session ID Object . . . . . . . . . . . . . . . . 35
3.3.3.2 . . . . . . 44
5.3.1 Session Lifetime Object . . . . . . . . . . . . . 35
3.3.3.3 . . 44
5.3.2 External Address Object . . . . . . . . . . . . . 36
3.3.3.4 . . 45
5.3.3 Extended Flow Information Object . . . . . . . . . 37
3.3.3.5 Error . . 46
5.3.4 Response Code Object . . . . . . . . . . . . . . . . . 47
5.3.5 Response Type Object . . 37
3.4 Message Formats . . . . . . . . . . . . . . . 47
5.3.6 Message Sequence Number Object . . . . . . 38
3.4.1 Policy Rules . . . . . . 48
5.3.7 Scoping Object . . . . . . . . . . . . . . . 38
3.4.2 Create . . . . . 48
5.3.8 Bound Session (CRS) ID Object . . . . . . . . . . . . . . . 49
5.3.9 Notify Target Object . . 39
3.4.3 Reserve External Address (REA) . . . . . . . . . . . . 39
3.4.4 Reserve-Create (REC) . . . 49
5.4 Message Formats . . . . . . . . . . . . . . 39
3.4.5 Prolong Session (PLS) . . . . . . . 50
5.4.1 CREATE . . . . . . . . . 39
3.4.6 Delete Session (DLS) . . . . . . . . . . . . . . . 50
5.4.2 RESERVE-EXTERNAL-ADDRESS (REA) . . 40
3.4.7 Path Succeeded (PS) . . . . . . . . . . 50
5.4.3 TRIGGER . . . . . . . 40
3.4.8 Path Deleted (PD) . . . . . . . . . . . . . . . . 51
5.4.4 RESPONSE . . 40
3.4.9 Return External Address (RA) . . . . . . . . . . . . . 40
3.4.10 Error Response (ER) . . . . . . . . 51
5.4.5 QUERY . . . . . . . . . 41

4. . . . . . . . . . . . . . . . 51
5.4.6 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 52

6. NSIS NAT and Firewall transitions issues Transition Issues . . . . . . . . . . . 42

5. 53

7. Security Considerations . . . . . . . . . . . . . . . . . . . 43

6. 54
7.1 Trust Relationship and Authorization . . . . . . . . . . . 54
7.1.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . 55
7.1.2 Intra-Domain Trust Relationship . . . . . . . . . . . 56
7.1.3 End-to-Middle Trust Relationship . . . . . . . . . . . 57

8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45

7. 59

9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46

8. 60

10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1 61
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 47
8.2 61
10.2 Informative References . . . . . . . . . . . . . . . . . . . 47 61

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49 64

A. Problems and Challenges . . . . . . . . . . . . . . . . . . . 51 65
A.1 Missing Network-to-Network Trust Relationship . . . . . . 51 65
A.2 Relationship with routing . . . . . . . . . . . . . . . . 52 66
A.3 Affected Parts of the Network . . . . . . . . . . . . . . 53 66
A.4 NSIS backward compatibility with NSIS unaware NAT and
Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 53 66
A.5 Authentication and Authorization . . . . . . . . . . . . . 54 67
A.6 Directional Properties . . . . . . . . . . . . . . . . . . 54 67
A.7 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 54 68
A.8 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 55 68
A.9 Combining Middlebox and QoS signaling . . . . . . . . . . 55 68
A.10 Inability to know the scenario . . . . . . . . . . . . . . 55 69

B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 70

Intellectual Property and Copyright Statements . . . . . . . . 58 71

1. Introduction

Firewalls and Network Address Translators (NAT) have been both been used
throughout the Internet for many years years, and they will be remain present in
for the foreseeable future. Using Firewalls brings security are used to protect networks
against certain types of attacks from the outside, and in times of
IPv4 address depletion depletion, NATs virtually extend the IP address space. In
general, both
Both types of devices may be obstacles to many applications, since
they only allow specific traffic created by a limited set of applications to
traverse them (i.e., (e.g., most HTTP traffic
or in general traffic, and client/server applications).
applications), due to the rather static properties of those
protocols. Other applications, for
instance, such as IP telephony or any and most other
peer-to-peer application, applications with more dynamic properties suffer from Firewalls and properties, create
traffic which is unable to traverse NATs so that they
do not work at all. Therefore, and Firewalls unassisted.
In practice, the traffic from many applications cannot traverse
Firewall
Firewalls or NATs. NATs, even if they work autonomously in an attempt to
restore the transparency of the network.

Several solutions to enable any application applications to traverse those boxes such entities
have been proposed and are currently used. in use. Typically, application
level gateways (ALG) have been integrated and so configuring
Firewalls and NATs with the Firewall or NAT to
configure the Firewall or NAT dynamically. Another approach is
middlebox communication (MIDCOM, currently under standardization at
the IETF). In this approach approach, ALGs external to the Firewall and or NAT external ALGs
configure them the corresponding entity via the MIDCOM protocol [7].
Several other work around work-around solutions are available as well, see such as
STUN [32] [35] and [31]. TURN [37]. However, all of these approaches introduce
other problems that are hard to solve; like solve, such as dependencies on certain the
type of NAT implementations implementation (full-cone, symmetric, ...), or dependency
dependencies on a certain network topology.

NAT and Firewall (NATFW) signaling share a property with Quality of
Service (QoS) signaling, i.e., in signaling. Namely, both cases it is required to reach require that any device on the
data path that is involved in QoS or NATFW treatment of data packets. packets
is reached. For both, NATFW and QoS, signaling travels path-coupled,
meaning that the signaling messages follow exactly the same path as that
the data packets do. take. RSVP [14] is an example for of a current QoS
signaling protocol. protocol that is path-coupled.

This memo defines a path-coupled signaling protocol in the framework
of NSIS for NAT and
Firewall configuration, configuration within the framework of NSIS, called the NATFW
NSIS Signaling Layer Protocol (NSLP). The general requirements for
NSIS are defined in [2]. The general framework of NSIS is outlined
in [1] and [1]. It introduces the split between an NSIS transport layer and
an NSIS signaling layer. The transport of NSLP messages is handled
by an NSIS Network Transport Layer Protocol (NTLP, see [3]) and takes
care about NSLP message transport. with GIMPS [3]
being the implementation of the abstract NTLP). The signaling logic
for QoS and NATFW signaling is implemented in the different NSLPs.

The QoS NSLP is defined in [4], furthermore while the general requirements for NSIS are
defined in [2].

There is a series of related documents to NATFW NSLP discussing
several other aspects of path-coupled NATFW signaling, including
security [20], migration [17], intrarealm signaling [18], and
inter-working with SIP [19]. is defined in
this document.

The NATFW NSLP allows requesting is designed to request the configuration of NATs and/or and/
or Firewalls along the data path to enable data flows to traverse
these devices without being obstructed. A simplified example: A
source host sends a NATFW NSLP signaling message towards its data
destination. This message follows the data path and every path. Every NATFW NSLP
NAT/Firewall along the data path intercepts these messages, processes
it
them, and configures itself accordingly. Afterwards, the actual data
flow can traverse every configured Firewall/NAT.

NATFW NSLP runs in two different modes, one is the path directed CREATE mode
where Firewalls in
which state at firewalls and NATs are configured along is created. In the data path as
pointed out above example,
this takes place in the above example. direction from the data sender to the data
receiver. The second one other mode is the reserve RESERVE mode. In this mode, where NATs
are detected discovered by the NSLP/NTLP within the network signaling messages, and a public publicly
reachable IP address and a port number are reserved. reserved at each NAT.
This
reserve mode enables hosts located behind NATs in a private addressing realm
delimited by a NAT to receive data originated in the public Internet on the reverse data path. network.
Both modes create NATFW NSLP and NTLP state in network entities.
NTLP state allows signaling messages to travel in the network. The forward
(downstream ) and the reverse (upstream) direction along the path
between an NAT/Firewall NSLP
state is maintained via sender and a soft-state mechanism. State includes not
only signaling state, but as well as corresponding receiver.
NAT bindings and Firewall rules. firewall rules are NAT/Firewall specific state.
This state is maintained via managed using a lifetime soft-state mechanism, i.e., it expires
unless it is refreshed every now and must be kept alive via then by a
lifetime extension mechanism if needed. Two signaling messages are certain message. If
state is to be deleted explicitly before it automatically expires,
another message can be used for deleting that. To find out which state explicitly and extending state's lifetime.
In general, all NATFW NSLP signaling messages are exchanged
end-to-end.

Traversal of non NATFW NSLPs or the NTLP is out of scope of this
document. Furthermore, only Firewalls and NATs are considered
currently installed in
this document, NSIS NAT/Firewall nodes, a query message can
be used at any other device, for instance IPSec security gateway,
is out of scope. time.

Section 2 describes the network environment for NATFW NSLP signaling
and highlights signaling,
highlighting the required trust relationship/ authorization. relationships and authorization required.
Section 3 defines the NATFW signaling protocol with its message
components, message formats, protocol. Section 5 defines
the messages and protocol operations. The and message components. In the remaining
document refers in parts of
the main body of the document, Section 4 to 6 covers transition issues and issues,
while Section 7 addresses security
considerations are handled considerations, with more
extensive discussions of security issues currently being contained in
[20]. Currently unsolved problems and challenges are listed and
discussed in Appendix A. Please note that readers familiar with possible locations of
Firewalls and NAT in NATs and their possible location within networks can
safely skip Section 2.

1.1 Terminology and Abbreviations

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

This document uses a number of terms defined in [2]. Furthermore, these The following
additional terms are used:
o NSIS NAT Forwarding State: The This term "NSIS NAT Forwarding State" in
this context refers to a state used to
forward the NSIS signaling message beyond the targeted destination address; that state is
typically used when the NSIS Responder address is not known
o Sender-/Receiver Initiated Signaling
Sender-initiated: NAT bindings and Firewall rules are created
immediately when the "path" message hits the NSIS nodes. With
"path" message we refer to the signaling message traveling from
the data sender towards the data receiver.
Receiver-initiated: NAT bindings and Firewall rules are created
when the "reserve" message returns from the other end. With
"reserve" message we refer to a signaling message on the
reverse path, this means from the receiver to the sender (i.e.
backwards routed).
Note that these definitions have nothing to do with number of
roundtrips, who performs authorization etc.
address.
o Policy rule: In general, a 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 conditions - where the conditions are evaluated to
determine whether the actions are performed." [RFC3198]. performed" [38]. In the context
of NSIS NATFW NSLP NSLP, the condition is a specification of a set of
packets to which rules are applied. The set of actions always
contains just a single element per rule, and is limited to either
action "reserved" "reserved", "deny" or action "enable". "allow".
o Firewall: A packet filtering device that matches packet packets against a
set of policy rules and applies the actions. In the context of
NSIS NATFW NSLP we refer to this device as Firewall.
o Network Address Translator: Network Address Translation is a
method by which IP addresses are mapped from one realm to another,
in an attempt to provide transparent routing to between hosts (see [9]).
[8]). Network Address Translators are devices that perform this
method.
o Middlebox: from [12]: "A middlebox is defined as any intermediate device
performing functions other than the normal, standard functions of
an IP router on the datagram path between a source host and a
destination host". The term middlebox in host" [12]. In the context of this document and in NSIS
NSIS, the term middlebox refers to Firewalls and NATs only. Other
types of middlebox are currently outside the scope.
o Security Gateway: IPsec based gateways.
o NSIS Initiator (NI): the The signaling entity, which entity that makes the a resource
request, usually as a result of user application request.
o NSIS Responder (NR): the The signaling entity , which that acts as the final
destination for the signaling and signaling. It can optionally interact with
applications as well.
o NSIS Forwarder (NF): the A signaling entity between an NI and an NR
which propagates NSIS signaling further through the network.
o Receiver (DR or R): the The node in the network, which network that is receiving the
data packets of a flow.
o Sender (DS or S): the The node in the network, which network that is sending the data
packets of a flow.
o NATFW NSLP session: Application An application layer flow of information for
which some network control state information is to be manipulated
or monitored (as defined in [1]). The control state for NATFW
NSLP is consists of NSLP state and associated policy rules at the a
middlebox.
o NSIS peer or peer: An NSIS node with which a an NSIS adjacency has
been created as defined in [3].

o Edge NAT: By An edge NAT we refer to the is a NAT device, which device that is reachable from outside the
public Internet and that has a globally routable IP address.
o Edge Firewall: An edge Firewall is a Firewall device that is
located on the demarcation line of an administrative domain.
o Public Network: Definition according to [8] is "A Global or Public Network is an address realm
with unique network addresses assigned by Internet Assigned
Numbers Authority (IANA) or an equivalent address registry. This
network is also referred as External network during NAT discussions."
discussions" [8].
o Private/Local Network: Definition according to [8] is " A "A private network is an address realm
independent of external network addresses. Private network may
also be referred alternately as Local Network. Transparent
routing between hosts in private realm and external realm is
facilitated by a NAT router." router" [8]. IP address space allocation for
private networks is recommended in [33] [36]
o Public/Global IP address: An IP address located in the public
network.
network according to Section 2.7 of [8].
o Private/Local IP address: An IP address located in the private
network.
network according to Section 2.8 of [8].
o Initial CREATE: A CREATE message creating a new session.

1.2 Middleboxes

The term middlebox raises different expectations about functionality
provided by such covers a device. Middleboxes range of devices which intercept the flow
of packets between end hosts and perform actions other than standard
forwarding expected in an IP router. As such, middleboxes fall into
a number of categories with a wide range of functionality not all of
which is pertinent to the NATFW NSLP. Middlebox categories in the
scope of this memo are Firewalls that filter data packets against their a
set of filter rules rules, and NATs that translate packet addresses from
one address realm to another address realm. Other types categories of
middleboxes, for instance such as QoS traffic shapers and security gateways, are
out of scope.

The term NAT used in this document is placeholder for a range of
different NAT flavors. We consider those these types of NATs:
o traditional NAT (basic NAT and NAPT)
o Bi-directional NAT
o Twice-NAT
o Multihomed NAT
For definitions and a detailed discussion about the characteristics
of each NAT type please see [8].

Both types of middleboxes under consideration here use policy rules for
to make a decision on data packet treatment. Policy rules consist of
a 5-tuple flow identifier (which is typically a 5-tuple) and an associated action. Data
action; data packets matching this 5-tuple experience the flow identifier are subjected to
the policy rule action. A 5-tuple consists of: selector matches the following
fields of a packet to configured values:
o Source IP address and port number
o Destination destination IP address and port number addresses
o Transport protocol number
o Transport source and destination port numbers

For further examples of flow identifiers see Section 5.1 of [3].

Actions for Firewalls are usually: usually one or more of:
o Allow: forward data packet
o Deny: block data packet and discard it
o Other actions like logging, diverting, duplicating, etc

Actions for NATs are include (amongst many others):
o Change source IP address and transport port number to a global globally
routeable IP address and associated port number.
o Change destination IP address and transport port number to a
private IP address and associated port number.

1.3 Non-Goals

Traversal of non-NSIS and non-NATFW NSLP aware NATs and Firewalls
is outside the scope of this document.
Only Firewalls and NATs are considered in this document, any other
types of devices, for instance IPSec security gateway, are out of
scope.
The exact implementation of policy rules and their mapping to Firewall
firewall rule sets and NAT bindings or sessions at the middlebox
is an implementation issue and thus out of scope of this document.
Some devices entitled categorized as Firewalls firewalls only accept traffic after
cryptographic verification (i.e. (i.e., IPsec protected data traffic).
Particularly for network access scenarios scenarios, either link layer or
network layer data protection is common. Hence we do not address
these types of devices (referred to as security gateways) since
per-flow signaling is rather uncommon in this environment. For a discussion
of network access authentication and associated scenarios the reader
is referred to the PANA working group (see [26]).
Discovering security gateways, which was also mentioned as an
application for NSIS signaling, for the purpose of executing an
IKE to create an IPsec SA, is already solved without requiring NSIS. outside the scope of this document.
In mobility scenarios an often experienced scenarios, a common problem is the traversal of a
security gateway at the edge of the a corporate network. Network
administrators often rely on the policy that allow only authenticated data
traffic is allowed to enter the network.
A problem statement for the traversal of these security gateways
in the context of Mobile IP can be found at [25]).

Other proposals for path-coupled NAT and Firewall traversal like RSVP
and CASP are described in [27] and [28].

1.3 [28]). This topic is
not within the scope of the present document.

1.4 General Scenario for NATFW Traversal

The purpose of NSIS NATFW signaling is to enable any communication
between endpoints across networks even in the presence of NAT and
Firewall middleboxes. It is expected assumed that those these middleboxes will be
statically configured in such a way that NSIS NATFW signaling
messages itself themselves are allowed to traverse them. NSIS NATFW NSLP
signaling is used to dynamically install such additional policy rules in
all NATFW middleboxes along the data path. Firewalls are configured
to forward data packets matching the policy rule provided by the NSLP
signaling. NATs are configured to translate data packets matching
the policy rule provided by the NSLP signaling.

The basic high-level picture of NSIS usage is that endhosts end hosts are
located behind middleboxes (NAT/FW in Figure 1). Applications
located at these endhosts end hosts try to establish communication between them
and use with
corresponding applications on other such end hosts. They trigger the
NSIS entity at the local host to provide for middlebox traversal
along the prospective data path (e.g., via an API call). The NSIS
entity in turn uses NSIS NATFW NSLP signaling to establish policy
rules on a along the data path, which allows allowing the said data to travel from the
sender to the receiver unobstructed. The applications can somehow trigger
middlebox traversal (e.g. via an API call) at the NSIS entity at the
local host.

Application Application Server (0, 1, or more) Application

+----+ +----+ +----+
| +------------------------+ +------------------------+ |
+-+--+ +----+ +-+--+
| |
| NSIS Entities NSIS Entities |
+-+--+ +----+ +-----+ +-+--+
| +--------+ +----------------------------+ +-----+ |
+-+--+ +-+--+ +--+--+ +-+--+
| | ------ | |
| | //// \\\\\ | |
+-+--+ +-+--+ |/ | +-+--+ +-+--+
| | | | | Internet | | | | |
| +--------+ +-----+ +----+ +-----+ |
+----+ +----+ |\ | +----+ +----+
\\\\ /////
sender NAT/FW (1+) ------ NATFW (1+) receiver

Figure 1: Generic View on NSIS in a NAT / Firewall case

For running end-to-end NATFW signaling signaling, it is necessary that each Firewall firewall
and each NAT involved in along the path between the data sender and the data
receiver implement the signaling communication runs an NSIS NATFW
entity. NSLP. There might be several NATs
and FWs in various possible combinations on a path between two hosts. The reader is referred to
Section 2.1 where different 2 presents a number of likely scenarios are presented. with different
combinations of NATs and firewalls.

2. Network Environment

2.1 Network Deployment Scenarios for Protocol Functionality using NATFW NSLP

This section introduces several scenarios for middleboxes in the
Internet. middlebox placement
within IP networks. Middleboxes are located typically found at various
different locations, i.e. including at Enterprise network borders, within
enterprise networks, as mobile phone network gateways, etc. In general, Usually,
middleboxes are placed more rather towards the edge of networks and less than in
network cores. Those
middleboxes are not only Firewalls and NATs may be found at these locations
either Firewall alone, or NAT and any they may be combined; other type categories of
combination is possible. Thus,
middleboxes may also be found at such locations, possibly combined
with the NATs and/or Firewalls. To reduce the number of network
elements needed, combined Firewall and NATs are have been made available.

NSIS initiators (NI) are sending send NSIS NATFW NSLP signaling messages via the
regular data path to the NSIS responder (NR). On the data
path path,
NATFW NSLP signaling messages reach different NSIS peers that
have
implement the NATFW NSLP implemented. NSLP. Each NATFW NSLP node processes the
signaling messages according to Section 3 and installs, and, if necessary, installs
policy rules for subsequent data packets.

Each of the following section sub-sections introduces a different scenario
for a different set of middleboxes and their ordering within the
topology. It is assumed that each middlebox implements the NSIS
NATFW NSLP signaling protocol.

2.1.1

2.1 Firewall traversal Traversal

This section describes a scenario with Firewalls only and only; NATs are not
involved. Both Each end hosts are host is behind a Firewall that is Firewall. The Firewalls are
connected via the public Internet. Figure 2 shows the topology. The
part labeled "public" is the Internet connection connecting both Firewalls.

+----+ //----\\ +----+
NI -----| FW |---| |------| FW |--- NR
+----+ \\----// +----+

private public private

FW: Firewall
NI: NSIS Initiator
NR: NSIS Responder

Figure 2: Firewall Traversal Scenario

Each Firewall on-path on the data path must provide traversal service for
NATFW NSLP in order to permit the NSIS message to reach the other end
host. All Firewalls process NSIS signaling and establish appropriate
policy rules, so that the required data packet flow can traverse
them.

2.1.2

2.2 NAT with two private Networks

Figure 3 shows a scenario with NATs at both ends of the network.
Therefore, each application instance, NSIS initiator and NSIS
responder, are behind NATs. The outermost NAT at each side is
connected to the public Internet. The NATs are generically labeled
as MB (for middlebox), since those devices definitely implement at least NAT-only, NAT
functionality, but can implement Firewalling firewall functionality as well.

Only two middleboxes MB are shown in Figure 3 at each side, but in
general more than one MB
general, any number of MBs on each side must be considered.

+----+ +----+ //----\\ +----+ +----+
NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR
+----+ +----+ \\----// +----+ +----+

private public private

MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder

Figure 3: NAT with two private networks Private Networks Scenario

Signaling traffic from NI to NR has to traverse all four the middleboxes
on the path path, and all four the middleboxes must be configured properly to
allow NSIS signaling to traverse. traverse them. The NATFW signaling must
configure all middleboxes and consider any address translation that
will result from this configuration in further signaling. The sender
(NI) has to know the IP address of the receiver (NR) in advance,
otherwise he cannot it will not be possible to send a single any NSIS signaling message messages
towards the responder. Note that this IP address is not the private
IP address of the responder. Instead a NAT binding (including a
public IP address) has to be obtained from previously installed on the NAT that
subsequently allows packets hitting reaching the NAT to be forwarded to the
receiver within the private address realm. This generally requires
further support from an application layer protocol for the purpose of
discovering and exchanging information. The receiver might have a
number of ways to learn its public IP address and port number and
might need to signal this information to the sender using the
application level signaling protocol.

2.1.3

2.3 NAT with private network Private Network on sender side Sender Side

This scenario shows an application instance at the sending node that
is behind one or more NATs (shown as MB). generic MB, see discussion in
Section 2.2). The receiver is located in the public Internet.

+----+ +----+ //----\\
NI --| MB |-----| MB |---| |--- NR
+----+ +----+ \\----//

private public

MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder

Figure 4: NAT with private network Private Network on sender scenario Sender Side Scenario

The traffic from NI to NR has to traverse only middleboxes only on the
sender's side. The receiver has a public IP address. The NI sends
its signaling message directly to the address of the NSIS responder.
Middleboxes along the path intercept the signaling messages and
configure the policy rules accordingly.

Note that the data sender does not necessarily know whether the
receiver is behind a NAT or not, hence, it is the receiving side that
has to detect whether itself is behind a NAT or not. As described in
Section 3.2.2 3.3.2 NSIS can also provide help for this procedure.

2.1.4

2.4 NAT with private network Private Network on receiver side Receiver Side Scenario

The application instance receiving data is behind one or more NATs. NATs
shown as MB (see discussion in Section 2.2).

//----\\ +----+ +----+
NI ---| |---| MB |-----| MB |--- NR
\\----// +----+ +----+

public private

MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder

Figure 5: NAT with private network Private Network on receiver Receiver Scenario

Initially, the NSIS responder must determine its public reachable IP
address at the external middlebox and notify the NSIS initiator about
this address. One possibility is that an application level protocol
is used, meaning that the public IP address is signaled via this
protocol to the NI. Afterwards the NI can start its signaling
towards the NR and so establishing the path via the both middleboxes
MB. in
the receiver side private network.

This scenario describes the use case for the reserve RESERVE mode of the
NATFW NSLP.

2.1.5

2.5 Both End Hosts behind twice-NATs

This is a special case, where the main problem is to detect consists of detecting
that both
nodes end hosts are logically within the same address space, but
are also behind in two partitions of the address realm on either side of a
twice-NAT (see [8] for a discussion about of twice-NAT functionality).

Sender and receiver are both within a single private address realm and
but the two partitions potentially have overlapping IP addresses. address
ranges. Figure 6 shows the
ordering arrangement of NATs. This is a common
configuration in several networks, particularly after the merging of
companies that have used the same private address space, thus having overlapping addresses resulting in many
cases.
overlapping address ranges.

public
+----+ +----+ //----\\
NI --| MB |--+--| MB |---| |
+----+ | +----+ \\----//
|
| +----+
+--| MB |------------ NR
+----+

private

MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder

Figure 6: NAT to public, sender Public, Sender and receiver behind Receiver on either side of a
twice-NAT Scenario

The middleboxes shown in Figure 6 are twice-NATs, i.e. i.e., they map IP
addresses and port numbers on both sides, at private and public
interfaces.

This scenario requires assistance of application level entities, like such
as a DNS server. Those The application level gateways must handle request requests
that are based on symbolic names names, and configure the middleboxes so
that data packets are correctly forwarded from NI to NR. The
configuration of those middleboxes may require other middlebox
communication protocols, like MIDCOM [7]. NSIS signaling is not
required in the twice-NAT only case, since the middleboxes of type the
twice-NAT type are normally configured by other means. Nevertheless,
NSIS signaling might by useful when there are Firewalls on path. In
this case NSIS will not configure any policy rule at twice-NATs, but
will configure policy rules at the intermediate Firewalls. Firewalls on the path. The NSIS
signaling protocol must be at least robust enough to survive this
scenario.

2.1.6

2.6 Both End Hosts behind same Behind Same NAT

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
not aware of this fact. As in Section 2.1.4 2.4 the NSIS responder must
determine its public IP address in advance and transfer it to the
NSIS initiator. Afterwards, the NSIS initiator can start sending the
signaling messages to the responder's public IP address. During this
process, a public IP address will be allocated for the NSIS initiator
at the same middlebox as for the responder. Now, the NSIS signaling
and the subsequent data packets will traverse the NAT two times: twice: from
initiator to public IP address of responder (first time) and from
public IP address of responder to responder (second time). This is
the worst case, case in which both sender and receiver obtain a public IP
address at the NAT NAT, and the communication path is certainly not
optimal anymore. in this case.

NI public
\ +----+ //----\\
+-| MB |----| |
/ +----+ \\----//
NR
private

MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder

Figure 7: NAT to public, both host behind same Public, Both Hosts Behind Same NAT

The NSIS NATFW signaling protocol should support mechanisms to detect
such a scenario. The signaling should directly by be exchanged directly between
NI and NR without involving the middlebox.

2.1.7

2.7 IPv4/v6 NAT with two private networks Private Networks

This scenario combines the usage use case mentioned described in Section 2.1.2 2.2 with the
IPv4 to IPv6 transition scenario, i.e. scenario involving address and protocol
translation, i.e., using Network Address and Protocol Translators
(NAT-PT, [11]).

The difference to from the other scenarios is the use of IPv6 to IPv4
(and vice versa) address and protocol translation. Additionally, the
base NTLP must take care of this case for its own functionality support transport of
forwarding messages between in mixed IPv4 and IPv6
networks where some NSIS peers. peers provide translation.

+----+ +----+ //---\\ +----+ //---\\ +----+ +----+
NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR
+----+ +----+ \\---// +----+ \\---// +----+ +----+

private public public private
IPv4 IPv6

MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder

Figure 8: IPv4/v6 NAT with two private networks Private Networks

This scenario needs the same type of application level support as
described in Section 2.1.5 2.5, and so those the issues of relating to twice-NATs
apply here as well.

2.1.8

2.8 Multihomed Network with NAT

The previous chapters sub-sections sketched network topologies where NAT and several
NATs and/or Firewalls are ordered sequentially on the path. This chapter
section describes a multihomed scenario with two NATs placed on
alternative paths to the Internet. public network.

+----+
NI -------| MB |\
\ +----+ \ //---\\
\ -| |-- NR
\ \\---//
\ +----+ |
--| MB |-------+
+----+
private
private public

MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder

Figure 9: Multihomed Network with two Two NATs

Depending on the destination the or load balancing requirements, either
one or the other middlebox is used for the data flow. Which
middlebox is used depends on local policy or routing decisions.
NATFW NSLP must be able to handle this situation proper, properly, see
Section 3.2.2 3.3.2 for a more elaborated an expanded discussion of this topic with respect
to NATs.

2.2 Trust Relationship and Authorization

Trust relationships

3. Protocol Description

This section defines messages, objects, and authorization are very important protocol semantics for
the
protocol machinery. Trust and authorization are closely related to
each other in NATFW NSLP. Section 3.1 introduces the sense that a certain degree base constituent element
of trust is required to
authorize a particular action. For any action (e.g. "create/delete
/prolong policy rules" then authorization is very important due to session state, the nature of middleboxes.

It is particularly not surprising that different degrees of required
authorization in a QoS signaling environment and middlebox signaling
exist. As elaborated in [23], establishment of a financial
relationship is very important for QoS signaling, whereas for
middlebox signaling is not directly of interest. For middlebox
signaling a stronger or weaker degree of authorization might be
needed.

Different trust relationships that appear in middlebox signaling
environments are described in policy rule. Section 3.2 introduces the subsequent sections. Peer-to-peer
trust relationships are those, which are used in QoS signaling today
protocol and seem to be the simplest. However, there are reasons to believe
that this protocol behavior is not defined in Section 3.3.
Section 5 defines the only type syntax of trust relationship found in today's
networks.

2.2.1 Peer-to-Peer Trust Relationship

Starting with the simplest scenario it is assumed that neighboring
nodes trust each other. The required security association to
authenticate messages and objects.

3.1 Policy Rules

Policy rules, bounded to protect a signaling message is either available
(manual configuration) or dynamically established with the help of an
authentication and key exchange protocol. If nodes session, are located
closely together it is assumed that security association
establishment is easier than establishing it between far distant
node. It is, however, difficult to describe this relationship
generally due to the different usage scenarios and environments.
Authorization heavily depends on the participating entities but for
this scenario it is assumed that neighboring entities trust each
other (at least for the purpose building block of policy rule creation, maintenance
and deletion). Note that Figure 10 does not illustrate the trust
relationship between the end host and the access network.

+------------------------+ +-------------------------+
| | | |
| Network A | | Network B |
| | | |
| +---------+ +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | Trust | box 2 | | |
| | +---------+ Relationship +---------+ | |
| | | | | |
| | | | | |
| | | | | |
| | Trust | | Trust | |
| | Relationship | | Relationship | |
| | | | | |
| | | | | |
| | | | | |
| +--+---+ | | +--+---+ |
| | Host | | | | Host | |
| | A | | | | B | |
| +------+ | | +------+ |
+------------------------+ +-------------------------+

Figure 10: Peer-to-Peer Trust Relationship

2.2.2 Intra-Domain Trust Relationship

In larger corporations often more than one
middlebox is used to
protect different departments. In many cases devices considered in the entire enterprise
is controlled by a security department, which gives instructions to NATFW NSLP. For Firewalls the department administrators. In such a scenario
policy rule consists usually of a peer-to-peer
trust-relationship might be prevalent. Sometimes it might be
necessary to preserve authentication 5-tuple, source/destination
address, transport protocol, and authorization information
within the network. As a possible solution a centralized approach
could be used whereby source/destination port number, plus
an interaction between action like allow or deny. For NATs the individual
middleboxes and a central entity (for example a policy decision point
- PDP) takes place. As an alternative individual middleboxes could
exchange the authorization decision to another middlebox within the
same trust domain. Individual middleboxes within an administrative
domain should exploit their trust relationship instead rule consists of requesting
authentication
action 'translate this address to realms address pool' and authorization of further
mapping information, that might be in the signaling initiator again most simply case internal
IP address and
again. Thereby complex protocol interaction is avoided. This
provides both a performance improvement without a security
disadvantage since a single administrative domain can be seen as a
single entity. Figure 11 illustrates a network structure, which uses
a centralized entity.

+-----------------------------------------------------------+
| |
| Network A |
| |
| |
| +---------+ +---------+
| +----///--------+ Middle- +------///------++ Middle- +---
| | | box 2 | | box 2 |
| | +----+----+ +----+----+
| | | | |
| +----+----+ | | |
| | Middle- +--------+ +---------+ | |
| | box 1 | | | | |
| +----+----+ | | | |
| | | | | |
| - | | | |
| - | +----+-----+ | |
| | | | external IP address.

Policy | | |
| +--+---+ +-----------+ Decision +----------+ |
| | Host | | Point | |
| | A | +----------+ |
| +------+ |
+-----------------------------------------------------------+

Figure 11: Intra-domain Trust Relationship

2.2.3 End-to-Middle Trust Relationship rules are usually carried in one piece in signaling
applications. In some scenarios a simple peer-to-peer trust relationship between
participating nodes is not sufficient. Network B might require
additional authorization of NSIS the signaling message initiator. If
authentication and authorization information policy rule is not attached to the
initial signaling message then divided into the signaling message arriving at
Middlebox 2 would cause filter
specification, an error message to be created, which
indicates the allow or deny action, and additional authorization requirement. In many cases
the signaling message initiator information.
The filter specification is already aware of the additionally
required authorization before the signaling carried within NTLP's message exchange is
executed. Replay protection is a requirement for authentication to
the non-neighboring middlebox, which might be difficult to accomplish
without adding routing
information (MRI) and additional roundtrips to the signaling protocol (e.g.
by adding a challenge/response type of message exchange).

Figure 12 shows the slightly more complex trust relationships information is carried in this
scenario.

+----------------------+ +--------------------------+
| | | |
| Network A | | Network B |
| | | |
| | Trust | |
| | Relationship | |
| +---------+ +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | +-------+ box 2 | | |
| | +---------+ | +---------+ | |
| | | | | | |
| |Trust | | | | |
| |Relationship | | | | |
| | | | | Trust | |
| | | | | Relationship| |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| +--+---+ | | | +--+---+ |
| | Host +----///----+------+ | | Host | |
| | A | |Trust | | B | |
| +------+ |Relationship | +------+ |
+----------------------+ +--------------------------+

Figure 12: End-to-Middle Trust Relationship

3. Protocol Description

The protocol description section defines the NSIS NATFW NSLP with its
messages, objects, and the protocol semantics. Section 3.1
introduces the protocol and Section 3.3 defines NSLP's
objects. Additional information is, for example, the syntax lifetime of the
messages and objects. The protocol behavior is defined in Section
3.2.

3.1 a
policy rule or session.

3.2 Basic protocol overview

The NSIS Signaling Layer Protocol (NSLP) for NAT and FW traversal NATFW NSLP is carried over the NSIS Transport Layer Protocol
(NTLP) defined in [3]. NATFW NSLP messages are initiated by the NSIS
initiator (NI), handled by NSIS forwarders (NF) and finally processed
by the NSIS responder (NR). It is required that at least NI and NR
implement this NSLP, intermediate NF only implement this NSLP when
they provide middlebox functions. Forwarders NSIS forwarders that do not have
any NATFW NSLP functions just forward these messages; those forwarders implement NTLP and one or
more other NSLPs. packets when they have no
interest (which is expected to happen in most cases).

A Data Sender (DS) that is (DS), intending to send data to a Data Receiver (DR)
must first start its NATFW NSLP signaling. So In the next step, the NI
at the data sender (DS) starts NSLP signaling towards the address of
data receiver DR (see Figure 13). 10). Although the above NATFW NSLP
usage is expected to be the most common, this specification does not
prevent scenarios where the data sender and NI reside on different
hosts.

+-------+ +-------+ +-------+ +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR |
| |--->| NF1 |--->| NF2 |--->| |
+-------+ +-------+ +-------+ +-------+

========================================>
Data Traffic Direction

---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSIS forwarder 1
MB2 : Middlebox 2 and NSIS forwarder 2

Figure 13: 10: General NSIS signaling

The sequence of NSLP events is as follows:
o NSLP request messages are processed each time a NF with NATFW NSLP
support is passed. Those These nodes process the message, check local
policies for authorization and authentication, possibly create
policy rules, and forward the signaling message to the next NSIS
node. The request message is forwarded until it reaches the NSIS
responder.
o NSIS responders will check received messages and process those them if
applicable. NSIS responders generate response messages and sent send
them hop-by-hop back to the NI via the same chain of NFs. NFs
(traversal of the same NF chain is guaranteed through the
established reverse message routing state in the NTLP).
o The response message is processed at each NI forwarder NF implementing NATFW
NSLP. The
o Once the NI has received a successful response, the Data Sender
can start sending its data flow to the Data Receiver, when the
signaling was successful, meaning that NI has received a successful
response.

In general, Receiver.

NATFW NSLP signaling follows the data path from DS to DR.
This DR, this
enables communication between both hosts for scenarios with only
Firewalls on the data path or NATs on sender side. For scenarios
with NATs on the receiver side certain problems arise, see also
Section 2.

When Data receiver (DR) the NR and Data Sender (DS) the NI are located in different address realms and DR
the NR is behind a NAT, DS the NI cannot signal to DR the NR directly. DR The
NR is not reachable from DS the NIs and thus no NATFW signaling messages
can be sent to the DR's address. Therefore, DR the NR must first determine an
address at obtain
a NAT binding that is reachable for DS, for instance DR must
determine its public IP address. the NI. Once DR the NR has
determined a public
address IP address, it forwards this information to the
DS via a separate mechanism, which may be
application level signaling like SIP. protocol (such as SIP). This application level
signaling layer
signaling, out of scope of the NATFW NSLP, may involve third parties
that assist in exchanging this
information. This separate mechanism is out of scope of NATFW NSLP. these messages.

NATFW NSLP signaling supports this public address fixing with this
mechanism:
o First, DR scenario by using the RESERVE mode
of operation :
1. The NR determines a public address by signaling on the reverse
path (DR (NR towards DS) NI) and thus making itself available to other
hosts. This process of determining a public addresses is called
reservation. This way DR reserves publicly reachable addresses
and ports, but this address/port cannot be used by data traffic
at this point of time.
o Second, DS is signaling
2. The NI signals directly to DR the NR as DS NI would do if there is no NAT
in between, and so creating creates policy rules at middleboxes. Note, that
the reservation mode will make reservations only, which will be
"activated" by the signaling from DS NI towards DR. NR. The first mode
is detailed in the Section 3.2.2 3.3.2

The protocol works on a soft-state basis, meaning that that whatever state
is installed or reserved on a middlebox, it will expire, and thus be
de-installed/ forgotten after a certain period of time. To prevent
this, the NATFW nodes involved boxes will have to specifically request a
session extension. An explicit NATFW NSLP state deletion message capability
is also provided by the protocol.

Middleboxes should report back return an error in case of error, so a failure, such that
appropriate
measures and debugging actions can be performed. taken; this ability would allow debugging
and error recovery. Error messages could be sent upstream (for
errors related to received messages as well as asynchronous error
notification messages) towards the NI as well as downstream towards
the NR (case of asynchronous error notification messages).

The next sections define the NATFW NSLP message types and formats,
protocol operations, and policy rule operations.

3.2

3.3 Protocol Operations

This section defines the protocol operations, how to create sessions,
maintain them, and how to reserve addresses.

3.2.1 All the protocols
messages require C-mode handling by the NTLP and cannot be
piggybacked to D-mode NTLP messages used during the NTLP path
discovery/refresh phase. The protocol messages NTLP usage is
described in more details within Section 5.

The protocol uses six messages:
o CREATE: a request message used for creating, changing, refreshing
and deleting NATFW NSLP sessions.

o RESERVE-EXTERNAL-ADDRESS (REA): a request message used for
reserving an external address
o RESPONSE: used to response to CREATE, REA and QUERY messages with
Success or Error information
o QUERY: a request message used by authorized NATFW NEs for querying
NATFW on installed stated
o NOTIFY: an asynchronous message used by NATFW NEs to alert
upstream and/or downstream NATFW NEs about specific events (mainly
failures).
o TRIGGER: a message sent upstream to trigger CREATE messages to be
sent.
The following sections will present the semantics of these messages
by exhibiting their impact on the protocol state machine.

3.3.1 Creating Sessions

Allowing two hosts to exchange data even in the presence of
middleboxes is realized in the NATFW NSLP by the 'create session' 'CREATE ' request
message. The data sender generates a 'create session' CREATE message as defined in
Section 3.4.2 5.4.1 and handles hands it to the NTLP. The NTLP forwards the whole
message on the basis of the flow message routing information towards DR. the
NR. Each NSIS forwarders forwarder along the path that is implementing NATFW NSLP process
NSLP, processes the NSLP message, this message. Forwarding is done thus managed NSLP
hop-by-hop but may pass transparently through NSIS forwarders which
do not contain NATFW NSLP functionality and non-NSIS aware routers
between NSLP
hop-by-hop. Finally, hop waypoints. When the message is approaching DR, DR reaches the NR, the NR
can accept the request or reject it. DR NR generates a response to the request,
request and this response is transported hop by hop hop-by-hop towards (XXX terminology) DS. the NI.
NATFW NSLP forwarders may reject requests at any time. Figure 14 11
sketches the message flow between NI (DS), a NF (NAT), and NR (DR).

NI Private Network NF Public Internet NR
| | |
| Create CREATE | |
|----------------------------->| |
| | |
| Error (if necessary) | RESPONSE[Error](if necessary)| |
|<-----------------------------| Create CREATE |
| |--------------------------->|
| | |
| | Path Succeeded/Error RESPONSE[Success/Error] |
| Path Succeeded/Error RESPONSE[Success/Error] |<---------------------------|
|<-----------------------------| |
| | |
| | |

Figure 14: 11: Creation message flow

Processing

Since the CREATE message is used for several purposes within the
lifetime of 'create session' a session, there are several processing rules for NATFW
NEs when generating and receiving CREATE messages. The different
processing methods depend not only if the CREATE is used to create,
modify, refresh or delete a session but also on the node at which the
processing happens. For an initial CREATE message the processing of
CREATE messages is differently per different for every NSIS node: node type:
o NSLP initiator: NI only generate 'create session' generates initial CREATE messages and
handle
hands them over to the NTLP. After receiving a 'path succeeded' successful
response, the data path is configured and the NI DS can start
sending its data to NR. the DR. After receiving an 'error' response
message the NI MAY try to generate the 'create session' CREATE message again or
give up, depending on the error condition.
o NATFW NSLP forwarder: NSLP forwarders NFs receiving 'create session'
messages an initial CREATE message
MUST first check authentication and authorization before any
further processing is executed. The NF SHOULD check with its
local policies if he it can accept the desired policy rule given by the
combination of the NTLP's 'Message-Routing-Information' (MRI) [3]
(the flow routing information. Further description information) and the CREATE payload
(behavior to be enforced on the packet stream). The NSLP message
processing depends on the middlebox type:
* NAT: When the 'create session' initial CREATE message is received at the public
side a network external node is trying to open a NAT
binding. First, of the NAT, it looks for a reservation made in advance advance, by
means of 'reserve external address'
using a REA message Section 3.3.2 , that matches the
destination address/port of the flow routing information MRI provided by the NTLP. If there is
no reservation had been made in advance the NSLP SHOULD return
an error response message of type 'no reservation found' and
discard the request. If there is a reservation, NSLP stores
the data sender's address as part of the policy rule to be
loaded and forwards the message with the address set to the
internal (private in most cases) address of the next NSIS node.
When the 'create session' message initial CREATE message, for a new session, is received
at the private side the NAT binding is reserved, but not
activated. The NSLP message is forwarded to next hop with
source address set to the NAT's external address. address from the newly
reserved binding.
* Firewall: When the 'create session' initial CREATE message is received the NSLP
just remembers the requested policy rule, but does not install
any policy rule. Afterwards, the message is forwarded to the
next NSLP hop. There is a difference between requests from
trusted (authorized NIs) and un-trusted (un-authorized NIs);
requests from trusted NIs will be pre-authorized, whereas
requests from un-trusted NIs will not be pre-authorized. This
difference is required to speed-up the protocol operations as
well as for the proxy mode usage (please refer to Section 3.4
and [17]).
* Combined NAT and Firewall: Processing at combined Firewall and
NAT middleboxes is the same as in the NAT case. No policy
rules are installed. Implementations MUST take care about into account
the order of packet processing in the Firewall and NAT
functions within the device. Order
of functions is to This will be interpreted referred to as how packets experience
'order of functions' and is generally different depending on
whether the
treatment packet arrives at the external or internal side of those functions.
the middlebox.
o NSLP receiver: NRs receiving 'create session' initial CREATE messages MUST reply
with a 'path succeeded' 'success' (response object has success information)
RESPONSE message if they accept the CREATE request message.
Otherwise they SHOULD generate a RESPONSE message with an error message. Both
code. RESPONSE messages are sent back NSLP hop-by-hop towards NI. the
NI, independently of the response codes, either success or error.

Policy rules at middleboxes MUST be only installed upon receiving a
successful response of type 'path succeeded'. response. This is a countermeasure to several problems,
for instance, loaded example wastage of resources due to loading policy rules at
intermediate NF without reaching when the actual NR.

3.2.2 CREATE message does not reach the final the
NR for some reason.

3.3.2 Reserving External Addresses

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
data sender is itself behind a NAT and (covered by as described in Section 3.2.1). 3.3.1.
For scenarios where the data receiver is located behind a NAT and it
needs to receive data flows from outside its own network (see Figure
5) it the problem is more troublesome. NSIS signaling, as well as
subsequent data flows, are directed to a particular destination IP
address that must be known in advance and reachable.

Figure 15: 12: The Data Receiver behind NAT problem

Figure 15 12 describes a typical message communication in a peer-to-peer
networking environment whereby the two end points learn of each
others existence with the help of a third party (referred as
Application Server). The communication with between the application
server
and each of the two end points (data sender and data receivers) serves a
number of functions. As one of the most important functions it receiver)
enables the two end hosts to learn the IP address of each other. others IP address. The
approach described in this memo supports this peer-to-peer approach,
but is not limited to it.

Some sort of communication between the data sender/data receiver and
a third party is typically necessary (independently of NSIS). NSIS
signaling messages cannot be used to communicate application level
relevant end point identifiers (in the generic case at least) as a
replacement for the communication with the application server.

If the data receiver is behind a NAT then an NSIS signaling message
will be addressed to the IP address allocated at the NAT (if there
was one allocated). If no corresponding NSIS NAT Forwarding State at
NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the signaling
message will terminate at the NAT device (most likely without proper
response message). The signaling message transmitted by the data
sender cannot install the NAT binding or NSIS NAT Forwarding State
"on-the-fly" since this would assume that the data sender knows the
topology at the data receiver side (i.e. (i.e., the number and the
arrangement of the NAT and the private IP address(es) of the data
receiver). The primary goal of path-coupled middlebox communication
was not to force end hosts to have this type of topology knowledge.

Public Internet Private Address
Space
Edge
NI(DS) NAT NAT NR(DR)
NR+ NI+
| | | |
| | | |
| | | |
| | Reserve | Reserve |
| |<---------|<----------------| REA | REA |
| |<----------------------|<----------------------|
| | | Return | ext addr/Error
| |RESPONSE[Success/Error]|RESPONSE[Success/Error]|
| |--------->|---------------->| |---------------------->|---------------------->|
| | | |
| | | |

====================================================>

============================================================>
Data Traffic Direction

Figure 16: 13: Reservation message flow

Figure 16 13 shows the message flow for reserving an external address/
port at a NAT. In this case the roles of the different NSIS entities
are:
o The actual data receiver (DR) for the anticipated data traffic is the
NSIS initiator (NI+) for the
'reserved external address' RESERVE-EXTERNAL-ADDRESS (REA)
message, but becomes the NSIS responder (NR) for 'create session' messages following later. CREATE
messages.
o The actual data sender (DS) will be the NSIS initiator (NI) for
later 'create session' CREATE messages and may be the NSIS target of the signaling
(NR+).
o The actual target of the 'reserved external address' REA message may be an arbitrary address NR+. address,
the Opportunistic Address (OA) that would force the message to get
intercepted by the far outmost NAT in the network. .

The NI+ agent (could be on the data receiver DR starts to signal an 'reserve external address'
message into or on any other host
within he private network) sends a the "wrong direction". By "wrong" we refer REA message targeted to the usual
behavior of path-coupled signaling where the data sender starts
signaling
Opportunistic Address (OA). The OA selection for this message is
discussed in order to tackle with routing asymmetry. Section 3.8. The data
receiver would typically return signaling messages to message routing for the data sender REA message is
in the reverse direction by utilizing state created at nodes along
the path (i.e. to reverse route the normal message routing used for
path-coupled signaling messages). In case of where the signaling is sent downstream (as
opposed to upstream in this case). When establishing NAT bindings
(and NSIS NAT Forwarding State) the direction does not matter since
the data path is modified through route pinning due to the external
NAT address. Subsequent NSIS messages (and also data traffic) will
travel through the same NAT boxes.

The signaling target address selection for this message is
discussed in Section 3.2.10.

The REA signaling message creates NSIS NAT Forwarding State at any
intermediate NSIS NAT node(s). node(s) encountered. Furthermore it has to be
ensured that the edge NAT device is discovered as part of this
process. The end host cannot be assumed to know this device -
instead the NAT box itself is assumed to know that it has such a capability. is located at
the outer perimeter of the private network. Forwarding of the 'reserve external address' REA '
message beyond this entity is not necessary, and should be prohibited
as it provides information on the capabilities of internal hosts capabilities. hosts.

The edge NAT device is responding responds to the REA message with a 'return external address' RESPONSE
message containing a success object carrying the public reachable IP
address/port number.

Processing of 'reserve external address' REA messages is differently per specific to the NSIS node: node type:
o NSLP initiator: NI+ only generate 'reserve external address' REA messages and should never
receive them.
o NSLP forwarder: NSLP forwarders receiving 'reserve external
address' REA messages MUST first
check authentication and authorization before any further
processing is executed. The NF SHOULD check with its local
policies if he it can accept the desired policy rule given by NTLP's flow
message routing information. information (MRI). Further processing depends on
the middlebox type:
* NAT: NATs check whether the message is received at the public
external (public in most cases) address or at the private internal
(private) address. If received at the public internal address a NF
MAY generate a RESPONSE message with an error message of type 'requested
external address 'REA
received from outside'. If received at the private internal address,
an IP address/port is reserved. In the case it is an edge-NAT,
the NSLP message is not forwarded anymore and a
response of type 'return RESPONSE
message with the external address' address and port information is
generated. If it is not an edge-NAT, the NSLP message is
forwarded further. further with the translated IP address/port (if
required by the NI+).
* Firewall: Firewalls MUST not change their configuration upon a
'reserve external address'
REA message. They simply MUST forward the message and MUST
keep NTLP state. Firewalls that are configured as
edge-Firewalls (XXX, do definition!) MAY return an error of type 'no NAT here'.

* Combined NAT and Firewall: Processing at combined Firewall and
NAT middleboxes is the same as in the NAT case.
o NSLP receiver: This type of message should never be received by
any NR and it SHOULD be discarded silently.

Processing of 'return a RESPONSE message with an external address' messages address object is differently per
different for every NSIS node: node type:
o NSLP initiator: Upon receiving a 'return external address' RESPONSE message with an
external address object, the NI+ can use the obtained IP address and port number
pairs carried for further application signaling.
o NSLP forwarder: NFs simply forward this message as long as they
keep state for the requested reservation.
o NSIS responder: This type of message should never be received by
any
an NR and it SHOULD be discarded silently.

3.2.3 Reserving External Addresses and Create Session

Some migration scenarios need specialized support to cope with the
situation where the receiving side is running NSIS only. End-to-end
signaling is going to fail without NSIS support at both sides. For
this the 'create-reverse' signaling mode is supported. In this case,
a DR can signal towards the DS like in the 'reserve external address'
message scenario. The message is forwarded until it reaches the
edge-NAT and retrieves a public IP address and port number. Unlike
in the 'reserve external address' no 'return external address'
response message is created, the forwarding
o Edge-NATs: This type of the request message
stops and a 'create session' message is generated should never be received by the edge-NAT.
This request message is sent towards DR with DS as source address any
Edge-NAT and
follows the regular processing orders as 'create session' messages
do. The exact definition of this mode is to it SHOULD be done.

3.2.4 Prolonging Sessions discarded silently.

3.3.3 NATFW Session refresh

NATFW NSLP sessions are maintained on a soft-state base. After a
certain timeout timeout, sessions and corresponding policy rules are removed
automatically by the middlebox, if they are not refreshed by refreshed. The
protocol uses a
prolong session message. NI is sending prolong CREATE message towards NR
and to refresh sessions. Even if used for
refresh purposes the CREATE message requires to be responded back, to
allow the intermediate NFs to propose a refresh period that would
align to their local policies. The NI sends CREATE messages destined
for the NR. Upon reception by each NSIS forwarder maintaining forwarder, the state for the
given session ID
extends is extended by the lifetime session refresh period, a period
of the session. time calculated based on a proposed refresh message period.
Extending lifetime of a session is calculated as current local time
plus lifetime. proposed lifetime value (session refresh period). Section 3.2.7 is
defining 3.5
defines the process of calculating lifetimes in detail.

NI Public Internet NAT Private address NR
| | space |
| Prolong CREATE[lifetime > 0] | |
|----------------------------->| |
| | |
| Error RESPONSE[Error] (if necessary) needed) | |
|<-----------------------------| Prolong CREATE[lifetime > 0] |
| |--------------------------->|
| | |
| | Error (if necessary) RESPONSE[Success/Error] |
| Error (if necessary) RESPONSE[Success/Error] |<---------------------------|
|<-----------------------------| |
| | |
| | |

Figure 17: Prolongation message flow 14: State Refresh Message Flow

Processing of 'prolong session' session refresh CREATE messages is differently per different for every
NSIS
node: node type:
o NSLP initiator: NI can generate 'prolong session' session refresh CREATE messages
before the session times out. The rate at which the refresh
CREATE messages are sent and their relation to the session state
lifetime are further discussed in Section 3.5. The message
routing information and the extended flow information object MUST
be set equal to the values of the initial CREATE request message.
o NSLP forwarder: NSLP forwarders receiving 'prolong session' session refresh messages
MUST first check authentication and authorization before any
further processing is executed. The NF SHOULD check with its
local policies if he it can accept the desired lifetime extension for
the session referred by the session ID. Processing of this
message is independent of the middlebox type.
o NSLP responder: NIs NRs accepting this prolong session refresh CREATE message
generate a
'path succeeded' message.

3.2.5 RESPONSE message with response object set to success.

3.3.4 Deleting Sessions

NATFW NSLP sessions may be deleted at any time. NSLP initiators can
trigger this deletion via the 'delete session' message, by using a CREATE messages with a lifetime
value set to 0, as shown in Figure 17. 15.

Figure 18: 15: Delete message flow

NSLP nodes receiving this message MUST delete the session
immediately. Corresponding policy rules to this particular session
MUST be deleted immediately, too. This message is forwarded until it
reaches the final NR. The 'delete' CREATE request message with a lifetime
value of 0, does not generate any response, neither positive nor
negative, since there is no NSIS state left at the nodes along the
path.

3.2.6 Authorization

Authorization

3.3.5 Reporting Asynchronous Events

NATFW NSLP forwarders and security issues NATFW NSLP responders must have the ability
to report asynchronous events to other NATFW NSLP nodes, especially
reporting back to the NATFW NSLP initiator. Such asynchronous events
may be premature session termination, changes in local polices, or
any other reason that indicates change of the NATFW NSLP session
state. Currently, only asynchronous session termination is defined
as event, but other events may be defined in later versions of this
memo.

NFs and NRs may generate NOTIFY messages upon asynchronous events,
with a response object indicating the reason of the event. There are currently discussed
two suggested mode of operations:
1. NOTIFY messages are sent hop-by-hop upstream towards NI. Those
NOTIFY messages may be sent downstream towards NR, if generated
by a NF, if needed. TBD: Should there be a way to configure
whether NOTIFY messages are sent downstream, too?
2. During session creation, via CREATE or REA, NIs may insert a
special 'notify address' object into the NSLP message, indicating
a node's address that should be notified about this event. TBD:
When this object is used, is it desired to send the NOTIFY to
both, NI and the other node? Sending to both could end up in one
asynchronous event generating three messages: NOTIFY to NI
(upstream), NOTIFY to NR (downstream), and NOTIFY to notify
address.
Processing is different for every NATFW NSLP node type and only
defined for asynchronous session termination events:

o NSLP initiator: NIs receiving NOTIFY messages MUST first check for
authentication and authorization. After successfully doing so,
NIs MUST remove the NSLP session as indicated by the NOTIFY
message. NIs MUST NOT generate NOTIFY messages.
o NSLP forwarder: NFs receiving NOTIFY messages MUST first check for
authentication and authorization. After successfully doing so,
NFs MUST remove the NSLP session and corresponding policy rules
immediately and MUST forward the NOTIFY message. NFs occurring an
asynchronous event generate NOTIFY messages and set the response
object to 'session termination' code. NOTIFY messages are sent
hop-by-hop upstream towards NI (This depends on above mentioned
design choice).
o NSLP responder: NRs may generate NOTIFY messages. NRs receiving
NOTIFY messages MUST first check for authentication and
authorization. After successfully doing so, NRs MUST remove the
NSLP session immediately. NRs occurring an asynchronous event
generate NOTIFY messages and set the response object to 'session
termination' code. NOTIFY messages are sent hop-by-hop upstream
towards NI (This depends on above mentioned design choice).

3.3.6 QUERY capabilities within the NATFW NSLP protocol

The NATFW NSLP provides query capabilities that could be used by:
o A session owner to track the session state, this would be used for
diagnosis when no data packets were received and the policy rule
was supposed to be created on the NATFW NFs.
o A superuser to track user activities, detect misbehaving users and
blocking them from using the NATFW NSLP on the NATFW NFs within
the network. When doing so it is recommended that the QUERY
message be scoped to the limits of the administrative domain.

The QUERY message could be used to query the following information:
o Session information: session id, flow source, destination and
status of the state listed in best status to worst status: up,
high traffic (used to detect DOS attack or unexpected traffic
rate), pending, down. The status of the policy rule indicate
sufficient diagnosis information, in case more diagnosis
information is required it could be provided by the NATFW NF logs.
Session status is only provided by an NF if no session status was
provided in the QUERY message or the NF's session status is worst
than the one provided by the queried upstream NEs. The Session
information could be retrieved by sending a QUERY against a
specific session id, a flow source and destination or user
identifier with session id or flow source and destination.
o User identifiers: the query would be used by a super-user to track
activities of a suspected user, the query would return all the
suspected user active sessions

QUERY message processing is different document for every NATFW NSLP node type:
o NSLP initiator: NIs only generate QUERY messages, but never with
session status information, in case received QUERY messages MUST
be discarded.
o NSLP forwarder: NFs receiving QUERY messages MUST first check for
authentication and authorization. After successfully doing so,
NFs will behave differently depending on the QUERY.
* if the QUERY is about a specific session: if it contains a
session status the NF compares it to the current local session
status; if no session status is provided in the QUERY message
the NF will insert its own session status in the QUERY message.
If the current local session status is worst, it will
incorporate its own session status field in the QUERY message.
Every NF will provide the flow description in case it was not
inside the QUERY.
* if the QUERY is about a specific user, the NF will gather all
the user's sessions and provide a list of them.
Once the message processing is done, if the message was not scoped
then NF will forward the QUERY message to the next downstream
node.
o NSLP responder: NRs (any node being the destination of the
message)receiving QUERY messages MUST first check for
authentication and authorization. After successfully doing so,
NRs must process the message as the NFs and respond with a
RESPONSE message to the NI. The RESPONSE message will travel
along the established reverse path Message Routing State.

Responses to QUERY messages are processed differently for every NATFW
NSLP node type:
o NSLP initiator: NIs receiving RESPONSEs to QUERY messages MUST
first check for authentication and authorization. After
successfully doing so, the objects within the RESPONSE messages
are provided up to the application layers and the session state
remains as it was unless the application triggers NATFW NSLP state
changes.
o NSLP forwarder: NFs receiving RESPONSEs to QUERY messages MUST
first check for authentication and authorization. After
successfully doing so, NFs forward the message upstream without
any interpretation.
o NSLP responder: if an NR received a RESPONSE to QUERY message it
MUST discard it.

3.3.7 QUERY Message semantics

From a semantics perspective, the QUERY messages may require the
following information incorporated within the messages:
o Session ID
o User ID
o Flow source (address and port) and destination (address and port),
in case the flow doesn't use a transport protocol a protocol
number would be included used with another identifier (SPI for IPsec)
QUERY responses should provide the following information:
o List of active sessions associated to a user
o Related information to a session: session ID, flow description and
policy rule state information

3.4 NATFW NSLP proxy mode of operation

3.4.1 Reserving External Addresses and triggering Create messages

Some migration scenarios need specialized support to cope with cases
where only the receiving side is running NSIS. End-to-end signaling
is going to fail without NSIS support at both data sender and data
receiver, unless the NATFW NSLP also gives the NR the ability to
install sessions. In this case, a NR can signal towards the
Opportunistic Address as is done in the standard REA message handling
scenario Section 3.3.2. The message is forwarded until it reaches
the edge-NAT and retrieves a public IP address and port number.
Unlike the standard REA message handling case no RESPONSE message is
sent. Instead a CREATE message is generated by the edge-NAT. This
CREATE request message is sent towards NR with DS as source address
(if the source address is known, otherwise the edge NAT address is
used as source address) and thereafter follows the regular processing
rules as for CREATE messages sent by the NI.

DS Public Internet NAT Private address NR
No NI | space
| | REA[CREATE] |
| |<------------------------- |
| | CREATE |
| | ------------------------> |
| | RESPONSE[Error/Success] |
| | ---------------------- > |
| | |
| | |

Figure 16: REA Triggering Sending of CREATE Message

This behavior requires within the REA message an indication to the
edge NAT if either a RESPONSE message or a CREATE message should be
used. In addition when the CREATE message is requested (as opposed
to a RESPONSE message) the REA message the data sender address. A
slight variant, shown in Figure 17 , could also be handled by
requesting within the REA message that a RESPONSE message needs to be
sent on the existing pinned down path as well as a CREATE message
on a newly discovered path between the Edge NAT and the NR. This
variant would allow the handling of asymmetric routes, which could go
through internal firewalls, within the local network.

DS Public Internet NAT Private address NR
No NI | space
| | REA[CREATE, DISC] |
| |<------------------------- |
| | RESPONSE[Error/Success] |
| | ---------------------- > |
| | CREATE |
| | ------------------------> |
| | RESPONSE[Error/Success] |
| | ---------------------- > |
| | |
| | |

Figure 17: REA Triggering Sending of CREATE Message on Separate
Reverse Path

In case a CREATE message is received from the far end NI and relates
the installed session, that CREATE message would have precedence over
the previous CREATE. The CREATE sent by the NI would allow to have a
more granular policy rule as only the data sender could send data
whereas in the REA triggered CREATE message any data source can send
packets to the data receiver. The edge NAT is not aware of the
applications context for which the CREATE messages were required.
Hence it is up to the NR to inform the Edge NAT if there was a
possibility to reduce the number of accepted data sources to the real
data sender, as well as to inform the Edge NAT to refresh the
established session.

For that purpose the NR will send TRIGGER messages, to the edge NAT
that responded to the REA message. These messages are sent upon
reception, from the user application, of further information on the
Data Sender (either explicit information or implied information such
as data sender address data reception address and same for the
transport port). The TRIGGER messages would be sent periodically to
the Edge NAT that responded to the REA. The TRIGGER messages would
be sent until either a CREATE message is received from the far-end or
when the user application no longer needs the NSIS session. Figure
18 shows how TRIGGER messages would be used after reaching consensus (
[20]).

3.2.7 the message
sequences of Figure 16 or Figure 17. In case a CREATE message is
received from the far end NI and relates to the installed session,
that CREATE message would have precedence over the triggered CREATE
messages. TRIGGER messages do not require to be responded back with
a RESPONSE message on the existing established reverse path. The
benefits of using REA triggering a CREATE and then using the TRIGGER
messages are that an end-host doesnt need to know if the far-end
support the NSIS protocol.

Foo.com Public Internet Bar.com
DS NAT Firewall NR
No NI | | TRIGGER[DSinfo]
TRIGGER[DSinfo]<-------------|
<-------------| |
|CREATE |
|----------->|CREATE |
| |-------------->|
| | RESPONSE[SUCCESS]
| | <-------------|
RESPONSE[SUCCESS] |
|<-----------| |
Refresh period expiry |
or updates to Data Sender information
| |
| | TRIGGER[DSinfo]
TRIGGER[DSinfo]<-------------|
<-------------| |
|CREATE |
|----------->|CREATE |
| |-------------->|
| | RESPONSE[SUCCESS]
| | <-------------|
RESPONSE[SUCCESS] |
|<-----------| |

Figure 18: TRIGGER message usage

3.4.2 Using CREATE messages to Trigger Reverse Path CREATE Messages

In certain network deployments, where a NATFW NE might not be
available on the end-host (Figure 19) or the NSIS messages are
scoped (Figure 20) implicitly or explicitly with a scoping object, a
CREATE message could be used to trigger another CREATE message sent
by the last NF terminating the CREATE message. There are two options
for this mode:
o The returning CREATE message could follow the established reverse
path using GIMPS routing state ([3],Section 3.4.2.1)
o Trigger the GIMPS layer to discover the reverse path, which would
require that the first CREATE message provides the message target
address (Section 3.4.2.2).

3.4.2.1 CREATE Responses Sent on Previously Pinned Down Reverse Path

Public NI/NR
Host foo.com FW Internet FW bar.com Host
foo | | bar
| | | CREATE[CREATE, NoNR] |
| | |<------------------------- |
| | | |
| | CREATE[CREATE] | |
| ,|<-----------------+ |
| ' | | |
| ' | CREATE[] | |
| `'|--------------- ->| |
| | | CREATE[] |
| | | ------------------------->|
| | | RESPONSE[Success/Error] |
| | | <------------------------ |
| |RESPONSE[Success/Error]| |
| | <----------------|

Figure 19: CREATE triggering CREATE Message Sending with no Scoping
and using Existing Reverse Path State

In Figure 19, the first CREATE indicates that if the message can not
reach its destination, a CREATE message should be sent back to the NI
by the last reached NATFW NE. As in Section 3.4.1 this mode of
operation requires that the CREATE message indicate the type of
required response which in this case is a CREATE message. However
this response type is subject to a condition: only if the NR can not
respond. This conditional behavior requires a specific flag to
indicate it. In this example, the NI does not require that the last
NATFW NF responds via a different reverse path than that already
pinned down.

Public NI/NR
Host foo.com FW Internet FW bar.com Host
foo | | bar
| | | CREATE[CREATE,Scope] |
| | |<------------------------- |
| | | |
| | | CREATE/RESPONSE[Error] |
| | | ------------------------->|
| | | RESPONSE[Success/Error] |
| | | <------------------------ |

Figure 20: CREATE Triggering CREATE Message Sending with Scoping and
using Existing Reverse Path State

In Figure 20, the first CREATE indicates that once the end of the
scope is reached, the last NATFW NSLP will respond with a CREATE
message (if the first CREATE request was successful). As in Section
3.4.1, this mode of operation requires that the CREATE message
indicate the type of response required which in this case is a CREATE
message. As the CREATE needs to terminate at a scope end, the scope
need to be provided within the CREATE message. In this example, the
NI doesnt require that the last NATFW NF responds via a different
reverse path than the already pinned down.

3.4.2.2 CREATE Responses Sent on Separately Established Reverse Path

In certain network topologies, where several NATFW NSLP are deployed
on alternate paths, it is better to minimize asymmetric route issues
that could occur when sending the CREATE message on the existing
pinned down reverse path.

Foo.com Public Internet Bar.com
2-RESPONSE1
/-------------|---------------------
/ --> FW1-NF --------------------- \
V / 1-CREATE1[CREATE,DISC,NoNR]| \ \
Host Foo/ | | NF3-NF Host Bar
NI/NR ^ | | |^
\ \ | 3-CREATE2 | ||
\ \--- FW2-NF --------------------------|
\----/ \--------------------------
| 4-RESPONSE2 |

Figure 21: CREATE Triggering Sending of CREATE Message with Scoping
and Using Separate Reverse path

To minimize the asymmetric route problem, the node responding with a
CREATE message would request the NTLP to rediscover the reverse path.
A RESPONSE message would be sent on the existing pinned down reverse
path (Step 2 in Figure 21), and a CREATE would be sent on a newly
discovered reverse path (Step 3 in Figure 21). Upon reception of the
latter message, the initiating NI will respond with a RESPONSE
message (Step 4 in Figure 21) as is done for the normal CREATE
message operations (Section 3.3.1). The CREATE message would need to
indicate to the last NATFW NF that a CREATE must be sent on a
separately discovered path and that a RESPONSE message needs to be
sent on the established pinned down reverse path. The new CREATE
message need to indicate to the NI that this session is bound to the
previous session. In addition the first message should indicate that
the last available NATFW NF will need to terminate the message and
start the above procedures (similar to Figure 19). The model could
also be applied when a scope is used, instead of terminating on the
last NATFW NF, the message will terminate on the end of the scope.

3.5 Calculation of Lifetimes Session Lifetime

NATFW NSLP sessions, and the corresponding policy rules possibly which may
have been installed, are maintained via soft-state. soft-state mechanism. Each
session is assigned a lifetime and they are the session is kept alive as long
as the lifetime is valid. After the expiration of the lifetime lifetime,
sessions and policy rules MUST be removed automatically and resources
bound to them should be freed as well. Session lifetime is kept at
every NATFW NSLP node. The NSLP forwarders and NSLP responder are
not responsible for triggering lifetime prolongination extension refresh messages
(see Section 3.2.4), 3.3.3): this is the task of the NSIS initiator.

NSIS initiator MUST choose a session lifetime (expressed in seconds)
value before they can sent sending any message (except 'delete session' messages)
to other NSLP nodes. This The session lifetime value should consider is calculated based
on:
o The number of lost refresh messages to cope with
o The end to end delay between the NI and NR
o Network vulnerability due to session hijacking ([21]). Session
hijacking is made easier when the NI does not remove explicitly
the session.
o The user application's needs, i.e., duration data exchange duration, in terms of
seconds, minutes or hours, hours and networking needs, i.e., values needs. This duration is
modeled as M x R, with R the message refresh period (in seconds)
and M a multiple of R.

As opposed to the NTLP Message Routing state [3] lifetime, the NSLP
session lifetime doesnt require to have a small value since the NSLP
state refresh is not handling routing changes but security related
concerns. [14] provides a good algorithm to calculate the session
lifetime as well as how to avoid refresh message synchronization
within the network. [14] recommends:
1. The refresh message timer to be randomly set to a value in the
range less than 30 seconds [0.5R, 1.5R].
2. To avoid premature loss of state, L (with L being the session
lifetime) must satisfy L >= (K + 0.5)*1.5*R, where K is a small
integer. Then in the worst case, K-1 successive messages may not be useful.
lost without state being deleted. Currently K = 3 is suggested
as the default. However, it may be necessary to set a larger K
value for hops with high loss rate. Other algorithms could be
used to define the relation between the session lifetime and the
refresh message period, the provided algorithm is only listed as
an example.

This requested lifetime value is placed in the 'lifetime object' 'lifetime' object of
the NSLP message and messages are forwarded to the next NATFW NSLP
node.

NATFW NSLP forwarders NFs processing the request message along the path MAY lower change
the request requested lifetime given to fit their needs and/or local policy. NATFW forwarders If an
NF changes the lifetime value it must also indicate the corresponding
refresh message period. NFs MUST NOT increase the lifetime value; value
unless the lifetime value was below their acceptable range; they MAY
reject the requested lifetime immediately and MUST generate an error
response message of type 'lifetime too big' upon rejection. The NSLP
request message is forwarded until it reaches the NSLP responder.
NSLP responder MAY reject the requested lifetime value and MUST
generate an error response message of type 'lifetime too big' upon
rejection. The NSLP responder MAY also lower the requested lifetime
as well
to a granted lifetime. an acceptable value (based on its local policies). NSLP
responders generate their appropriate response message for the
received request message, sets the lifetime value to the above
granted lifetime and sends the message back hop-by-hop towards NSLP
initiator.

Each NSLP forwarder processes the response message, reads and stores
the granted lifetime value. The forwarders SHOULD accept the granted
lifetime, as long as the value is equal or lower than within the requested
lifetime. tolerable lifetime range
defined in their local policies. They MAY reject the lifetime and
generate a 'lifetime not acceptable' error response message. Figure 19
22 shows the procedure with an example, where an initiator requests
60 minutes seconds lifetime in
'create session' the CREATE message and the lifetime is
shortened along the path by the forwarder to 20 minutes seconds and by the
responder to 5 minutes. 15 seconds.

+-------+ CREATE(lt=60m) CREATE(lt=60s) +-----------+ CREATE(lt=20m) CREATE(lt=20s) +--------+
| |---------------->| NSLP |---------------->| |
| NI | | | | NR |
| |<----------------| forwarder |<----------------| |
+-------+ OK(lt=5m) RESPONSE(lt=15s +-----------+ OK(lt=5m) RESPONSE(lt=15s +--------+
MRR=3s) MRR=3s)

lt = lifetime
CREATE
MRR = 'create session' message
OK = 'path succeeded' message Message Refresh Rate

Figure 19: 22: Lifetime Calculation Example

3.2.8

3.6 Middlebox Resource

TBD: This section needs to be done and should describe how to map
flow routing information to middlebox policy rules. Further, this
section should clarify wildcarding. XXX

3.2.9

3.7 De-Multiplexing at NATs

Section 3.2.2 3.3.2 describes how NSIS nodes behind NATs can obtain a
public
publicly reachable IP address and port number at a NAT. The
information IP address/port number can then be transmitted via a
signaling protocol and/or third party to the communication partner
that would like to send data towards. towards hosts behind the NAT. However,
NSIS signaling flows are sent towards the address of the NAT at which
this particular IP address and port number is allocated. The NATFW
NSLP forwarder at this NAT needs to know how the incoming NSLP
requests are related to reserved addresses, meaning how to
de-multiplex incoming requests.

Two options for

The de-multiplexing incoming NSLP requests are:
1. Based on flow routing information, like protocol number and TCP
port numbers.
2. Based on NSIS session IDs.

Approach 2) would require that both NSIS ends, initiator and
responder, use the same session ID in NSIS signaling. Since session
IDs are usually generated randomly, application level signaling would
have to be adapted to carry NSIS session IDs used during reservation
to the other end (the NSIS initiator sending the 'create session'
message). This approach SHOULD NOT be used.

Approach 1) method uses information stored at NATs (like (such as
mapping of public IP address to private, transport protocol, port
numbers) and information given by NTLP's flow routing information to de-multiplex
NSIS messages. This approach is RECOMMENDED.

3.2.10 information.

3.8 Selecting Destination IP addresses Opportunistic Addresses for REA

Request messages of type 'reserve external address'

REA do need, as any other message type as well, a final destination
IP address to reach. But as many applications do not provide a
destination IP address at in the first place, there is a need to choose
a destination address for
the 'reserve external address' REA messages. This destination address can
be the final target, but for the mentioned type of application, applications which do not provide an
upfront address, the destination address can has to be arbitrary. Taking chosen
independently. Choosing the "correct" 'correct' destination IP address might may be
difficult and it is possible there is no right
answer. 'right answer'. [19] shows
choices for SIP and this section provides some hints about choosing a
good destination IP address in general. address.

1. Public IP address of the data sender:
* Assumption:
+ The data receiver already learned the IP address of the
data sender (e.g. (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. different,
this could happen in a network deployment such as in Figure
12. As a consequence it might be necessary to advertise a
new (and different) external IP address with SIP 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 (allocated at NAT B):
* Assumption:
+ The data receiver already learned his externally visible IP
address (e.g. (e.g., based on the third party communication).
* Problems:
+ Communication with a third party is required.
3. IP address at of the Application Server:
* Assumption:
+ An application server (or a different third party) is
available.
* Problems:
+ If the NSIS signaling message is not terminated at the NAT
of the local network then an NSIS unaware application
server might discard the message.
+ Routing might not be optimal since the route between a) the
data receiver and the application server b) the data
receiver and the data sender might be different.

3.3

4. NATFW NSLP Messages NTLP Requirements

The NATFW NSLP requires the following capabilities from the NTLP:
o Ability to detect that the NSIS Responder does not support NATFW
NSLP. This capability is key to launching the proxy mode behavior
as described in Section 3.4 and [17].
o Detection of NATs and their support of the NSIS NATFW NSLP. If
the NTLP discovers that the NSIS host is behind an NSIS aware NAT,
the NR will send REA messages to the opportunistic address. If
the NTLP discovers that the NSIS host is behind a NAT that does
not support NSIS then the NSIS host will need to use a separate
NAT traversal mechanism.
o Message origin authentication and message integrity protection
o Transport of information used for correlation purposes between the
NSIS protocol suite and user application layers. This requirement
allows NSLP NATFW to check that the message was solicited by prior
application message exchanges before an NTLP messaging association
is established between an NR and the upstream NF.
o Detection of routing changes
o Protection against malicious announcement of fake path changes,
this is needed to mitigate a threat discussed in section 7 of [21]

5. NATFW NSLP Message Components

A NATFW NSLP message consists of a NSLP header and one or more
objects following the header. The NSLP header is common for all
NSLPs and objects are Type-Length-Value (TLV) encoded using big
endian (network ordered) binary data representations. Header and
objects are bound aligned to 32 bits bit boundaries and objects object lengths that do are
not fall into multiples of 32 bits boundaries must be padded to the next higher 32 bits. bit
multiple.

The whole NSLP message is carried in as payload of a NTLP message.

Note that the notation 0x is used to indicate hexadecimal numbers.

3.3.1

5.1 NSLP Header

The NSLP header is common to all NSLPs and is the first part of all
NSLP messages. It contains two fields, the NSLP message type and a
reserved field. The total length is 32 bits. The layout of the NSLP
header is defined by Figure 20. 23.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSLP message type | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 20: 23: Common NSLP header

The reserved field MUST be set to zero in the NATFW NSLP header
before sending and MUST be ignored during processing of the header.
Note that other NSLPs use this field as a flag field.

3.3.2

5.2 NSLP message types

The message types identify requests and responses. Defined messages
types for requests are:
o 0x0101 : create CREATE
o 0x0102 : reserve RESERVE-EXTERNAL-ADDRESS(REA)
o 0x0103 : reserve-create QUERY
o 0x0104 : prolong NOTIFY
o 0x0105 : delete RESPONSE
o 0x0106 : TRIGGER
Defined message types for responses are:
o 0x0201 : path_succeed
o 0x0202 : path_deleted
o 0x0203 : ret_ext_addr are (TBD):

o 0x0204 : error

3.3.3 TBD

5.3 NSLP Objects

NATFW NSLP objects use a common header format defined by Figure 21. 24.
Objects are Type-Length-Value (TLV) encoded using big endian (network
ordered) binary data representations. The object header contains two
fields, the NSLP object type and the object length. Its total length
is 32 bits.

Note that all objects MUST be padded always to 32 bits.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSLP object type | NSLP object length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 21: 24: Common NSLP object header

The length is the total length of the object without the object
header. The unit is a word, consisting of 4 bytes. The particular
values of type and length for each NSLP object are listed in the
subsequent chapters sections that define the NSLP objects.

3.3.3.1 Session ID Object

The session ID object carries an identifier for the session

TBD: Processing of unknown options is currently subject to
discussions within the
signaled flow. The only field working group. It is proposed to extend the session ID of 16 bytes length.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 16 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// 16 bytes session id //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 22: Session ID
NSLP object header with some bits that indicate treatment of unknown
options. The session ID is generated in random way by compatibility bits (CP) are coded into two 2 bits and
determine the NSIS initiator.

3.3.3.2 action to take upon receiving an unknown option. The
applied behavior based on the CP bits is:
00 - Abort processing and report error
01 - Ignore object and do not forward
10 - Ignore object and do forward
All other combinations MUST NOT be set and objects carrying these
other CP bit combinations MUST discarded.

5.3.1 Session Lifetime Object

The session lifetime object carries the requested or granted lifetime
of a NATFW NSLP session measured in seconds. The object consists
only of the 4 bytes lifetime field.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 OID_NATFW_LT | 4 bytes 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NATFW NSLP session lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 23: 25: Lifetime object

3.3.3.3

5.3.2 External Address Object

The external address objects can be included in ret_ext_addr
responses RESPONSE messages
(Section 3.4.9) 5.4.4) only. It contains the external IP address and port
number allocated at the edge-NAT. Note that this address/
port may be either reserved or reserve-create. Two fields are defined, the
external IP address, and the external port number. For IPv4 the
object with value 0x0010 OID_NATFW_IPv4 is defined. It has a length of 8
bytes and is shown in Figure 24. 26.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0010 OID_NATFW_IPv4 | 8 bytes 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 24: 26: External Address Object for IPv4 addresses

For IPv6 the object with value 0x0011 OID_NATFW_IPv6 is defined. It has a
length of 20 bytes and is shown in Figure 25. 27.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0011 OID_NATFW_IPv6 | 20 bytes 0x0005 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 25: 27: External Address Object for IPv6 addresses

3.3.3.4

5.3.3 Extended Flow Information Object

In general, flow information is kept at the NTLP level during
signaling. The message routing information of the NTLP carries all
necessary information. Nevertheless, some additional information may
be required for NSLP operations. The 'extended flow information'
object carries this additional information about number of action to be taken
on the installed policy rules and subsequent port numbers
that should be allocated at middleboxes. of policy rules.

These fields are defined for the policy rule object:
o Rule action: This field indicates the action for the policy rule
to be activated. Allow values are 'allow' (0x01) and 'deny'
(0x02)
o Number of ports: This field gives the number of ports that should
be allocated beginnig beginning at the port given in NTLP's flow message routing
information.

Figure 26: 28: Extended Flow Information

3.3.3.5 Error

5.3.4 Response Code Object

The error

This object carries the reason response code, which may be indications for an error. It has only one
field,
either a successful request or failed request depending on the error code, and is 2 bytes long. value
of the 'response code' field.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 OID_NATFW_RESPONSE | 4 bytes 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| error response code | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 27: Error 29: Response Code Object

TBD: Define error clases response classes, success codes and define the error coded. codes.
Possible error classes are:
o Policy rule errors
o Authentication and Authorization errors
o NAT
Currently in this memo defined errors:
o lifetime too big
o lifetime not acceptable
o no NAT here
o no reservation found
o requested external address from outside

3.4

5.3.5 Response Type Object

The response type object indicates that a specific response is needed
to the NSLP responder.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OID_NATFW_RESP_TYPE | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|S|L| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 30: Response Type Object

If the C bit is set to 1 the required response is a CREATE request
message, otherwise a RESPONSE message. If the S bit is set to 1 the
scoping object MUST be used. If the L bit is set to 1 the CREATE
request message is ONLY sent if the message does not reach its
target, even though the if the C bit is set.

The source IP address is optional and may be set to a zero IP address
or to a real IP address. If set to a real address, NATFW NSLP uses
this address as assumed data sender's address.

5.3.6 Message Sequence Number Object

XXX Text is missing.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OID_NATFW_MSN | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 31: Message Sequence Number Object

5.3.7 Scoping Object

The scoping object determines the allowed scope for the particular
message.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OID_NATFW_SCOPE | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message scope |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 32: Scoping Object

These 'message scope' values are allowed: region, single hop.

5.3.8 Bound Session ID Object

This object carries a session ID and is used for QUERY messages only.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OID_NATFW_BID | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bound session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 33: Bound Session ID Object

5.3.9 Notify Target Object

This object carries the IP address of the notify target node. TBD:
Details on this, like IPv6 version etc.

0 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OID_NATFW_NOTIFY_TGT | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| notify nodes' IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 34: Notify Target Object

5.4 Message Formats

This section defines the content of each NATFW NSLP message type.
The message types are defined in Section 3.3.2. 5.2. First, the request
messages are defined with their respective objects to be included in
the message. Second, the response messages are defined with their
respective objects to be included.

Basically, each message is constructed of NSLP header and one or more
NSLP objects. The order of objects is not defined, meaning that
objects may occur in any sequence. Objects are marked either with
mandatory [M] or optional [O]. Where [M] implies that this
particular object MUST be included within the message and where [O]
implies that this particular object is OPTIONAL within the message.

Each section elaborates the required settings and parameters to be
set by the NSLP at for the NTLP, for instance, how the flow message routing
information is set.

3.4.1 Policy Rules

Policy rules are the building block of middlebox devices considered
in the NATFW NSLP. For Firewalls the policy rule consists usually of
a 5-tuple, source/destination address, transport protocol, and
source/destination port number, plus an action like allow or deny.
Other actions are available depending on the implementation of the
Firewall, but NATFW NSLP uses only allow action, since a default to
deny policy at the middlebox is assumed. For NATs the policy rule
consists of action 'map this another address realm' and further
mapping information, that might be in the most simply case internal
IP address and external IP address.

Policy rules are usually carried in one piece in signaling
applications. In NSIS the policy rule is divided into the filter
specification, an implicit allow action, and additional information.
The filter specification is carried within NTLP's flow routing
information and additional information is carried in NSLP's objects.
Additional information is for instance the lifetime of a policy rule
or session.

3.4.2 Create Session (CRS)

5.4.1 CREATE

The create session CREATE request message is used to create NSLP sessions and at middleboxes to
create policy rules.

The create session Furthermore, CREATE messages are used to
refresh sessions and to delete them.

The CREATE message carries these objects:
o Session ID Lifetime object [M]
o Lifetime Extended flow information object [M]
o Message sequence number object [M]
o Respose type object [O]
o Scoping object[O]
o Notify target [O]

The flow message routing information in the NTLP MUST be set to DS as
source address and DR as destination address. All other parameters
MUST be set according the required policy rule.

3.4.3 Reserve External Address (REA) When the CREATE
messages is received by a node operating in proxy mode Section 3.4
the NI address is the NR address from the message that triggered the
CREATE to be sent, if that address is not valid (wildcarded) the
proxy node address is used instead. The reserve external NR address would be the NI's
address provided by the message routing information of the message
that triggered the CREATE.

5.4.2 RESERVE-EXTERNAL-ADDRESS (REA)

The RESERVE-EXTERNAL-ADDRESS (REA) request message is used to lookup target
a NAT and to allocated an external IP address and possibly port
number, so that the initiator of the REA request has a public
reachable IP address/port number.

The REA request message carries these objects:
o Session ID Lifetime object [M]
o Lifetime Message sequence number object [M]
o Response type object [M]
o Scoping object [M]
o Extended flow information [O]

The REA message needs special NTLP treatment. First of all, REA
messages travel the wrong way, from the DR towards DS. Second, the
DS' address used during the signaling may be not the actual DS (see
Section 3.2.10). 3.8). Therefore, the NTLP flow routing information is set to
DR as initiator and DS as responders, a special field is given in the
NTLP: The signaling destination.

3.4.4 Reserve-Create (REC)

XXX This is a proposal for a new message to support the reservation
and simultaneous/implicit create message generation.

5.4.3 TRIGGER

The reserve-create message carries these objects:
o Session ID object
o Lifetime object

NTLP issues: TBD.

3.4.5 Prolong Session (PLS)

The prolong TRIGGER request message is used to prolong (extend) the lifetime
of a NATFW NSLP and policy rules at middleboxes. in proxy mode operation. XXX

The prolong session TRIGGER request message carries these objects:
o Session ID Lifetime object [M]
o Lifetime Message sequence number object

The [M]
o Response type object [M]
o Scoping object [M]
o Extended flow routing information in the NTLP MUST be set [O]

XXX

5.4.4 RESPONSE

RESPONSE messages are responses to DS as source
address CREATE, REA, and DR as destination address. All other parameters MUST be
set according the required policy rule.

3.4.6 Delete Session (DLS) QUERY messages.

The delete request message is used to delete NATFW NSLP sessions.

The delete session RESPONSE message carries these objects:
o Session ID Lifetime object

The flow routing information in the NTLP MUST be set to DS as source [M]
o Response object [M]
o External address and DR as destination address. All other parameters MUST be
set according the required policy rule.

3.4.7 Path Succeeded (PS)

The path succeeded response object ([M] for success responses to REA)

This message is routed upstream.

5.4.5 QUERY

QUERY messages are used to acknowledge a
successful create and prolong. for diagnosis purposes.

The path succeeded QUERY message carries these objects:
o Session ID Response object [M]
o lifetime Message sequence number object [M]
o Scoping object [M]
o Bound session ID [O]

This message is routed on the reverse path.

3.4.8 Path Deleted (PD) downstream.

5.4.6 NOTIFY

The path deleted response message NOTIFY messages is used to acknowledge a successful
delete request message.

The report asynchronous events happening
along the signaled path deleted to other NATFW NSLP nodes.

The NOTIFY message carries this object:
o Session ID Response code object

This message is routed on the reverse path.

3.4.9 Return External Address (RA) with NOTIFY code [M].

The return external address response message is sent back as a
positive result of reserve external address request. It contains routing information in the
reserved external IP NTLP MUST be set to DS as
source address and port number.

The path succeeded message carries these objects:
o Session ID object
o Lifetime object
o External address object (either IPv4 or IPv6 type)

This message DR as destination address, forwarding direction is routed on
upstream (Note that Section 5.4.6 discusses some design options
regarding the reverse path.

3.4.10 Error Response (ER)

The error response message is sent back by any NSIS node involved in transport). The session id object must be set
to the corresponding session that occurs an error condition.

The error message carries these objects:
o Session ID object
o Error object

This message is routed on the reverse path.

4. effected by this asynchronous
event.

6. NSIS NAT and Firewall transitions issues Transition Issues

NSIS NAT and Firewall transition issues are premature and will be
addressed in a separate draft (see [17]). An update of this section
will be based on consensus.

7. Security Considerations

Security is of major concern particularly in case of Firewall
traversal. Generic Security threats for NSIS signaling in general have been discussed
described in [6] and they are applicable here as well. It to this document. [21]
extends this threat investigtion by considering NATFW NSLP specific
threats. Based on the identified threats a list of security
requirements have been defined. As an important requirement for
security protection it is necessary to provide
proper signaling message
o data origin authentication
o replay protection
o integrity protection and proper authorization.
o optionally confidentiality protection
between neighboring NATFW NSLP nodes.

To consider the aspect of authentication and key exchange we aim to
reuse the mechanisms provided in [3] between neighboring nodes.

Some scenarios also demand security between non-neighboring nodes but
this aspect is still in discussions. A possible commonality with the
QoS NSLP has been identified and CMS [24] has been investigated as a
possible candidate for security protection between non-neighboring
entities. Note that this aspect also includes some more
sophisticated user authentication mechanisms, as described in [23].
With regard to end-to-end security the NAT need for a binding between an
NSIS signaling session and application layer session has been
described in Section 3.3 of [6].

In order to solicit feedback from the IETF community on some hard
security problems for path-coupled NATFW signaling a more detailed
description in [22] is available.

The NATFW NSLP is a protocol which may involve a number of NSIS nodes
and is, as such, not a two-party protocol. This fact requires more
thoughts about scenarios, trust relationships and authorization
mechanisms. This section lists a few scenarios relevant for security
and illustrates possible trust reationships which have an impact to
authorization. More problematic scenarios are described in Appendix
A.

7.1 Trust Relationship and Authorization

Trust relationships and authorization are very important for the
protocol machinery. Trust and authorization are closely related to
each other in the sense that a certain degree of trust is required to
authorize a particular action. For any action (e.g. "create/delete
/prolong policy rules), authorization is very important due to the
nature of middleboxes.

Different types of trust relationships may affect different
categories of middleboxes. As explained in [26], establishment of a
financial relationship is typically very important for QoS signaling,
whereas financial relationships are less directly of interest for
NATFW middlebox signaling. It is therefore not particularly
surprising that there are differences in the nature and level of
authorization likely to be co-located with required in a Firewall QoS signaling environment
and in NATFW middlebox signaling. For NATFW middlebox signaling, a
stronger or weaker degree of authorization might
therefore require packet filters to be changed needed.
Typically NATFW signaling requires authorization to configure and
traverse particular nodes or networks which may derive indirectly
from a financial relationship. This is a more 'absolute' situation
either the usage is allowed or not, and the effect on both network
owner and network user is 'binary'.

Different trust relationships that appear in order middlebox signaling
environments are described in the subsequent sub-sections. QoS
signaling today uses peer-to-peer trust relationships. They are
simplest kind of trust relationships. However, there are reasons to allow
believe that this is not the only type of trust relationship found in
today's networks.

7.1.1 Peer-to-Peer Trust Relationship

Starting with the simplest scenario, it is assumed that neighboring
nodes trust each other. The required security association to
authenticate and to protect a signaling message to process is either available
(after manual configuration), or has been dynamically established
with the help of an authentication and key exchange protocol. If
nodes are located closely together, it is assumed that security
association establishment is easier than establishing it between
distant nodes. It is, however, difficult to traverse. This section aims describe this
relationship generally due to
raise some items the different usage scenarios and
environments. Authorization heavily depends on the participating
entities, but for further discussion this scenario, it is assumed that neighboring
entities trust each other (at least for the purpose of policy rule
creation, maintenance, and illustrates deletion). Note that Figure 35 does not
illustrate the problems trust relationship between the authors faced when creating end host and the access
network.

Figure 35: Peer-to-Peer Trust Relationship

7.1.2 Intra-Domain Trust Relationship

In larger corporations, often more than one middlebox is used to
protect or serve different departments. In many cases, the entire
enterprise is controlled by a security solution department, which gives
instructions to the department administrators. In such a scenario, a
peer-to-peer trust-relationship might be prevalent. Sometimes it
might be necessary to preserve authentication and authorization
information within the network. As a possible solution, a
centralized approach could be used, whereby an interaction between
the individual middleboxes and a central entity (for example a policy
decision point - PDP) takes place. As an alternative, individual
middleboxes could exchange the authorization decision with another
middlebox within the same trust domain. Individual middleboxes
within an administrative domain should exploit their trust
relationship instead of requesting authentication and authorization
of the signaling initiator again and again. Thereby complex protocol
interactions are avoided. This provides both a performance
improvement without a security disadvantage since a single
administrative domain can be seen as a single entity. Figure 36
illustrates a network structure which uses a centralized entity.

Figure 36: Intra-domain Trust Relationship

7.1.3 End-to-Middle Trust Relationship

In some scenarios, a simple peer-to-peer trust relationship between
participating nodes is not sufficient. Network B might require
additional authorization of the signaling message initiator. If
authentication and authorization information is not attached to the
initial signaling message then the signaling message arriving at
Middlebox 2 would result in an error message being created, which
indicates the additional authorization requirement. In many cases
the signaling message initiator is already aware of the additionally
required authorization before the signaling message exchange is
executed. Replay protection is a requirement for authentication to
the NAT/
Firewall NSLP.

Installing non-neighboring middlebox, which might be difficult to accomplish
without adding additional roundtrips to the signaling protocol (e.g.,
by adding a challenge/response type of message exchange).

Figure 37 shows the slightly more complex trust relationships in this
scenario.

Figure 37: End-to-Middle Trust Relationship

Finally it should be noted that installing packet filters provides
some security, but also has some weaknesses, which heavily depend on
the type of packet filter installed. A packet filter cannot prevent
an adversary to inject traffic (due to the IP spoofing capabilities).
This type of attack might not be particular helpful if the packet
filter is a standard 5 tuple which is very restrictive. If packet
filter installation, however, allows specifying a rule, which
restricts only the source IP address, then IP spoofing allows
transmitting traffic to an arbitrary address. NSIS aims to provide
path-coupled signaling and therefore an adversary is somewhat
restricted in the location from which attacks can be performed. Some
trust is therefore assumed from nodes and networks along the path.

Without doubts there is a dependency on the security provided by the
NTLP. Section Appendix A and Section 2.2 motivates some trust
relationship and authorization scenarios. These scenarios deserve a
discussion since some of them (particularly one with a missing
network-to-network trust relationship) is different to what is know
from QoS signaling. To address some of these trust relationships and
authorization issues requires security mechanisms between
non-neighboring nodes at the NSLP layer. For the group of authors it
seems that peer-to-peer and end-to-middle security needs to be
provided. An NSLP security mechanism between neighboring

8. Open Issues

The NATFW NSLP peers
might be necessary if security mechanisms at the NTLP do not provide
adequate protection mechanisms. This issue is, however, still in
discussion.

As has a design goal it seems to be favorable to reuse existing
mechanisms to the best extend possible. In most cases it is
necessary to carry the objects for end-to-middle as NSLP payloads
since the presence series of NATs might prevent direct communication. Three
security mechanisms have to be considered in more detail in a future
version related documents discussing several
other aspects of this document: CMS [21] and Identity Representation for
RSVP [15]. The authors believe that CMS more suitable (since it
provides much more functionality). The details deserve further
discussion and implementation experience.

With regard to signal between two end hosts even though the receiver
is behind a NAT this proposal suggests creating state by the data
receiver first. This allows NSIS signaling messages to traverse a
NAT at the receiver side (due to the established state at this NAT
box) and simplifies path-coupled NATFW signaling, including security handling. To achieve this behavior it
is required to install NSIS NTLP and NSLP state. Furthermore, it is
envisioned to associate the two
[22], migration (i.e., traversal of nsis unaware NATs) [17],
intra-realm signaling parts (one part from the
data sender to the NAT [18], and the other part from the NAT to the data
receiver) inter-working with the help of the Session Identifier. As such, the
discussion in [15] is relevant for this document.

Another interesting property of this protocol proposal is to prevent
Denial SIP [19].
Summaries of Service attacks against NAT boxes whereby an adversary
allocates NAT bindings with the help of data packets. Since outcomes from these
data packets do not provide any type of authentication and are not
authorized any adversary is able documents may be added,
depending on WG feedback, to mount such an attack. This
attack has been mentioned at several places in the literature
already and is particularly harmful if no NAPT functionality is used
(i.e. if a new NAT binding consumes one IP address of a pool later version of IP
addresses). Using the protocol described in this document additional
security can be achieved and draft.

A more fairness detailed list of open issue can be provided.

6. Open Issues

At least the following issues require further discussion:
o Option processing rules in presence of unknown options.
o Terminology w.r.t. the term wrong way.
o NTLP: New object and semantics for REA.
o NTLP and NATFW NSLP interaction
o List of NTLP transport modes per NSLP message
o Routing Change detection
o Query message, definition of semantics needed
o Is there a need for a QoS NSLP RSN like object/mechanism in NATFW
NSLP?
o Add IANA considerations section.
o re-work security considerations.
o Query message: Syntax and semantics.
o Add text about asynchronous messages.
o Anycast address for REA.
o Check common formats with QoS NSLP
o Change length field of objects to long words as unit?
o Variable length for session id?
o Meaning of 0 as session ID.
o Extended flow object: Needs refinement

7. found at: http://
nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-natfw-issues/index

9. Contributors

A number of individuals have contributed to this draft. Since it was
not possible to list them all in the authors section, it was decided
to split it and move Marcus Brunner and Henning Schulzrinne into the
contributors section. Separating into two groups was done without
treating any one of them better (or worse) than others.

10. References

8.1

10.1 Normative References

[1] Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT
draft-ietf-nsis-fw-05.txt, October 2003.

[2] Brunner et al., M., "Requirements for Signaling Protocols",
DRAFT draft-ietf-nsis-req-09.txt, October 2003.

[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", DRAFT
draft-ietf-nsis-ntlp-00.txt,
draft-ietf-nsis-ntlp-02.txt, October 2003.

[4] Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
Quality-of-Service signaling", DRAFT
draft-ietf-nsis-qos-nslp-03.txt, May 2004.

[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.

[6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
DRAFT draft-ietf-nsis-threats-01.txt, January 2003.

[7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002.

8.2

10.2 Informative References

[8] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations, RFC 2663", August 1999.

[9] Srisuresh, P. and M. Holdrege, "Network Address Translator
(NAT)Terminology and Considerations, RFC 2663".

[10] Srisuresh, P. and E. Egevang, "Traditional IP Network Address
Translator (Traditional NAT), RFC 3022", January 2001.

[11] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT), RFC 2766", February 2000.

[12] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002.

[13] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan,
"DNS extensions to Network Address Translators (DNS_ALG)", RFC
2694, September 1999.

[14] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", September 1997.

[15] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC
3182, October 2001.

[16] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and
X. Fu, "Security Implications of the Session Identifier", June
2003.

[17] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H.
Tschofenig, "NAT/Firewall NSLP Migration Considerations", DRAFT
draft-aoun-nsis-nslp-natfw-migration-01.txt, Februar 2004.

[18] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H.
Tschofenig, "NATFirewall NSLP Intra-realm considerations",
DRAFT draft-aoun-nsis-nslp-natfw-intrarealm-00.txt, Februar
2004.

[19] Martin, M., Brunner, M. and M. Stiemerling, "SIP NSIS
Interactions for NAT/Firewall Traversal", DRAFT
draft-martin-nsis-nslp-natfw-sip-00.txt, Februar 2004.

[20] Martin, M., Brunner, M., Stiemerling, M., Girao, J. and C.
Aoun, "A NSIS NAT/Firewall NSLP Security Infrastructure", DRAFT
draft-martin-nsis-nslp-natfw-security-01.txt, Februar February 2004.

[21] Fessi, A., Brunner, M., Stiemerling, M., Thiruvengadam, S.,
Tschofenig, H. and C. Aoun, "Security Threats for the NAT/
Firewall NSLP", DRAFT draft-fessi-nsis-natfw-threats-01.txt,
July 2004.

[22] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security
Problems", draft-tschofenig-nsis-natfw-security-problems-00.txt
(work in progress), July 2004.

[23] Tschofenig, H. and J. Kross, "Extended QoS Authorization for
the QoS NSLP", draft-tschofenig-nsis-qos-ext-authz-00.txt (work
in progress), July 2004.

[24] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.

[22]

[25] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K.
Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt,
November 2002.

[23]

[26] Tschofenig, H., Buechli, M., Van den Bosch, S. and H.
Schulzrinne, "NSIS Authentication, Authorization and Accounting
Issues", March 2003.

[24]

[27] Amini, L. and H. Schulzrinne, "Observations from router-level
internet traces", DIMACS Workshop on Internet and WWW
Measurement, Mapping and Modelin Jersey) , Februar 2002.

[25]

[28] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4
Traversal of VPN Gateways",
draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in
progress), April 2003.

[26]

[29] Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin,
"Problem Space and Usage Scenarios for PANA",
draft-ietf-pana-usage-scenarios-06 (work in progress), April
2003.

[27]

[30] Shore, M., "The TIST (Topology-Insensitive Service Traversal)
Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002.

[28]

[31] Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT
Traversal Client for CASP", DRAFT
draft-tschofenig-nsis-casp-midcom-01.txt, March 2003.

[29]

[32] 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.

[30]

[33] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H. and H.
Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and
Framework", DRAFT draft-brunner-nsis-midcom-ps-00.txt, June
2003.

[31]

[34] Ford, B., Srisuresh, P. and D. Kegel, "Peer-to-Peer(P2P)
communication Network Address Translators(NAT)", DRAFT
draft-ford-midcom-p2p-02.txt, March 2004.

[32]

[35] Rosenberg et al, J., "STUN - Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators (NATs)", RFC
3489, March 2003.

[33]

[36] Rekhter et al, Y., "Address Allocation for Private Internets",
RFC 1918, February 1996.

[37] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-04 (work in progress), February
2004.

[38] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
Waldbusser, "Terminology for Policy-Based Management", RFC
3198, November 2001.

Authors' Addresses

Martin Stiemerling
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany

Phone: +49 (0) 6221 905 11 13
EMail: stiemerling@netlab.nec.de
URI:

Hannes Tschoefenig Tschofenig
Siemens AG
Otto-Hahn-Ring 6
Munich 81739
Germany

Phone:
EMail: Hannes.Tschofenig@siemens.com
URI:

Miquel Martin
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany

Phone: +49 (0) 6221 905 11 16
EMail: miquel.martin@netlab.nec.de
URI:

Cedric Aoun
Nortel Networks
France

EMail: cedric.aoun@nortelnetworks.com

Appendix A. Problems and Challenges

This section describes a number of problems that have to be addressed
for NSIS NAT/Firewall. Issues presented here are subject to further
discussions. These issues might be also of relevance to other NSLP
protocols.

A.1 Missing Network-to-Network Trust Relationship

Peer-to-peer trust relationship, as shown in Figure 10, 35, is a very
convenient assumption that allows simplified signaling message
processing. However, it might not always be applicable, especially
between two arbitrary access networks (over a core network where
signaling messages are not interpreted). Possibly peer-to-peer trust
relationship does not exist because of the large number of networks
and the unwillingness of administrators to have other network
operators to create holes in their Firewalls without proper
authorization. Hence in the following scenario we assume a somewhat
different message processing and show three possible approaches to
tackle the problem. None of these three approaches is without
drawbacks or constraining assumptions.

+----------------------+ +--------------------------+
| | | |
| Network A | | Network B |
| | | |
| +---------+ Missing +---------+ |
| +-///-+ Middle- | Trust | Middle- +-///-+ |
| | | box 1 | Relation- | box 2 | | |
| | +---------+ ship +---------+ | |
| | | or | | |
| | | Authorization| | |
| | | | | |
| | Trust | | Trust | |
| | Relationship | | Relationship | |
| | | | | |
| | | | | |
| | | | | |
| +--+---+ | | +--+---+ |
| | Host | | | | Host | |
| | A | | | | B | |
| +------+ | | +------+ |
+----------------------+ +--------------------------+

Figure 28: 38: Missing Network-to-Network Trust Relationship

Figure 28 38 illustrates a problem whereby an external node is not
allowed to manipulate (create, delete, query, etc.) packet filters at
a Firewall. Opening pinholes is only allowed for internal nodes or
with a certain authorization permission. Hence the solution
alternatives in Section 3.2.2 3.3.2 focus on establishing the necessary
trust with cooperation of internal nodes.

A.2 Relationship with routing

The data path is following the "normal" routes. The NAT/FW devices
along the data path are those providing the service. In this case
the service is something like "open a pinhole" or even more general
"allow for connectivity between two communication partners". The
benefit of using path-coupled signaling is that the NSIS NATFW NSLP
does not need to determine what middleboxes or in what order the data
flow will go through.

Creating NAT bindings modifies the path of data packets between two
end points. Without NATs involved, packets flow from endhost to
endhost following the path given by the routing. With NATs involved,
this end-to-end flow is not directly possible, because of separated
address realms. Thus, data packets flow towards the external IP
address at a NAT (external IP address may be a public IP address).
Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with
routing - instead they only follow the path of the data packets.

A.3 Affected Parts of the Network

NATs and Firewalls are usually located at the edge of the network,
whereby other signaling applications affect all nodes along the path.
One typical example is QoS signaling where all networks along the
path must provide QoS in order to achieve true end-to-end QoS. In
the NAT/Firewall case, only some of the domains/nodes are affected
(typically access networks), whereas most parts of the networks and
nodes are unaffected (e.g. (e.g., the core network).

This fact raises some questions. Should an NSIS NTLP node intercept
every signaling message independently of the upper layer signaling
application or should it be possible to make the discovery procedure
more intelligent to skip nodes. These questions are also related to
the question whether NSIS NAT/FW should be combined with other NSIS
signaling applications.

A.4 NSIS backward compatibility with NSIS unaware NAT and Firewalls

Backward compatibility is a key for NSIS deployments, as such the
NSIS protocol suite should be sufficiently robust to allow traversal
of none NSIS aware routers (QoS gates, Firewalls, NATs, etc ).

NSIS NATFW NSLP's backward compatibility issues are different than
the NSIS QoS NSLP backward compatibility issues, where an NSIS
unaware QoS gate will simply forward the QoS NSLP message. An NSIS
unaware Firewall rejects NSIS messages, since Firewalls typically
implement the policy "default to deny".

The NSIS backward compatibility support on none NSIS aware Firewall
would typically consist of configuring a static policy rule that
allows the forwarding of the NSIS protocol messages (either protocol
type if raw transport mode is used or transport port number in case a
transport protocol is used).

For NATs backward compatibility is more problematic since signaling
messages are forwarded (at least in one direction), but with a
changed IP address and changed port numbers. The content of the NSIS
signaling message is, however, unchanged. This can lead to
unexpected results, both due to embedded unchanged local scoped
addresses and none NSIS aware Firewalls configured with specific
policy rules allowing forwarding of the NSIS protocol (case of
transport protocols are used for the NTLP). NSIS unaware NATs must
be detected to maintain a well-known deterministic mode of operation
for all the involved NSIS entities. Such a "legacy" NAT detection
procedure can be done during the NSIS discover procedure itself.

Based on experience it was discovered that routers unaware of the
Router Alert IP option [RFC 2113] discarded packets, this is
certainly a problem for NSIS signaling.

A.5 Authentication and Authorization

For both types of middleboxes, Firewall and NAT security is a strong
requirement. Authentication and authorization means must be
provided.

For NATFW signaling applications it is partially not possible to do
authentication and authorization based on IP addresses. Since NATs
change IP addresses, such an address based authentication and
authorization scheme would fail.

A.6 Directional Properties

There two directional properties that need to be addressed by the
NATFW NSLP:
o Directionality of the data
o Directionality of NSLP signaling

Both properties are relevant to NATFW NSLP aware NATs and Firewalls.

With regards to NSLP signaling directionality: As stated in the
previous sections, the authentication and authorization of NSLP
signaling messages received from hosts within the same trust domain
(typically from hosts located within the security perimeter delimited
by Firewalls) is normally simpler than received messages sent by
hosts located in different trust domains.

The way NSIS signaling messages enters the NSIS entity of a Firewall
(see Figure 2) might be important, because different policies might
apply for authentication and admission control.

Hosts deployed within the secured network perimeter delimited by a
Firewall, are protected from hosts deployed outside the secured
network perimeter, hence by nature the Firewall has more restrictions
on flows triggered from hosts deployed outside the security
perimeter.

A.7 Addressing

A more general problem of NATs is the addressing of the end-point.
NSIS signaling message have to be addressed to the other end host to
follow data packets subsequently sent. Therefore, a public IP
address of the receiver has to be known prior to sending an NSIS
message. When NSIS signaling messages contain IP addresses of the
sender and the receiver in the signaling message payloads, then an
NSIS entity must modify them. This is one of the cases, where a NSIS
aware NATs is also helpful for other types of signaling applications
e.g.
e.g., QoS signaling.

A.8 NTLP/NSLP NAT Support

It must be possible for NSIS NATs along the path to change NTLP and/
or NSLP message payloads, which carry IP address and port
information. This functionality includes the support of providing
mid-session and mid-path modification of these payloads. As a
consequence these payloads must not be reordered, integrity protected
and/or encrypted in a non peer-to-peer fashion (e.g. (e.g., end-to-middle,
end-to-end protection). Ideally these mutable payloads must be
marked (e.g. (e.g., a protected flag) to assist NATs in their effort of
adjusting these payloads.

A.9 Combining Middlebox and QoS signaling

In many cases, middlebox and QoS signaling has to be combined at
least logically. Hence, it was suggested to combine them into a
single signaling message or to tie them together with the help of
some sort of data connection identifier, later on referred as Session
ID. This, however, has some disadvantages such as:

- NAT/FW NSLP signaling affects a much small number of NSIS nodes
along the path (for example compared to the QoS signaling).

- NAT/FW signaling might show different signaling patterns (e.g. (e.g.,
required end-to-middle communication).

- The refresh interval is likely to be different.

- The number of error cases increase as different signaling
applications are combined into a single message. The combination of
error cases has to be considered.

A.10 Inability to know the scenario

In Section 2.1 2 a number of different scenarios are presented. Data
receiver and sender may be located behind zero, one, or more
Firewalls and NATs. Depending on the scenario, different signaling
approaches have to be taken. For instance, data receiver with no
NAT and Firewall can receive any sort of data and signaling without
any further action. Data receivers behind a NAT must first obtain a
public IP address before any signaling can happen. The scenario
might even change over time with moving networks, ad-hoc networks or
with mobility.

NSIS signaling must assume the worst case and cannot put
responsibility to the user to know which scenario is currently
applicable. As a result, it might be necessary to perform a
"discovery" periodically such that the NSIS entity at the end host
has enough information to decide which scenario is currently
applicable. This additional messaging, which might not be necessary
in all cases, requires additional performance, bandwidth and adds
complexity. Additional, information by the user can provide
information to assist this "discovery" process, but cannot replace
it.

Appendix B. Acknowledgments

We would like to acknowledge acknowledge: Vishal Sankhla and Joao Girao for their
input to this draft. draft; and Reinaldo Penno for his comments on the
initial version of the document. Furthermore, we would like thank
Elwyn Davis for his valuable help and input.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither nor does it represent that it has
made any independent effort to identify any such rights. Information
on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation RFC documents can be
found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors implementers or users of this
specification can be obtained from the IETF Secretariat. on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which that may cover technology that may be required to practice implement
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose at
ietf-ipr@ietf.org.

Disclaimer of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. Validity

This document and the information contained herein is are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.