NSIS Working Group C. Aoun Internet-Draft Nortel Networks Expires:April 19,August 16, 2004 M. Brunner M. Stiemerling M. Martin NEC H. Tschofenig SiemensOctober 20, 2003 NATFirewallFebruary 16, 2004 NAT/Firewall NSLPmigration and intra-realm communication considerations draft-aoun-nsis-nslp-natfw-migration-00Migration Considerations draft-aoun-nsis-nslp-natfw-migration-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onApril 19,August 16, 2004. Copyright Notice Copyright (C) The Internet Society(2003).(2004). All Rights Reserved. Abstract This document discussesNAT/FWmigrationto support theissues towards NSIS NAT/FW NSLPas well as intra-realm communications considerations.enabled NATs and Firewalls. The document will serve as input to the NSIS NATFW NSLP document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . .3 2. NSIS Responder address selection for intra realm communications optimization . . . . . . . . .. . 3 2. Terminology . . . .4 2.1 Potential solutions to the problem. . . . . . . . . . . .5 2.1.1 Intra realm solution protocol operation impacts. . . . .6 2.1.2 Intra realm solution application protocols impacts. . . .74 3.NATFW NSLP migration analysis . . . . . . . . . . . . . . 8 3.1 Global scoped address determination withNSIS unawareNATs . . . . . . . . .NAT Traversal . . . . . . . . . . . . . . . . . .10 3.2 Analysis of unilateral5 4. Unilateral NSIS signaling . . . . . . . . . .13 3.3 Co-existence with existing NAT traversal mechanisms . . . 19 3.4 NSIS protocol traversal of NSIS Unaware Firewalls and NATs . . . . . . . . . . . . . .. . . . . . . .. . . . . 20 3.4.1 NSIS protocol traversal of8 5. NSISUnaware Firewalls . . .unaware Firewall Traversal .20 3.4.1.1 NSIS protocol traversal of a mix of NSIS Unaware Firewalls and NSIS aware NATs. . . . . . . . . . . . . .20 3.4.1.2 NSIS protocol traversal of NSIS Unaware NATs . . . . . . . 21 4.13 6. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . .22 5. Security Considerations . . . . . . . . . . . . . . .. .23 6. IANA14 7. Security Considerations . . . . . . . . . . . . . . . . . . .24 7.15 8. OpenIssuesissues . . . . . . . . . . . . . . . . . . . . . . . .25. 16 Normative References . . . . . . . . . . . . . . . . . . .26. . 17 Informative References . . . . . . . . . . . . . . . . . .27. . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . .28. . 18 Intellectual Property and Copyright Statements . . . . . .30. . 20 1. IntroductionWhether interim NAT and Firewall traversal mechanisms will already be deployed in networks or not, it is important to understand NSIS NATFW NSLP co-existence with non-NSIS aware NATs and Firewalls until their migration to NSIS would have been accomplished.The overall NSISNATFW NSLP responder provides the NSIS NATFW NSLP Initiator with its address, in some cases the NSIS responder may have several addresses: a (or several) global scoped address and its locally scoped address(es). Which address does it provide to the NSIS initiator? This document will cover both the above issues and serve as input toprotocol suite (including theNSISNATFWNSLP main document. 2. NSIS Responder address selection for intra realm communications optimization An NSIS Element hosting anNSLP) is impacted by NSIS NATFW NSLPmay have more than one address, its local scoped address(es) and global scoped address(es). A default address selection that priorities arbitrarily a global scoped address over a local scoped address may imply none optimal routing for communications between NSIS elements hosted within the same addressing realm. In Figure 1 the arbitrary selection of the global scoped address, works properly to receive NSIS signaling from Host B. However in deployment scenario shown in Figure 2, host Aunaware NATs andhost C end-up communicating through their local MB1 middlebox resulting in a non optimal data path with all its implications (additional delay, additional bandwidth in certain parts of the network infrastructure, etc ...). +---------------------+ +--------------------+ | | | | | Host A | ,-----------. | Host B | | +-----+| ,-'The NET `-. | | | | MB1 |+-- --+ | | +-----+| `-. ,-' | | | | `-----------' | | | | | | +---------------------+ +--------------------+ MB: Middle box (NAT or Firewall or a combination) Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities Figure 1 +---------------------+ +--------------------+ | | | | | Host A`-. | ,-----------. | Host B | | `. +-----+| ,-'The NET `-. | | | i.. MB1 |+-- --+ | | Host C_.-'' +-----+| `-. ,-' | | | | `-----------' | | | | | | +---------------------+ +--------------------+ MB: Middle box (NAT or Firewall or a combination) Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities Host C: An NE hosting NSIS NATFW NSLP NI/NR capabilities Figure 2 2.1 Potential solutions to the problem There are two ways to deal withFirewalls, thisnon-optimal routing of packets for intra-realm communications between NSIS entities. The NSIS Responder should either: 1. Decide based on local decision, which address to provide to the NI to signal it or, 2. Let the far end NSIS Initiator decide which address to select based on the NSIS Responder's provided addresses (1) lets the NSIS Responder decide on its own, which address to provide based on certain hints, which may not be the most optimal decision since the NSIS Responder may not have sufficient knowledge about the NSIS Initiator at the time of delivering its address to the responder. In most cases none arbitrary local decision for address selection requires to know about the far end host, which is not always practical. An example of such local based address selection is the IPv6 default address selection mechanism ([2]) where an IPv6 (or IPv6/v4) node has to select which source and destination address to pick in order to communicate with a far end node. The mechanism relies on receiving input from the local resolver (DNS client or local hosts file) about the far end node . In the context of multimedia applications (and probably othersdocument covers impacts aswell), the NSIS Initiator is provided the NSIS Responder contact information (includes IP address and transport port [1] via the user application protocols (example: SIP, H.323 etc ...). Within that specific context, the NSIS Responder does not have sufficient information about the NSIS Initiator to provide it a valid address. Hence it can not decide successfully in all cases which address to provide to the NSIS Initiator. Hence (2) is more efficientwell asit requires the NSIS Responder to provide all its addresses (local scoped and global scoped ones) to the NSIS Initiator. As a result, the NSIS Initiator will need to decide on which address to signal the NSIS Responder among all the provided ones. One possible way for the NSIS Initiator to decide from which address it will send NSIS signaling to the NSIS Responder and which NSIS Responder address to use is to check on which address the NSIS responder will reply back. An existing proposal [3] discusses the usage of (2) for SIP User Agents (SIP UA), the SIP UA will probe the far end SIP UA to see from which address it will response back. In [3], the STUN protocol [7] is used to check the responsiveness of the far end host. In [6], the reverse routability used to check which address to respondsome suggestions tocounters RTP DOS attacks. The same required reverse routability could be achieved by the NSIS NATFW NSLP. ****Include message sequences in the next iteration of the discussion******* Inease thecontextdeployments ofNSIS,the NSIS protocolitself should be used as the probing mechanism. Consequently the NSIS Initiator will send simultaneously several NSIS messages towards the NSIS Responder, one message per provided address. The following occur during the process: o In casesuite until theNSIS Responderinstalled base on NATs andInitiator are located within the same addressing realm, the NSIS Responder should receive a response from all the addressesFirewalls migrates towhich it has sent NSIS messages.NSIS. TheNSIS Initiator will then choose the local scoped address as the destination address for messages destined to the NSIS Responder. o In case the NSIS Responder and Initiator are not located within the same addressing realm, the NSIS Initiator would only receive a response from the valid global scope address. In event that there is another NE within the network that has the same local scoped address as the originally targeted NSIS Responder, the wrongly targeted NSIS ResponderNATFW NSLP shouldsend back an error or discard the message (the later would be preferable). 2.1.1 Intra realm solution protocol operation impacts As opposed to the normal NSIS mode of operation, an NI that has already a security association with the neighboring NE on the path to a specific NR would need to verify that the target local scoped NR address is the same as one already cached in its NSIS neighbor table cache (association of Next hop NE with the target NR table).This would be required to avoid any confusion withallow an end host supporting NSISnode that could be hosted within the same addressing realm and that would have the same local scoped address. There is a potential threat where an malicious NE with the same local scoped address as the target NR respond back positivelyto operate properly without theNSIS message and consequently hijack the data flow. This threat could be counter-measured by proper cryptographic authenticationneed ofthesupporting true end-to-end NSISResponder response by using keying material provided by the applicationsignaling(assuming that it was secured). The procedure requiring an NSIS Initiator to send NSIS messages to several NR addresses, requires that the NI sends his NSIS messages at the same timetoavoid impacting real-time sensitive applications. In case the response to the message sent to the global scoped is received first, it could potentially be used as a hint that no response will be received from the NR's local scoped address. Hence there is no point to continue to delay the address selection process and proceed with the NSIS protocol operations. In case the first response is received from a local scoped address and has been authenticated with the keying material provided by the application signaling protocol then the address selection process ends, and the NSIS protocol operations continue. 2.1.2 Intra realm solution application protocols impacts The proposed intra realm path optimization proposal requiring an NR to provide several data recipient addresses within the application protocol, has obviously a certain impact on the application protocol. [5] discusses the impact to SDP [8] and should be used by all theits applicationprotocols using SDP. A similar approach should be followed by other protocols, not using SDP, including H.323 [9] and others requiring usage of NSIS with multiple addresses for the NR. 3. NATFW NSLP migration analysiscorrespondent. Thissection goes through a detailed analysis ofis very practical during theNATFW NSLP transition challenges and its possible solutions. The conceptioninitial phases of the NSISNATFW NSLP MUST ensure that upon its deployments in networks, it should not disrupt applications using interim NATmigration andFirewall traversal mechanisms. In addition: o The NATFW NSLP should ensure that an NR would not always be required to have minimal service, particularly when the NI has ais applicable in simple networkconfiguration withoutconfigurations not affected by asymmetricroute issues.routing. In the early phases of the NSIS NATFW NSLP migration, this situation willbeoccur quite frequent and hence this scenario must be supported.oThe NSIS protocol shouldbe designed totraversenon-NSIS awareNSIS unaware NATsand Firewalls,(and possibly Firewalls) to allowusage of non NAT and Firewall related NSLP (Qos NSLP for example). As the reader will notice in the subsequent sections NRs behind o It is advised for an NSIS aware NAT and Firewall implementation to keep its existing currently used stateful behavior (depending on its applicability) until the transition to NSIS has ended (in order to havea smoothertransition). Severaldeploymentscenario will be considered within this analysis,of, forsimplicity the discussed scenario cover at most two Middleboxes on the path between the NI and NR. In Figure 3,example, Qos NSLP in today's networks. To provide atotal of 144 deployment scenario could be possible only the ones having an NI or NR (only when theresmooth migration it isa NAT) are considered. Implied but not shown scenario within Figure 5 are ones in the NI column or NR row. Obviously not allnecessary to understand thescenario will be coveredcoexistence of NSIS aware and unware NATs and Firewalls. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thissection, only the most interesting scenariodocument arediscussed in the next sections. A check list willto beadded later oninterpreted as described inthe annex of the next iteration of the analysis. `.-----+------+-------+-------+--------+------+-------+ | `NR | NAT | FW |NATFW | NAT++ |FW++ |NATFW++| |NI `. |NE+NAT|NE+FW |NE+NATFW NE |NE | NE | |``````|``````|```````|```````|````````|``````|```````| | |Sc2 | |Sc10 |Sc14 | |Sc22 | |NAT |Sc3 |Sc7 |Sc11 |Sc15 |Sc19 |Sc23 | |NE+NAT|Sc4 |Sc8 |Sc12 |Sc16 |Sc20 |Sc24 | |````````````````````````````````````````````````````` | |Sc26 | |Sc34 |Sc38 | |Sc46 | | FW |Sc27 |Sc31 |Sc35 |Sc39 |Sc43 |Sc47 | | NE+FW|Sc28 |Sc32 |Sc36 |Sc40 |Sc44 |Sc48 | ''''''''''''''''''''''''''''''''''''''''''''''''''''''' | |Sc50 | |Sc58 |Sc62 | |Sc70 | |NATFW |Sc51 |Sc55 |Sc59 |Sc63 |Sc67 |Sc71 | NE+NATFW Sc52 |Sc56 |Sc60 |Sc64 |Sc68 |Sc72 | ''''''''''''''''''''''''''''''''''''''''''''''''''''''' | |Sc74 | |Sc82 |Sc86 | |Sc94 | | NAT++|Sc75 |Sc79 |Sc83 |Sc87 |Sc91 |Sc95 | | NE |Sc76 |Sc80 |Sc84 |Sc88 |Sc92 |Sc96 | +------+------+-------+-------+--------+------+-------+ | |Sc98 | |Sc106 |Sc110 | | Sc118 | |FW++ |Sc99 | Sc103 |Sc107 |Sc111 |Sc115 | Sc119 | |NE |Sc100 | Sc104 |Sc108 |Sc112 |Sc116 | Sc120 | +------+------+-------+-------+--------+------+-------+ | |Sc122 | |Sc130 | Sc134 | | Sc142 | |NATFW++ Sc123| Sc127 |Sc131 | Sc135 | Sc139| Sc143 | | NE | Sc124| Sc128 |Sc132 | Sc136 | Sc140| Sc144 | +------+------+-------+-------+--------+------+-------+ Figure 3 Scxyz: Scenario number xyz NAT : NSIS Unaware NAT NE : NSIS Entity with NI and NR functions NE+NAT: NE hosted within a network connected to the[1]. The terminology used in this document is defined in [2]. 3. NSIS unaware NATFW : NSIS Unaware Firewall NE+FW: NE hosted within a network protected byTraversal This section discusses how anNSIS Unaware FW NATFW: NSIS Unaware NAT and Firewall hosted within the same Middlebox NE+NATFW:NEhosted within a network protected bywith any NSLP could still operate when an NSISUnaware NATFW NAT++: NSIS Awareunaware NATNAT++NE: NE hosted within a network connected to an NAT++ FW++ : NSIS Aware FW FW++NE: NE hosted within a network connected to a FW++ NATFW++: NSIS Aware NATFW NATFW++NE: NE hosted within a network connected to a NATFW++ Every cell in Figure 3is on thecombinationdata path. The detection ofthe NI's network and the NR's network. Deployments scenario, where there are no NI and NR, no NI (withoutanNR with a NAT), are not shown. For example: `.-----+------+ | `NR | NAT | |NI `. |NE+NAT| |````` :``````| | NAT |Sc2 | |NE+NAT|Sc3 | | |Sc4 | Figure 4 Scenario 1: NAT x NAT is not considered as there is no NI and no NR with a NAT Scenario 2:NSIS unaware NATx NE+NAT is considered as there is an NR withcould be aNAT (even if it is not NSIS aware) Scenario 3: NE+NAT x NAT, is considered since there is an NI as part of the NE functions Scenario 4: NE+NAT x NE+NAT, is considered since there is an NI as partfeature of the NTLP [3], allowing its usage on any NEfunctions The same logic is applicable to all the cells in Figure 3 For simplicity only network deployments are shown with a maximumregardless of2 MBs on the path between the NI and the NR. Handled scenario within the NI column or NR raw aretheones having an NI or NR. In the next sections, we shall go through the various issues that are specific to the scenario mentioned in Figure 3. 3.1 Global scoped address determination withsupported NSLPs. Several NSISunaware NATs This section discussesindependent approaches could be used by thepotentional role that anNEwith a NATFW NSLP could still havetodetermine alearn its global scoped addresstranslated by a none NSIS aware NAT. Upon detection that the NE is attachedin order toa network hosting an NSIS unaware NAT,use itcould havefor its hosted NSLPs. In this version of thetwo alternatives, either: 1. The NSIS API could invokedocument, only theservices of aSTUNclient [7] as shownprotocol [5] isFigure 7, this would allow applications using UDP transportconsidered as means towork (only applicable for cone NAT [7]).acquire the global scoped address; the next versions will consider other approaches. +---------------------------------------+ | | +--------+ | +----------+ | | STUN | | |Apps | | | Server | | +----------+ +---+| +--------+ | | STUN | |NAT|| | | CLIENT | | || | |__________| +---+| ||NATFW NSLP||ANY_NSLP | | | | NI/NR | | | +----------+ | | Host A | +---------------------------------------+ Figure5 2. The NE could send, through the1: STUN usage for NSIS unawareNAT, a bind request message towards a network entity hosting a simplified NR function responding to the message with the translated address. The translated address and port would correspond toNATs Within thetranslated source address and portinitial stages of thereceivedNSISmessage by the NE. This translated address and port information would only be useful for UDP transported data, and would imply that the NSIS protocol wouldmigration, NE functions will besent from the same address and port as the data flows. This behavior impliesco-hosting achange toSTUN client that was already present on theprotocol operations, sinceapplication end-host. Within Host A, shown in Figure 1, theNTLP does not normally require transport protocol changes for a given NSLP (at least for now);NSIS API could invoke theother implied modification is to support a minimum setservices ofoperations ontheresponding NE hostingSTUN client (as shown in Figure 2) upon determination that an NSIS unaware NAT was on theNATFW NSLP. The minimum set of operationspath.This wouldconsist of the ability to authenticate the NE, providing the translated address and port, and support ofallow applications using UDP transport(as well as TCP if certificates needtobe sent first). This mechanism would only bework (only applicabletofor coneNATs [7]. +---------------------------------------+ | | +--------+ + +----------+ | |NATFW | | |Apps | | | NSLP-NR| | +----------+ +---+| +--------+ | |NATFW NSLP| |NAT|| | | NI/NR | | || | +----------+ +---+| | Host A | | | +---------------------------------------+ Figure 6NAT variants [5]). +-----------------+ ___________| NSIS aware NAT |_________ | | Determination | | NSIS | +-----------------+ | NSIS Aware | | Unaware | | | | V V +-------------------+ +------------+ |Proceed with | If not UDP |Used data | |normal NR operation| +--------|transport | +-------------------+ | |protocol | | +------------+ | | If UDP V | +-------------+ | |Log error | | |to app layer | | +-------------+ V +-------------+ | Invoke STUN | | Client | +------+------+ | | | V +------------+ | Send STUN | | binding | | request | +-----+------+ | V +-------------------------+ |Standard STUN operations | +-------------------------+ Figure7 +-----------------+ ___________|2: Interactions with a STUN client NSLPs would use the STUN returned global scoped address for the flow id [3].To allow NSISaware NAT |_________ | | Determination | |signaling to be received by the NR on host A, without impacting existing applications (i.e. without explicitly providing the address and port of the NSIS| +-----------------+ |recipient in the application signaling), the NSISAware | | Unaware | | | | V +------------+ +-------------------+ If not UDP |Usedprotocols would need to use NTLP datagram mode transport (as defined in [3]). This would imply that the NTLP will be using the same port as the data| |Proceedflows, this might complicate the proposed mode of operations (and might not meet the expected performance). The next version of the draft will discuss whether this approach would be practical based on received feedback from implementors. Subsequently we discuss how the NATFW NSLP could co-exist with interim NAT traversal mechanisms described in [8]. In Figure 3, a STUN client (Host A) [5], an NE (Host B), a host using a Media Proxy [8] and host using a TURN client [9] co-exist in the same network with a NATFW NSLP aware NAT. There are no reasons for the existing mechanisms to be mutually exclusive every host could continue using the existing interim solutions, meanwhile the unilateral NSIS signaling would be used until both ends support the NSIS NATFW NSLP. +---------------------------+ |+--------|transport | |normal NR operation| | |protocol | +-------------------+ | +------------+ | | If UDP V | +-------------+ | |Log error_|__1______.STUN Server |STUN Client ----'''''''''' |V |to app layer|+------------+ +-------------+ |Send bindHost A ||create msgApp server ||over UDP2 _..NAT++ |+-----+------+.-' | NI/NR __.--'' |V +-------+------------+-----+3 .'+ |Simplified NE to respondHost B -'' | Media Proxy.-' |with observed translated| |address and port|+--------------+-----------+| Host C | |+---------------------+4 |NR to provide| Turn Client---------------+---------- TURN Server |translated addressHost D | |to app layer|+---------------------++---------------------------+ Figure8 3.2 Analysis3: Coexistence ofunilateralNSIS NATFW NSLP and existing NAT traversal mechanisms 4. Unilateral NSIS signaling When NSIS NAT/FW signaling will start to be deployed, it is quite possible that an NI sends an NSIS message without having an NR to respond to it. The NATFW NSLP shouldhave the ability to have a mechanism that would allow itbe able to handle this type of deployments. NSIS NATFW NSLP signaling for NAT binds is already local within the trustdomain,domain (the Reserve External Address is intercepted by the edge NAT, ref [2], however this is not the case with firewall signaling that should be end to end. Since the purpose of this section is to discuss how are end to end signaled messages handled when no NRs are available on the end-host only Firewalls (the NFs) are discussed within the example networks. There arethreetwo interesting cases to be analyzed:1.Approach 1: Implicit (not explicitly scoped) localized signaling: The local trust domain (from an NI perspective) has at least one NSIS aware Firewall, there is no NR on the far end as well as no NSIS aware NAT or Firewall. This approaches is similar to [13], however the NSIS messages do not included any scoping information. Figure 4 shows this scenario graphically. +-----------------------+ +--------------------+ |+----------+ | | +----------+ ||App client| | | |App client| ||NI/NR | FW++ | ,---------. | +----------+ |+----------+ ''''''' The net ---. Host B | | Host A | `---------' | | | | | | | Net A | | Net B | +-----------------------+ +--------------------+ Figure9 2.4: Implicit localized signaling Approach 2: Missing trust with far end host's NFs: The local trust domain has no NSIS aware Firewall, there is no NR at the far end but there is at least an NSIS aware firewall with which the local NI has no direct trust relation (which implies an authorization issue and possibly authentication issues).+-----------------------+ +--------------------+ |+----------+ | | +----------+ ||App client| | | |App client| ||NI/NR | | ,---------. | FW++ +----------+ |+----------+ '''''''Thenet ---. Host B | | Host A | `---------' | | | | | | | Net A | | Net B | +-----------------------+ +--------------------+ Figure 10 3. The local trust domain (from an NI perspective) has at least one Firewall, there is no NRmain addition to the issue discussed in the localized signaling case above (determination of the last NE on thefar end but there is at least onepath and response to the NSISaware Firewall with whichmessage by thelocal NI has no directlast NE) is the lack of trustrelation (which implies an authorization issue and possibly authentication issues).relations with the NI. Figure 5 shows this scenario graphically. +-----------------------+ +--------------------+ |+----------+ | | +----------+ ||App client| | | |App client| ||NI/NR |FW++| ,---------. | FW++ +----------+ |+----------+ ''''''' The net ---. Host B | | Host A | `---------' | | | | |Net B| | Net A | | Net B | +-----------------------+ +--------------------+ Figure115: Missing trust with the remote host's network In1),approach (1), the NI sends its firewall policy rule creation message, it traverses the first NF (its own firewall) but there is no NR to respond back. If we consider to have a response timer on the last NF being traversed by an NATFW NSLP message then if no response is received to the NSIS message, the last NF will respond back to the NI with a notification of no far end NR response. This will imply that the signaling will be scoped to the last NF on the path that responded back. Using the network deployment shown in Figure9,4, the following mode of operation would apply: Host A Host B NI FW++ Expected NR | | | |1-NSIS Init msg | | |----------------> | | | |2-NSIS Init msg | | | +---------------> | | | |NATFW NSLP ON | | | | | | | | | | | | | | | | Timeout | 3-NSIS Init msg Ack| V | |No NR | | |<.................| | Figure12 When6: Detecting the last NSIS peer Figure 7 provides the message sequences when more than one NSIS aware NAT or Firewall is deployed within the same trustdomain, upondomain. Upon determination of a previous NSIS hop, an NSIS aware node will notify the previous NSIS hop of its existence to avoid launching the timer that triggersthesending of an NSIS message back to the NI. The current NTLP message association establishment procedures supports this behavior. The last NF on the path will launch the timer since no valid downstream NSIS neighborwas sent to it.responded back. Trust domain A Trust domain B <..........................................> <--------> Host A Host B NI FW++ FW++ Expected NR | | | | | NSIS Init msg | | | | ----------------> | NSIS Init msg | | | | ---------------> | NSIS Init msg | | | NATFW NSLP ON |---------------->| | | | | with Token | | | Valid . | NATFW NSLP ON | | | NSIS Neighbor | | | | |<-----------------| | | | |----------------->| | Timeout | | | Ack | | | | | | | | | | | | | | | | | | | | | V | | | <................+ | | | NSIS Init msg Ack| | | NSIS Init msg Ack | No NR | | | No NR | | | | <.................| | | Figure137: Detecting the last NSIS peer (multiple FWs) In2),approach (2), the NI sends its firewall policy rule creation message, it traverses the FW hosted in Host B's network, but host A is not authorized to install a policy rule unless the policy rule creation is approved by a trusted entity within Net B. Unfortunately Host B was not yet upgraded to support the NATFW NSLP, another entity needs to authorize the policy rule installation. Potentially a trusted third party already aware of the application session held between Host A and Host B could provide an authorization token to Host A[13],[11], the token would be encapsulated within the NATFW NSLP message and would allow the NSIS aware Firewall in Net B to authorize Host A's requested policy rule to be installed. This approach would obviously require to put in place a mechanism to provide the authorization token to Host A. The token could be requested by the NI and included in the NSLP signaling by default or after receiving an error message from the far end NSIS aware Firewall indicating that authorization data is required. The authorization token would need to be associated with the identity of the NI, associating the authorization token with an IP address is not sufficient, and could lead to issues if the IP address was not valid due to address translation occurring on the path, a proper mechanism should be put in place to allow proper authentication of thelegalentitled token user.The next revision ofFigure 8 shows thediscussion will cover in more details this aspect.architecture with two different networks and the trusted third party which creates the authorization. Figure 9 provides a message flow for authorization token handling. +---------------+ | Authorization|1-Generate Token | mediator | .'--------------+ .' \ 2-Provide .-' \ Token .' \ .' \ .' \4-Check token .-' \ validity +-----------.'----------+ ++----------------+ |+--------.'+ | | \ +----------+ ||App client| | | \ |App client| ||NI/NR +-------. | ,-=.----.-. | FW++ +----------+ |+----------+ `---------'The net `-------- Host B | | Host A | `---------' | | | | 3-Send | | | Network A | NSLP msg with | Network B | +-----------------------+ Token +-----------------+ Figure148: Authorization Token Handling Trust domain A Trust domain B <........................> <---------------------> Host A Host B NI FW FW++ Expected NR | | | | | NSIS Init msg | | | | ------------------+----------------> | | | | | NSIS Init msg | | | | +-------------->| | | | NATFW NSLP ON | | | NSIS ERROR . | | <....................................| | | |Need Authorization| | | NSIS Init msg | | | | ------------------------------------>| | | with Token | | | | | | NSIS Init msg | | | |---------------->| | | | | with Token | | | Valid + | NATFW NSLP ON | | | NSIS Neighbor | | | | |<-----------------| | Timeout | | |----------------->| | | | NSIS Init msg Ack | Ack | | | | No NR | <................| V | | <.................| NSIS Init msg Ack| | | | No NR | | Figure15 In 3),the NI sends its message to the non-existing NR at host B, it traverses the first9: Authorization Token Message Flow 5. NSISaware Firewall, the policy rule installation succeeds; the message continues to be forwarded until it reaches the 2nd NATFW NSLP aware firewall. In case no authorization material is provided in the NSLP message, theunaware Firewallwill send an error message notifying the NI to send authorization data. If the NI can't send any authorization data, then it will decide to scope the NSIS signaling message to the last NF on which the state installation succeeded. Trust domain A Trust domain B <........................> <---------------------> Host A Host B NI FW++ FW++ Expected NR | | | | | NSIS Init msg | | | | ----------------> | NSIS Init msg | | | | +--------------> | | | | NATFW NSLP ON | | | | | | | | NSIS ERROR . | | |<.................| | | |Need Authorization| | | NSIS Init msg | | | | ----------------> | | | | Scoped to last | | | | succeeded state | | | |installation hop | | | | | | | | | | | | NSIS Init msg Ack | | | | No NR | | | | <.................| | | Figure 16 Since the signaling is unilateral (no NI available to do the installation for the other direction), the installed policy rules should be bi-directional. Although bi-directional policy rules could be problematic as discussed in [1], it is the only solution available when no remote NI would be available. 3.3 Co-existence with existing NAT traversal mechanisms Section 3.1 discussed how a NATFW NE could be used when an NSIS un-aware NAT is deployed within the network infrastructure. This section discusses how the NATFW NSLP could co-exist with interim NAT traversal mechanisms [10]. In Figure 17, a STUN client (Host A) [7], an NE (host B), a host using a Media Proxy [10] and host using a TURN client [11] co-exist in the same network with a NATFW NSLP aware NAT. There are no reasons for the existing mechanisms to be mutually exclusive every host could continue using the existing interim solutions, meanwhile the unilateral NSIS signaling would be used until both ends support the NSIS NATFW NSLP. +---------------------------+ | _|__1______.STUN Server |STUN Client ----'''''''''' | | Host A | App server | 2 _..NAT++ | .-' | NI/NR __.--'' | 3 .'+ | Host B -'' | Media Proxy.-' | | | | | Host C | | 4 | | Turn Client---------------+---------- TURN Server | Host D | | | +---------------------------+ Figure 17 3.4 NSIS protocol traversal of NSIS Unaware Firewalls and NATs 3.4.1 NSIS protocol traversal of NSIS Unaware FirewallsTraversal In case an NSIS unaware firewall is traversed by NSIS messages, NSIS messages should be allowed to go through it, as well as the exchanged data flows between the user application clients. This is not necessarily an obvious task to perform in case the NSIS messagescan'tcannot be identified by the NSIS unaware firewall. Same applies for the user application data flows. NSIS message identification should be supported by existing firewalls. Currently firewalls support flow identification by using the 5 tuple or a sub-set of it.WeThe authors are still expecting feedback from firewall vendors to see if we cannotassume thatthe firewallexisting firewalls willsupportnot drop packets including the the Router Alert Option (RAO) [12]. In case existing firewalls drop packets having the router alertoption [14], hence itoption, then the RAO should not be the only element of the used identification filter. User application data flow identification, should be deterministic at a specific address and port range level. This means that the application clients uses a combination of an address and specific transport portrange. Thisrange.This combination should be configured on the firewall.+-----------------------+ ++-------------------+ | | | +-----+ |+------+ | | | AC | ||AC | | ,-=.----.-. | |NI/NR| ||NI/NR + Qos++ -----'The net ----Qos++ FW +-----+ |+------+ | `---------' | Host B | | Host A | | | | | | | +-----------------------+ +--------------------+ FW: NSIS unaware FW Qos++: NE with Qos NSLP Figure 18 3.4.1.1 NSIS protocol traversal of a mix of NSIS Unaware Firewalls and NSIS aware NATsIn case a NAT is deployed on the path and it is NSIS-NATFW, the assigned bind should be consistent with policy rules configured with the NSIS unaware firewall.+-----------------------+ ++-------------------+ | | | +-----+ |+------+ | | | AC | ||AC | | ,-=.----.-. | |NI/NR| ||NI/NR + NATFW++ Qos++------'The net `----Qos++ FW +-----+ |+------+ | `---------' | Host B | | Host A | | | | | | | +-----------------------+ +--------------------+ FW: NSIS unaware FW Qos++: NE with Qos NSLP NATFW++: NSIS aware NATFW Policy rules configured on the NSIS unaware FW to allow specific filters for NSIS signaling and user Application data flows Figure 19Even though the deployedFWFirewall is not NSIS aware, the application data would still be forwarded if existing interim solutions were used such as a mix of stateless policy rules and flow based states with initial packets sent in the outbound direction (inside to outside a trust domain).3.4.1.26. NATFW NSLP NTLP requirements In this section we list two requirements for the NTLP raised by this document. o When NSISprotocol traversalsignaling is used in presence of NSISUnaware NATsunware NATscreate an address bind state for flows having well known patterns part of a predefined filter matching expression. In most cases the patterns consist of the protocol number within thethen raw IPheaderMUST NOT be used. Network address andtransportportnumbers. When a packet flow has different paterns within in its filter matching expression, not all NATs will be able to forward the packets. When several NEs are deployed behind NATs, a mandatory demultiplexing field is required for the NSIS protocol in order to match a source or destination to another source or destination. Priortranslation requires transport layer identifiers as mean tothe NSIS protocol, NATs haddirect inbound traffic towork with IPSEC before IPSEC UDP encapsulation was used ([4]),theSPI parameter wasright recipient. o If IPsec is usedas demultiplexing field, but this capability was not native in all NATs. Hence IPSEC hadtowait forsecure NSIS signaling messages then UDP encapsulationto be be forwarded through consumer market NATs. The learned lesson is that the best approachforthe NSIS protocol to be backward compatible with existing NATs, wouldIPsec protected packets (see [4]) MUST be used tobe transported over existing transport protocols andensure that IPsec does notto be sent as raw IP payload. 4. NATFW NSLP NTLP requirements The NATFW NSLP transition requires the NTLP to change transport protocol to UDP when the data is transported over UDP, as discussed in Section 3.1. If the valid next neighbor determination described in Section 3.2,break. IKE with extensions or IKEv2 isapplicable to other NSLPs it would potentially make senseable tohave a partdetect the presence ofit incorporated ina NAT along theNTLP.path. 7. Security Considerations This document discusses various security issues for NAT/Firewall signaling in migration scenarios. Furtherinvestigation would be required to define what shouldsecurity considerations can bedonefound in [2]. 8. Open issues Working on this document we identified to theNTLP (NSLP independent)following open issues andwhat shouldactions that need to bedone withintaken: o Add a network centric solution to address interim deployment phases where theNSLP. The NATFW NSLP does not have any next NSIS hop failure detection mechanism,end host doesn't support yet theNSLP reliesNSIS protocol suite. o Provide updates on thethe NTLP layer for this capability. NTLP security requirements: TBD 5. Security Considerations SectionRAO firewall issues o Update Section3.2 and [1] discuss the security considerations for the NSIS NATFW NSLP. 6. IANA Considerations There are no IANA considerations defined in this document. 7. Open Issues Need3 with regards toclose on:theintra-realm security issues,multiplexing/demultiplexing of NSIS messages and user data on theeditorial issues, linkingsame socket. o Move the mediated authorizationtoken with the NI cryptographic authentification mechanisms, NTLP required NAT handling capabilities.discussion in Section 4 to [2] Normative References [1]Brunner, M.,Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [2] Stiemerling, M., Martin, M., Tschofenig,H., Schulzrinne,H. and C. Aoun, "ANAT/FirewallNAT/ Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFTdraft-ietf-nsis-nslp-natfw-00.txt, October 2003. Informative References [2] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484,draft-ietf-nsis-nslp-natfw-01.txt, February2003.2004. [3]Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for the Session Initiation"GIMPS: General Internet Messaging Protocol(SIP)", DRAFT draft-rosenberg-sipping-ice-01.txt, Junefor Signaling", draft-draft-ietf-nsis-ntlp-00 (work in progress), October 2003. Informative References [4] A. Huttunen et all, A., "UDP Encapsulation of IPsec Packets", DRAFTdraft-camarillo-mmusic-alt-01.txt,draft-ietf-ipsec-udp-encaps-07.txt, Jan 2003. [5]Camarillo, J. and J. Rosenberg, "The Alternative Semantics for the Session Description Protocol Grouping Framework", DRAFT draft-camarillo-mmusic-alt-01.txt, June 2003. [6] Rosenberg, J., "The Real Time Transport Protocol (RTP) Denial of Service (Dos) Attack and its Prevention", DRAFT draft-camarillo-mmusic-alt-01.txt, June 2003. [7]Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.[8][6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.[9][7] ITU-T SG16, "Packet-based multimedia communications systems", ITU-T H.323, November 2000.[10][8] Rosenberg, J., "NAT and Firewall Scenarios and Solutions for SIP", draft-rosenberg-sipping-nat-scenarios-00 (work in progress), November 2001.[11][9] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-01 (work in progress), March 2003.[12][10] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August2002, <reference.RFC.3304.xml>. [13]2002. [11] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April2003, <reference.RFC.3521.xml>. [14]2003. [12] Katz, D., "IP Router Alert Option", RFC 2113, February1997, <reference.RFC.2113.xml>.1997. [13] Manner, J., "Localized RSVP", draft-manner-lrsvp-03 (work in progress), January 2004. Authors' Addresses Cedric Aoun Nortel Networks France EMail: cedric.aoun@nortelnetworks.com Marcus Brunner Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 29 EMail: brunner@ccrle.nec.de URI: http://www.brubers.org/marcus Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 13 EMail: stiemerling@ccrle.nec.de URI: Miquel Martin Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 16 EMail: miquel.martin@ccrle.nec.de URI: Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich 81739 Germany Phone: EMail: Hannes.Tschofenig@siemens.com URI: Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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 does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society(2003).(2004). All Rights Reserved. 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 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. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.