Internet Engineering Task Force Internet Draft H. Tschofenig, H. [-Schulzrinne-] {+Schulzrinne, C. Aoun+} Siemens/Columbia [-U. draft-tschofenig-nsis-casp-midcom-00.txt 23 October 2002-] {+U./Nortel Networks draft-tschofenig-nsis-casp-midcom-01.txt 3 March 2003+} Expires: [-January-] {+September+} 2003 A Firewall/NAT Traversal Client for CASP 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document describes a CASP client protocol that allows nodes to signal information to firewalls [-mainly-] {+both+} in an in-path {+and off-path+} fashion. The protocol furthermore allows [-the signaling initiator-] to establish [-and/or learn-] a NAT [-binding.-] {+binding and to provide the signaling initiator with the NAT information.+} This {+is+} information can then be used within other protocols such as SIP. H. Tschofenig et. al. [Page 1] Internet Draft CASP [-Midcom 23 October 2002-] {+NATFW 3 March 2003+} 1 Introduction [-CASP-Midcom-] {+CASP-NATFW+} is a client protocol for the Cross-Application Signaling Protocol (CASP) [1]. It is one of a family of CASP client protocols and allows the signaling of firewall {+and NAT+} information along the data path [-(in- path)-] {+(in-path)+} in a topology independent manner. [-CASP-Midcom-] {+CASP-NATFW+} aims to address issues raised [-in-] {+and not solved within+} the MIDCOM working group [2] and uses ideas for in-path signaling using RSVP as described in [3] and in [4]. [-CASP-Midcom aims to provide a long-term solution to the MIDCOM problem-] {+2 Definitions Terms in context+} with [-the-] {+trust relationships are described in [5]. The+} following [-properties: Routing-] {+terms are used in this document: Policy Rule: The term policy rule is used as defined in [6]. A policy rule consists+} of [-Signaling Messages: CASP with its scout discovery mechanisms allows signaling messages-] {+two components: a packet filter and an action+} to [-follow the path of-] {+be performed on packets matching+} the [-data traffic towards a destination.-] {+packet filter expression.+} This [-assumes that standard routing-] {+document uses two actions for a policy rule: allow without logging and allow with logging. Per-default no logging+} is used. [-CASP, however, operates independent of the underlying routing mechanism. Route changes can be detected by the scout protocol and signaling message transmission-] {+If logging+} is [-adopted accordingly. Other mechanisms for detecting route changes can also-] {+desired then it has to+} be [-used such-] {+specified+} as [-routing protocols. Security Protection: Creating holes into-] {+described in Section 9. As stated in [6] it was agreed not to specify+} a [-firewall-] {+deny action for policy rule. Hence there+} is [-a sensitive task that requires trust and an appropriate security protection of-] {+no such deny action defined in this document. In+} the [-signaling messages-] {+context of NAT, as defined+} in [-order to-] {+[7], basic NAT, NAPT and twice NAT could+} be [-successful. Trust assumptions between the participating entities thereby determine whether-] {+applied to packet flows matching+} the [-task of installing-] packet [-filters at a firewall-] {+filter. Policy Groups: The term policy group+} is [-possible at all. CASP-Midcom thereby reuses the security mechanisms introduced by CASP. Still some additional security mechanisms described-] {+not used+} in this document [-have to be used to provide secure protocol operation. Sender/Receiver Initiated: CASP signaling can be executed in sender- and receiver initiated mode. Establishment of firewall-] {+since its meaning is partially captured by the packet filter. A+} packet filter [-information is usually done in a asymmetric manner e.g. establishment-] {+allows various attributes (even lists and ranges+} of [-unidirectional Traffic Selectors at firewalls. Flexibility in Message Delivery: Signaling messages can-] {+certain attributes) to+} be [-triggered by any node along the path.-] {+specified.+} In [-most cases, however, it is the responsibility-] {+case+} of [-the-] {+in- path+} signaling [-message initiator (typically-] {+only one particular destination IP address (which is available in+} the [-end host)-] {+CASP NTLP payload) can be specified. More fine grain packet filters have+} to [-provide-] {+be specified in+} the [-necessary information which policy rules to install.-] CASP [-messages might terminate at any CASP peer along the path. Hence it is-] {+NSLP payload (in this case CASP-NATFW). For off- path signaling this rule must+} not [-necessary to forward the messages-] {+hold. Lifetime of Policy Rules: An NSLP is allowed+} to {+specify+} the [-final destination.-] {+lifetime for policy rule.+} The [-decision whether-] {+lifetime corresponds+} to [-furthermore forward the signaling message toward the destination can be caused by-] the [-initiator (by including CASP specific information)-] {+refresh interval. If no lifetime+} or {+refresh interval is selected then a default value is used. Packet filter (PF): The term packet filter refers to attributes describing subsets of+} the [-decision could also be forced-] {+data traffic+} for [-example by a non CASP-aware firewall. Such-] {+which+} a [-device might not forward CASP message. Another example-] {+specific behavior should be provided. The term flow identifier+} is [-an-] {+also+} H. Tschofenig et. al. [Page 2] Internet Draft CASP [-Midcom 23 October 2002 authorization failure generated because of lacking trust (and proper credentials by-] {+NATFW 3 March 2003 often used in+} the {+area of QoS+} signaling [-initator). Error Resilience: CASP was designed based on the soft-state principle to allow orphan states-] {+protocols. For NAT traversal a packet filter (or flow identifier) refers+} to [-time-out automatically. End Host Topology Unawareness: Routing-] {+a NAT binding. The terms in-path (off-path)+} signaling [-messages along-] {+can be used inter-changable with path-coupled (path-decoupled) signaling. 3 General Limits of In-Path Firewall Signaling At+} the [-data path allows CASP aware nodes to reflect topology information into-] {+beginning of this document it is worth stating that+} the [-processing-] {+problem+} of [-CASP-] {+firewall+} signaling [-messages. Processing of Traffic Selectors-] is [-an example where local topology-] {+addressed by a number of working groups. This section provides a brief overview of some of the recent activities+} and [-protocol information need to be available-] {+describes the general limits of in-path firewall signaling. The following working groups or activities at the IETF have a relationship+} to [-ensure proper behavior. Traffic Selector handling is already defined-] {+policy rule installation and firewall communication+} in [-CASP [1]. Defining them-] {+general: To address a single device+} at the [-CASP M-Layer is necessary since this object-] {+borders of the access networks (i.e. the first IP device)+} is [-used by more than one client layer protocol. The Traffic Selector used in CASP-QoS [5] messages might be also require modification-] {+covered+} by {+the PANA working group to implement the controlled/uncontrolled network access procedures. Thereby authentication of+} a [-NAT along-] {+user or a device with+} the [-path. Mid-path modification-] {+help+} of {+EAP is required to create policy rules at+} the [-Traffic Selector-] {+first IP device. This subsequently+} allows the end host to [-be topology unaware. If topology information needs-] {+forward packets+} to [-be incorporated into the signaling message processing then it should be done at the locations where-] the [-corresponding information is easily available (for example at the individual CASP-Midcom aware nodes along-] {+Internet or to access services within+} the [-path). 2 Definitions Trust Relationship:-] {+local domain.+} The [-term trust relationship and the subcategories is used-] {+MIDCOM working group also aims to install policy rules+} at [-various places in this document. Since its meaning might confuse some readers a short description is given in this section. CASP is-] {+firewalls. However, their approach seems to be focused on off-path signaling. Additionally of interest are activities related to Endpoint Firewall Controll, RSIP and Socks. To provide+} a [-protocol for establishing-] {+generic solution to install+} state [-information within-] {+at+} a possibly large number of [-network elements. Unlike to typical end-to-end communication protocols there-] {+firewalls along the path some trust must be placed on devices along the path. If no such trust+} is [-more than one mean to establish trust: end-to-end, end-to-middle, between neighboring peers and between non-neighboring peers.-] {+available which might be likely the case in an adhoc network scenario as shown in+} Figure 1 [-describes these options graphically: The existence-] {+then firewall signaling is doomed to fail. An adhoc networks consists+} of a [-security association (statically or dynamically created) requires some degree-] {+number+} of [-trust. However, it does not necessarily lead to-] {+nodes between+} the [-necessary degree of trust-] {+end host (Node A) and the ISP+} to [-allow certain operations-] {+which Node A wants+} to [-be executed (authorization). Hence in this case-] {+get access. Although Node A uses an authentication and key exchange protocol to create a policy rule at+} the [-term trust-] {+firewall 1 it+} is [-not equal-] {+still possible for an untrusted node (in this case Node 3)+} to {+inject data traffic which will pass Firewall 1 since+} the [-existence-] {+data traffic is unauthenticated. To prevent this type+} of {+threat protocols developed in the IPSEC or the IPSRA working group, which establish+} a security [-association. With-] {+association to protect+} the [-creation of policy rules at firewalls additional trust might-] {+data traffic, can+} be [-required in addition to a chain-of-trust where only neighboring peers trust each other. The principle of chain-of-trust is a frequently used concept in the area of QoS signaling protocols. In Section 2 of [6] the concept is described in-] {+used.+} H. Tschofenig et. al. [Page 3] Internet Draft CASP [-Midcom 23 October 2002 **************************************** * * * * +----+-----+ +----------+ +----+-----+ +-----+ Firewall +-------+ Firewall +--------+-] {+NATFW 3 March 2003 To summarize: In many cases in-path policy rule installation might provide enough security protection to prevent unauthorized nodes from gaining access to network resources. However, due to the absence of per- packet authentication man-in-the-middle attacks of malicious nodes along the path cannot be prevented by installed policy rules. +------------------------------------------+ +--------// | Adhoc | | ISP | Network | | | regular data | | | traffic by +---------+ | | | node A |Malicious| | +-+--------+ | +-------------->+ Node +-----+///-->++} Firewall [-+-----+-] {++-//+} | {+^+} | {+3 |===========>|+} 1 | | [-2-] {+| +---------+ injected +-+--------++} | | [-3-] {+data traffic+} | | | [-+----------+ +----+-----+ +----------+-] | | [-~-] | | [-~-] | | [-~-] | {++---+-----+ +---------++} | [-~-] | | [-~-] {++ Node+} | | [-~~~~~~~~~~~~~~~~~~~~~~~~~~~~-] {+Node+} | | [-~-] | | [-~-] | [-+--+--++ +--+---+-] {+1+} | [-Host +//////////////////////////////////////////////////////+ Host-] | {+2+} | [-A-] | | [-B-] {+| +---------+ +---------+ | | | ^ | +--------// | | | +----------+-------------------------------+ | +--+---+ | Node | | A+} | +------+ [-+------+ Legend: -----: Peer-to-Peer Trust Relationship /////: End-to-End Trust Relationship *****: Middle-to-Middle Trust Relationship ~~~~~: End-to-Middle Trust Relationship-] Figure 1: [-Possible-] {+General Limits of In-Path Firewall Signaling 4+} Trust Relationships [-more detail. Policy Rule: The term policy rule-] {+It+} is [-used as defined in [7]. Other frequently used terms are packet filters, filter rules or firewall rules. In addition to the Traffic Selector attributes an action has-] {+unusual+} to [-be specified. Since it was agreed not-] {+start a protocol description with trust relationships+} to [-allow deny rules there-] {+explain the basic protocol behavior. A protocol for firewall traversal is somewhat different since trust relationships+} are [-only two possible actions: allow without logging-] {+very important for the protocol design+} and [-allow with logging. Per-default no logging is defined --] {+NAT traversal does not cause problems to+} the [-Traffic Selector attribute is used without any modification. If logging is desired then it has to be specified as described in Section 8. As stated in [7] it was agreed not to specify a deny action-] {+same degree.+} for [-policy rule. Hence there is no such deny action defined in this document. Policy Groups: The term policy group is not used in this document since-] its [-meaning is partially captured by the Traffic-] {+internal mechanisms.+} H. Tschofenig et. al. [Page 4] Internet Draft CASP [-Midcom 23 October 2002 Selector functionality introduced in CASP. CASP allows various Traffic Selector attributes (even lists and ranges of certain attributes) to be specified. In case of in-path discovery only one IP destination address-] {+NATFW 3 March 2003 4.1 Peer-to-Peer Trust Relationship The following scenarios+} can be [-specified inside the Traffic Selector in-] {+considered as+} the [-generic case-] {+simplest+} since [-it is used routing (and hence also used by the scout in-path discovery protocol). For off-path signaling this rule must not hold. Lifetime of Policy Rules: It is worth mentioning that-] {+peer-to- peer trust relationship exist between+} the [-lifetime specified for policy rules is equal-] {+participating entities. These trust relationships are either direct or indirect and help+} to {+establish security associations dynamically (for example between Host A and+} the [-established state at the C-layer. For-] {+local middlebox i.e. Middlebox 1 within Network A) with+} the [-lifetime-] {+help of an authentication and key exchange protocol. Authentication and authorization of+} the [-following rule applies: lifetime(C-Layer) less-or-equal lifetime(M-Layer) less-or- equal lifetime(T-Layer). Since-] {+request to+} the [-Transport-Layer (T-Layer)-] {+middlebox device+} is [-shared by many M-Layer session its lifetime-] {+thereby required for successful protocol completion. Important in this context+} is [-not explicitly specified. The lifetime of-] the [-T-Layer might depend on-] {+trust relationship between+} the [-local policy but usually it is removed as soon as all M-Layer states expired. Traffic Selector (TS): The term Traffic Selector refers-] {+two networks (i.e. between Middlebox 1 and Middlebox 2). In this scenario it is assumed that no firewall is present within the core network. In case that Middlebox requires authentication of the Host A (or from the user located at Host A) then an "Authentication Required" RESPONSE message with an error code is returned+} to [-attributes describing subsets-] {+the initiator. In case+} of a [-data traffic for which a specific behavior-] {+sender-initiated signaling message transmitted by Host A the requested filter entries at the first middlebox are already installed when the request at the subsequent middlebox fails. Since end hosts usually do not have (and+} should [-be assigned. In case-] {+not have) topology information+} of [-firewall traversal-] the [-term Traffic Selector refers-] {+networks along the path it is not possible+} to {+transmit+} policy rules [-(or policy groups-] {+for both directions (if data traffic later flows+} in [-case that-] {+both directions). Hence+} it is [-more generalized). The term-] {+required that both nodes transmit separate signaling messages for each direction containing separate policy rules for each traffic+} flow [-identifier-] {+(if the data traffic+} is [-also often used-] {+later sent+} in [-the area of QoS-] {+both directions). These+} signaling [-protocols. For a NAT traversal a Traffic Selector refers to-] {+messages are transmitted by+} the [-NAT binding. There is furthermore a one-to-one relationship between a M- layer and a C-layer (state defined in this document including policy rules-] {+end hosts+} and [-other parameters) state. If a particular M- layer state is removed then also the corresponding C-layer state has-] {+they do not need+} to [-be removed. The identification-] {+travel along the same path because+} of {+asymmetric routes (see [8]. Therefore+} the [-both states (M-layer and C-layer)-] {+signaling message which+} is [-done based on-] {+triggered from+} the [-128-bit session identifier. 3 Trust Relationships It is unusual-] {+two end hosts in each direction do not necessarily need+} to [-start a protocol description-] {+install state at the same firewall. Policy rule installation is based on the information transmitted+} with [-trust relationships-] {+the flow identifier object at the CASP NTLP layer and at the packet filter object at the NATFW NSLP layer. The content of both objects might change mid-path (for example when passing a NAT) and is allowed+} to [-explain-] {+change mid-session (for example because of mobility). For those cases where+} the [-basic protocol behavior. A protocol for firewall traversal-] {+information carried within a packet filter object cannot be interpreted an error message+} is [-somewhat different since trust relationships are very important for-] {+returned indicating+} the [-protocol design and-] {+inadequate information. Packet filter processing failures are possible when+} for [-its internal mechanisms. It-] {+example a Virtual Private Network Identifier such as (Extended) Tunnel ID+} is [-worth noting that NAT traversal does not cause problems-] {+transmitted to an IP firewall or when a firewall is unable+} to {+install a packet filter with+} the [-same degree. 3.1 Peer-to-Peer-] {+indicated granularity. 4.2 Intra-domain+} Trust Relationship [-The following scenarios can be considered as the simplest since peer-to- peer trust relationship exist between the participating entities. These-] H. Tschofenig et. al. [Page 5] Internet Draft CASP [-Midcom 23 October 2002 trust relationships are either pre-existing or can be dynamically established (for example between Host-] {+NATFW 3 March 2003 +--------------------------+ +--------------------------+ | | | | | Network+} A [-and the local middlebox i.e. Middlebox 1 within-] {+| |+} Network [-A) as part of the execution of a security protocol. Authentication and authorization of the request to the middlebox device is thereby required for successful protocol completion. Important in this context is the trust relationship between the two networks (i.e. between Middlebox-] {+B | | | | | | +---------+ +---------+ | | +-///-+ Middle- +---///////----+ Middle- +-///-+ | | | | box+} 1 [-and Middlebox 2).-] {+| Trust | box 2 | | | | | +---------+ Relationship +---------+ | | | | | | | | | | | | | | | | | | | | | | Trust | | Trust | | | | Relationship | | Relationship | | | | | | | | | | | | | | | | | | | | | +--+---+ | | +--+---+ | | | Host | | | | Host | | | | A | | | | B | | | +------+ | | +------+ | +--------------------------+ +--------------------------+ Figure 2: Peer-to-Peer Trust Relationship+} In [-this scenario it is assumed that no-] {+larger corporations often more than one+} firewall is [-present within the core network.-] {+used to protect different departments.+} In [-case that Middlebox requires authentication of the Host A (or from-] {+many cases+} the [-user located at Host A) then an "Authentication Required" RESPONSE message with an error code-] {+entire enterprise+} is [-returned-] {+controlled by a security department which gives instructions+} to the [-initiator.-] {+department administrators.+} In [-case of-] {+such+} a [-sender- initiated signaling message transmitted by Host A the requested filter entries at the first middlebox are already installed when-] {+scenario a peer-to-peer trust- relationship might be prevalent. Sometimes however it might be necessary to preserve authentication and authorization information within+} the [-request at-] {+network. In this case an interaction between+} the [-subsequent middlebox fails. Since end hosts usually do not have (and should not have) topology information of the networks along the path-] {+individual middleboxes and a central entity (for example a policy decision point - PDP) might be required. Otherwise+} it is [-not-] possible to [-transmit Traffic Selectors for both directions (if data traffic later flows in both directions). Hence it is required that both nodes transmit separate signaling messages for each direction containing separate Traffic Selectors for each traffic flow (if the data traffic is later sent in both directions). These signaling messages are transmitted by-] {+communicate+} the [-end hosts and they do not need-] {+authorization decision made at one firewall+} to [-travel along-] {+another firewall within+} the same [-path. Therefore the signaling message in both directions do not necessarily install state at-] {+trust domain. Each middlebox can either communicate with+} the [-same firewall. Policy rules installation is based on-] {+PDP or+} the [-information transmitted with-] {+PDP issues an authorization token which allows+} the [-Traffic Selector object. Traffic Selectors can change mid-path (for example when passing a NAT) and are allowed-] {+middleboxes+} to [-change mid-session (for example because-] {+react independently. Figure 3 refers to this structure. To avoid complex protocol interactions individual middleboxes within an administrative domain should make use of their trust relationship instead of requesting authentication and authorization+} of [-mobility). For those cases where-] the [-information transported within-] {+signaling initiator again. This provides both+} a [-Traffic Selector object cannot-] {+performance improvement without a security disadvantage since a single administrative domain can+} be [-interpreted an error message is returned indicating the inadequate information. Traffic Selector processing failures are possible when for example-] {+seen as+} a [-Virtual Private Network Identifier such as (Extended) Tunnel ID is transmitted to an IP firewall. 3.2 Intra-domain Trust Relationship In larger corporations often more than one firewall is used to protect different departments. In many cases the entire enterprise is controlled by a security department which gives instructions to the department administrators. In such a scenario a peer-to-peer trust- relationship might be prevalent. Sometimes, however, it might be necessary to preserve authentication and authorization information within the network. In this case an interaction between the individual middleboxes and a central entity (for example a policy decision point - PDP) might be required. Each middlebox can either communicate with the-] {+single entity.+} H. Tschofenig et. al. [Page 6] Internet Draft CASP [-Midcom 23 October 2002 +--------------------------+ +--------------------------+ | |-] {+NATFW 3 March 2003 +---------------------------------------------------------------++} | | | Network A | | [-Network B | |-] | | | | +---------+ +---------+ | [-| +-///-+-] {++----///--------++} Middle- [-+---///////----+-] {++------///------+++} Middle- [-+-///-+ |-] {++---+} | | | box [-1-] {+2+} | [-Trust-] | box 2 | | | [-| | +---------+ Relationship +---------+ | | | | |-] {++----+----+ +----+----++} | | | | | | {++----+----++} | | | | | {+Middle- +--------+ +---------++} | | | | {+box 1+} | | [-Trust-] | | [-Trust-] | | {++----+----++} | | [-Relationship-] | | [-Relationship-] | | | | | | | {+-+} | | | | | {+-+} | {++----+-----++} | | | | | | {+Policy+} | | [-+--+---+-] | | +--+---+ {++-----------+ Decision +----------++} | | | Host | | [-| | Host-] {+Point+} | | | | A | [-| | | B | | | +------+-] {++----------++} | | +------+ | [-+--------------------------+ +--------------------------+-] {++---------------------------------------------------------------++} Figure [-2: Peer-to-Peer-] {+3: Intra-domain+} Trust Relationship [-PDP or the PDP issues an authorization token which allows the middleboxes to react independently. Figure 3 refers to this structure. To avoid complex protocol interactions individual middleboxes within an administrative domain should make use of their trust relationship instead of challenging the signaling message originator. 3.3-] {+4.3+} Required 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 some [-proof of identity-] {+authentication+} of the signaling message [-originator.-] {+initiator.+} If [-such a proof-] {+authentication and authorization information+} is not [-included in-] {+attached to the initial signaling message then+} the signaling message arriving at Middlebox 2 [-then-] {+would cause+} a RESPONSE message with an error code "Authentication Required" is returned. However, in many cases the user initiating the signaling message exchange is already aware of such a constraint and received credentials before the message exchange was started. These credentials might be based either on symmetric (shared secret) or based on asymmetric (public key) cryptography. In order to avoid a challenge/response type of message exchange [-and to reuse the CASP H. Tschofenig et. al. [Page 7] Internet Draft CASP Midcom 23 October 2002 +---------------------------------------------------------------+ | | | Network A | | | | | | +---------+ +---------+ | +----///--------+ Middle- +------///------++ Middle- +--- | | | box 2 | | box 2 | | | +----+----+ +----+----+ | | | | | | +----+----+ | | | | | Middle- +--------+ +---------+ | | | | box 1 | | | | | | +----+----+ | | | | | | | | | | | - | | | | | - | +----+-----+ | | | | | | Policy | | | | +--+---+ +-----------+ Decision +----------+ | | | Host | | Point | | | | A | +----------+ | | +------+ | +---------------------------------------------------------------+ Figure 3: Intra-domain Trust Relationship security mechanisms-] the initiating node (Host A in [-this case)-] {+our scenario)+} already includes a CMS object to the outgoing signaling message. The CMS object contains the identity of the signaling initiator, the identity of the {+destination+} network, the destination address of Host B, a timestamp for replay protection and possibly some {+H. Tschofenig et. al. [Page 7] Internet Draft CASP NATFW 3 March 2003+} other application specific information like an application identifier. CMS allows to use both symmetric and asymmetric credentials. Figure 4 shows the slightly more complex trust relationships in this scenario. [-3.4 Missing Network-to-Network Trust Relationship Peer-to-peer trust relationship as shown in Figure 2 is a very convenient assumption that allows simplified signaling message processing. However, it is obvious that such an assumption does not always hold. Especially the trust relationship between two arbitrary H. Tschofenig et. al. [Page 8] Internet Draft CASP Midcom 23 October 2002-] +--------------------------+ +--------------------------+ | | | | | Network A | | Network B | | | | | | | Trust | | | | Relationship | | | +---------+ +---------+ | | +-///-+ Middle- +---///////----+ Middle- +-///-+ | | | | box 1 | +-------+ box 2 | | | | | +---------+ | +---------+ | | | | | | | | | | |Trust | | | | | | |Relationship | | | | | | | | | | Trust | | | | | | | Relationship| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +--+---+ | | | +--+---+ | | | Host +----///----+------+ | | Host | | | | A | |Trust | | B | | | +------+ |Relationship | +------+ | +--------------------------+ +--------------------------+ Figure 4: End-to-Middle Trust Relationship {+4.4 Missing Network-to-Network Trust Relationship Peer-to-peer trust relationship as shown in Figure 2 is a very convenient assumption that allows simplified signaling message processing. However it is obvious that such an assumption does not always hold. Especially the trust relationship between two arbitrary+} non-adjacent access networks is likely non-existent because of the large number of networks and the unwillingness of administrators to have other network operators to create holes in their [-firewalls.-] {+firewalls without proper authorization.+} Hence in the following scenario we assume a somewhat {+H. Tschofenig et. al. [Page 8] Internet Draft CASP NATFW 3 March 2003+} different message processing and show three possible [-approaches.-] {+approaches to tackle the problem.+} None of these three approaches is without drawbacks or constraining assumptions. [-We identified three possible approaches of tackling the problem described in Figure 5. Receiver-Initiated Signaling The first approach makes use of receiver-based signaling message exchange. If Host A sends a signaling message toward the destination to Middlebox 1 the message can be properly protected. Middlebox 1 establishes some state information and expects a incoming message initiated by Host B. Signaling message protection between the H. Tschofenig et. al. [Page 9] Internet Draft CASP Midcom 23 October 2002-] +--------------------------+ +--------------------------+ | | | | | Network A | | Network B | | | | | | +---------+ Missing +---------+ | | +-///-+ Middle- | Trust | Middle- +-///-+ | | | | box 1 | Relation- | box 2 | | | | | +---------+ ship +---------+ | | | | | | | | | | | | | | | | | | | | | | Trust | | Trust | | | | Relationship | | Relationship | | | | | | | | | | | | | | | | | | | | | +--+---+ | | +--+---+ | | | Host | | | | Host | | | | A | | | | B | | | +------+ | | +------+ | +--------------------------+ +--------------------------+ Figure 5: Missing Network-to-Network Trust Relationship {+We identified three possible approaches of tackling the problem described in Figure 5. Receiver-Initiated Signaling: The first approach makes use of receiver-based signaling message exchange. If Host A sends a signaling message toward the destination to Middlebox 1 the message can be properly protected. Middlebox 1 establishes some state information and expects an incoming message initiated by Host B. Signaling message protection between the+} two networks is difficult. [-The-] {+A+} missing trust relationship does not necessarily mean that no security association establishment is possible. The lacking trust "only" disallows Middlebox 1 to create packet filters at Middlebox 2. {+Hence, this missing trust is an authorization problem rather than a security association establishment problem.+} If the CASP {+H. Tschofenig et. al. [Page 9] Internet Draft CASP NATFW 3 March 2003+} message itself is allowed to pass the firewall then it finally reaches Host B. Host B should not experience any difficulties to install filters at the local firewall (Middlebox 2). The message is then forwarded to Middlebox 1 which already waits for the incoming signaling message. Because it is possible to associate existing state information at Middlebox 1 with the incoming message packet filters are installed and the message is finally forwarded to Host A. Authorization for packet filter installation in Network A has to be provided by Host A and for Network B has to be provided by Host B when returning the response message. [-Traffic Selectors-] {+packet filters+} are installed for data traffic from Host A to Host B. The same procedure has to be applied again to signal information for the other direction (Host B to Host A). [-H. Tschofenig et. al. [Page 10] Internet Draft CASP Midcom 23 October 2002-] The following behavior has to be assumed in order for this approach to be applicable: - [-CASP signaling-] {+Signaling+} messages must be allowed to pass firewalls along the path. {+No authorization for packet filter installation is required at this stage.+} Blocking [-CASP-] {+signaling+} messages at firewalls disallows the receiver of the signaling message to return a signaling message. - The {+signaling message initiated by the NI will require state installation on all the NFs in the path (if a RSVP+} PATH message {+semantic+} is [-assumed to be stateful.-] {+assumed). CASP NTLP, however, also allows a stateless signaling message routing.+} This approach suffers from the following drawbacks: - If {+the+} CASP signaling messages [-are-] {+(in this case the "PATH" message) is+} not allowed to bypass a firewall then no policy rules are [-create-] {+created+} at any node along the path. - [-Receiver-Initiated-] {+Receiver-initiated+} signaling has the advantage that the receiver has to accept the creation of the policy rule in his own network to trigger the creation locally. This seems to simplify security processing. If a NAT is present then still a RESPONSE message is required to inform the data message sender about the NAT-binding (i.e. the IP addresses and port information seen by a data traffic receiver). Access Network-Only Signaling Message Exchange The next approach is based on signaling [-Traffic Selector-] {+packet filter+} information by both hosts into the local access network only. CASP allows to specify such a behavior by indicating the signaling endpoint with the help of scoping ( for example with domain [-name). If packet filters for both directions have to be installed then signaling messages have to make reservations up- and downstream along the data path. Similar-] {+name or a "local H. Tschofenig et. al. [Page 10] Internet Draft CASP NATFW 3 March 2003 network only" flag). Scoping means that the signaling message although addressed to a particular destination IP address terminates somewhere along the path. If packet filters for both directions have to be installed then the signaling messages have to make packet filter installations up- and downstream along the data path. Similar+} to proposals in the area of QoS signaling some problems are likely to occur. One such problem is that downstream [-reservations-] {+signaling+} in general [-does not work due to the policy-] {+causes problems because+} of [-routing protocols and the-] asymmetric routes. {+In particular it is difficult to determine the firewall where the downstream data traffic will enter a network.+} The problem of triggering downstream reservations is for example described in [-[8].-] {+[9].+} Another problem for example is the placement of a firewall or NAT along the path other than in the access network. This would prevent a successful data exchange. The following behavior has to be assumed in order for this approach to be applicable: - [-Triggering-] {+It must be possible to trigger+} a signaling message {+exchange for a+} downstream [-must be possible. Thereby-] {+signaling message exchange at+} the [-correct-] firewall [-should be affected-] where [-later-] {+the+} data traffic enters the [-domain. H. Tschofenig et. al. [Page 11] Internet Draft CASP Midcom 23 October 2002-] {+network.+} - No other firewalls or NATs are present along the path other than in the access network. This approach suffers from the following drawbacks: - To signal policy rules only within the access network (by both end-points) has a number of disadvantage and challenges [-as described in various source including [8].-] {+(see for example [9]).+} The complex message processing caused by this approach [-stronly-] {+strongly+} argues against it although it might sound simple (and even might be simple in restricted environments). Section [-9 also addressed-] {+10 addresses+} message flows for this case. Although its usage is possible with CASP we strongly discourage its usage. - Some circumstances can lead to ineffective policy rules. Authorization [-Tokens-] {+Tokens:+} The last approach is based on some exchanged authorization tokens which are created by an authorized entity (such as the PDP) in each access network. Both hosts need to exchange these tokens with some protocols such as SIP or HTTP which is more likely [-to-] allowed to bypass the firewall. [-Later when the CASP-Midcom signaling messages are exchanged the token is included.-] Host A would then include the received {+authorization+} token {+to the signaling message+} for Network B. When the signaling message arrives at Middlebox 2 then the token is verified by the token-creating entity. [-To avoid-] {+In order to prevent parties from H. Tschofenig et. al. [Page 11] Internet Draft CASP NATFW 3 March 2003+} reusing [-of-] the token [-a timestamp has-] {+timestamps (e.g. token creation, token lifetime, etc.) have+} to be included. Adding IP address information about Host A would create difficulties in relationship with NATs. Information about Host B might be possible to include in order to limit attacks where a token is lost and reused [-to-] {+by+} a different host for a different purpose. The goal is to restrict the [-token. Which information can be safely included inside-] {+usage of+} the token [-might also-] {+for a specific session. The content of the token only needs to+} be [-implementation specified-] {+verified by the originator of the token+} since it only has to be verified locally. [-Some further investigation is required.-] {+Since authorization needs to be linked to the authorized actions which have to be performed on the packets matching the packet filter, the token may include the associated action or a reference to it.+} The following behavior has to be assumed in order for this approach to be applicable: - The exchange of authorization tokens between end-systems must be possible. These protocols must be allowed to pass the firewalls. - An end-system must be able to request such an authorization token at some entity in the local network. [-This approach suffers from-] {+- The hosts need to have each other's addresses, which is complicated to have if there are NATs deployed on the path (especially with double NAT). This approach suffers from+} the following drawback: [-H. Tschofenig et. al. [Page 12] Internet Draft CASP Midcom 23 October 2002-] - An additional protocol is required for an end host to request an authorization token from an entity in the local network as depicted in Section [-9.-] {+10.+} Note that CASP could be extended to provide this functionality but currently it does not. [-3.5-] {+4.5+} Off-Path Signaling The separation [-of-] {+between signaling+} message delivery and [-next-hop-] discovery [-for-] {+within at+} the CASP {+NTLP+} protocol allows it to support in-path and off-path signaling easily with the same protocol. Throughout this document [-in-path-] {+in- path+} signaling was assumed (the Scout protocol is used per-default for next peer discovery) but off-path signaling might be [-required-] {+desired+} in some scenarios where a third-party entity wants to signal some policy rules to a [-firewall.-] {+firewall and NATs.+} This mechanism has disadvantages in larger networks with multiple firewalls since topology information is required {+H. Tschofenig et. al. [Page 12] Internet Draft CASP NATFW 3 March 2003+} in order [-not-] to install policy rules [-at-] {+on+} the [-wrong device. 4-] {+traversed firewalls and NATs. 5+} Assumptions Based on the above-described trust relationships the following protocol assumptions have to be made. [-ú-] {+·+} Middleboxes along the path are CASP-aware. If a middlebox is not CASP-aware then protocol functionality [-can not-] {+cannot+} be fully [-guaranteed.-] {+guaranteed (especially if the middlebox cannot be controlled with the help of some protocol at all).+} The [-CASP-Midcom-] {+CASP-NATFW NSLP+} protocol can operate with limitations if a CASP-unaware firewall blocks all CASP signaling traffic. To support CASP-unaware NATs along the path some information needs to be added to a [-CASP-Midcom-] {+CASP-NATFW+} message to allow the signaling message receiving entity to verify that the source ip address (and port numbers) have changed. Currently no such object is included in this version of the document. [-ú-] {+·+} The end host should not be required to know the topology of the networks along the path or some other network internal issues. Therefore it is not possible to make an assumption about routing and hence we have to assume asymmetric routes. As a consequence end hosts include unidirectional [-Traffic Selectors-] {+packet filters+} only. Within a administrative domain where more information is available this assumption might not hold and the establishment of bi-directional [-Traffic Selectors-] {+packet filters+} could be possible. [-5-] {+6+} NAT Involvement Two issues need to be addressed when NATs are present along the path. Since the end host should not a-priori knowledge about the location, number and types of NATs along the path their presence has to be assumed. [-H. Tschofenig et. al. [Page 13] Internet Draft CASP Midcom 23 October 2002 First-] {+First,+} the CASP signaling messages {+itself+} must be able to traverse a non-CASP aware NAT box without major problems. [-Since-] {+A NAT binding of a non-+} CASP [-uses-] {+aware NAT can be established and maintained much easier with TCP than with UDP. CASP recommends the usage of+} transport protocols such as TCP or SCTP [-a NAT is able to maintain a binding. Note that non-CASP aware NATs prevent the successful installation of packet filters at subsequent CASP-aware firewalls.-] In case that the NAT is CASP-aware problems only occur if source port numbers are fixed. [-So far-] CASP does not require fixed source port numbers to be used. The second issue addresses data packets for which a NAT binding needs to be requested. When an end host starts to transmit scout packets to discover the presence of [-firewalls/NATs-] {+firewalls and NATs+} along the path it is willing to subsequently transmit data packets [-with a given Traffic Selector.-] {+which match the packet filter.+} Subsequently such a [-firewall/nat/firewall-] {+firewall-NAT-firewall+} scenario is described to explain the basic protocol interaction and the usefulness {+for+} allowing [-Traffic Selectors-] {+H. Tschofenig et. al. [Page 13] Internet Draft CASP NATFW 3 March 2003 packet filters+} to change mid-path (i.e. along the path). Mid-session changes of [-Traffic Selectors-] {+packet filters+} happen in mobility cases (for example if the end host obtains a new care-of address). [-In Figure 6 a hosts (Host A) wants to enable transmit data traffic from source IP address 192.168.1.5 to a given destination IP address (not shown in the Figure 6) at port 666 (both udp and tcp). Therefore Host-] {++---------------------------------------------------------------+ | | | Network+} A [-transmits a CASP-Midcom message to-] {+| | | | PF=(192.168.1.5; PF=(139.23.203.30; | | tcp+udp;666) tcp+udp;7000) | | +---------+ +----------+ | +----///------->+ NAT +------///----->++} Firewall {++--> | | |+} 1 [-(after discovering-] {+| | 2 | | | +---------+ +----------+ | | | | +----+-----+ | | | Firewall | | | | 1 | | | +----+-----+ | | ^ | | - PF=(192.168.1.5; | | - tcp+udp;666) | | | | | +--+---+ | | | Host | | | | A | | | +------+ | +---------------------------------------------------------------+ Figure 6: NAT Involvement In Figure 6 a hosts (Host A) wants to enable transmit data traffic from source IP address 192.168.1.5 to a given destination IP address (not shown in the Figure 6) at port 666 (both udp and tcp). Therefore Host A transmits a CASP-NATFW message to Firewall 1 (after discovering+} that this firewall is {+the next CASP supporting node+} along the data path) to create the corresponding packet filters. Note that the traffic selector is unidirectional. This scenario shows a sender-initiated scenario. Firewall 1 installs two policy rules (one for udp and the other one for tcp) after successful authentication and authorization. After forwarding to the next middlebox (a NAT in this case) a NAT binding has to be created for the given traffic selectors. The externally visible [-Traffic Selector-] {+packet filter+} (IP address changed to 139.23.203.30 and port number=7000) is {+H. Tschofenig et. al. [Page 14] Internet Draft CASP NATFW 3 March 2003+} then forwarded to the next firewall (Firewall 2). Firewall 2 again creates policy rules after authentication and authorization. Then the {+signaling+} message is forwarded towards the destination. After the signaling messages reaches [-its target (the-] {+the+} destination IP [-address)-] {+address+} or until no further firewall can be reached (for example because the message is rejected at a non CASP-aware firewall) a RESPONSE message is returned (if requested by the signaling message initiator). A RESPONSE message would contain a Status object which includes information about the applied [-Traffic Selector-] {+packet filter+} and whether the message reached its target or not. In case of NATs along the path the [-Traffic Selector-] {+packet filter+} information is then included in protocols like SIP to communicate on which protocol/port data will be sent. {+In case no RESPONSE message is sent back, the CASP-NATFW aware NFs on the path will return a RESPONSE message with an unsuccessful end to end message delivery error when an associated timer to the existing installed state (relevant to the reception of the CREATE message) expires. The CASP-NATFW NI will receive only one RESPONSE message it may receive more than one in particular cases. It is up to the NI to decide if it has to proceed with the application or not. Every CASP- NATFW on the path will need to filter out the associated RESPONSE, messages to the same original CREATE message, sent by the CASP-NATFW NFs on the upstream. In case a RESPONSE message provides a different filter within the installed policy rule attribute, the RESPONSE message will be forwarded on the downstream towards the CASP-NATFW aware NI.+} Section [-9-] {+10+} additionally addresses some message flows with NAT involvement. [-H. Tschofenig et. al. [Page 14] Internet Draft CASP Midcom 23 October 2002 +---------------------------------------------------------------+ | | | Network A | | | | TS=(192.168.1.5; TS=(139.23.203.30; | | tcp+udp;666) tcp+udp;7000) | | +---------+ +----------+ | +----///------->+ NAT +------///----->+ Firewall +--> | | | 1 | | 2 | | | +---------+ +----------+ | | | | +----+-----+ | | | Firewall | | | | 1 | | | +----+-----+ | | ^ | | - TS=(192.168.1.5; | | - tcp+udp;666) | | | | | +--+---+ | | | Host | | | | A | | | +------+ | +---------------------------------------------------------------+ Figure 6: NAT Involvement 6-] {+7+} Operation [-CASP-Midcom-] {+CASP-NATFW+} defines the following message types: Path: A PATH message allows a receiver-initiated reservation approach. This message does not cause packet filters to be installed although all objects are present. This message is then used as a trigger to cause a CREATE to be returned. The PATH message transmitting entity includes the objects which are later used (if not modified) by the sender of the CREATE message. {+The PATH message allows receiver-initiated signaling to be supported.+} Create: A CREATE message allows to establish or update {+NSLP+} state {+(i.e. policy rules)+} at one or more [-firewall(s).-] {+firewall(s) along the path.+} Verification is necessary to ensure that policy rule creation is allowed by the requesting entity and that no other local security policy is violated. In case a security policy is [-violated or the creation of the policy-] H. Tschofenig et. al. [Page 15] Internet Draft CASP [-Midcom 23 October 2002-] {+NATFW 3 March 2003 violated or the creation of the policy+} rule(s) is not permitted, a RESPONSE message with a "Security Policy Violated" error code is returned. If the CREATE message is used without a previous PATH message then it represents a typical sender-initiated reservation. Release: A RELEASE message is used to delete installed {+NSLP+} state at a [-firewall/NAT explicitly-] {+firewall and to release a NAT binding+} without waiting for a soft-state timeout. This message can only delete previously installed state. Referring to previously installed state can easily be done using the session identifier. {+Only authorized parties are allowed to delete installed state, this includes the creator of the state or other parties trusted by the state creator (useful for fail over of the state creator).+} Response: A RESPONSE message is either sent to acknowledge a previous message or to indicate an error. In case of an acknowledgement it is required that the signaling message initiator requests the transmission of a response message. Therefore the Next [-object-] {+object, discussed in Section 9,+} is set to the Response message. No state information is modified by processing and forwarding an acknowledgement. If an error has to be returned then the error code inside the RESPONSE message allows to specify more detailed error information. Such an error code might for example indicate missing user specific credentials, a missing authorization token or a security policy violation. Detailed error codes have to be defined in future versions of this document. Query: A QUERY message triggers a RESPONSE message to return installed state information. The main purpose of this message is to provide diagnostic facilities. An initiator must only be able to query owned state information. Otherwise the entire set of policy rules of a firewall could be retrieved which causes security concerns. An adversary would have a simple mechanism to retrieve a lot of useful information for subsequent attacks. Trigger: {+The TRIGGER message is an asynchronous event notification sent by a CASP-NATFW aware node. Unlike the CREATE message it does not create or modify NSLP state at nodes between the initiator and the target of the TRIGGER. As a difference to the PATH message also no NTLP routing state is created at nodes between the initator and the target of the TRIGGER.+} Some sort of trigger message is required to support access network signaling message exchanges as described in Section [-9-] {+10+} and in Section [-3.4.-] {+4.4.+} (TBD: This usefulness of this message or other technical alternatives require some investigation.) {+H. Tschofenig et. al. [Page 16] Internet Draft CASP NATFW 3 March 2003+} The following table shows the basic message behavior whereby the following abbreviations are used: MAY (O), MUST NOT (--), MUST (M) or NA [-(not applicable))-] {+(Not Applicable))+} The operations specify which message might indicate information to trigger which other message in response by the other end. Some messages (such as an error message) are created automatically without previous indication. [-H. Tschofenig et. al. [Page 16] Internet Draft CASP Midcom 23 October 2002-] Msg/Next Msg Path Create Release Response Query Trigger ----------------------------------------------------------------- Path NA M -- O -- -- Create O O -- O -- -- Release -- -- O? O M -- Response -- -- -- NA -- -- Query -- -- -- M NA -- Trigger O O O? -- -- NA Note that the "Must" entries in the table above indicate only the default behavior. For example: A PATH message must be followed by a CREATE message. [-However,-] {+However+} in case of an error a RESPONSE message (with an error code) will be returned. The following issues still require some investigations: [---] {+·+} To enable a bi-directional reservation the sender of a CREATE message has to indicate either another CREATE message in the Next object or a PATH message. It is questionable whether a sender- initiated signaling message should follow a receiver-initiated? [---] {+·+} Is it useful to allow a RESPONSE or a RELEASE message to follow a RELEASE message? [-7-] {+8+} Typical Policy Rule Attributes [-Traffic Selectors used in CASP are used to install policy rules in firewalls.-] This paragraph describes some typically used attributes. Other attributes such as flow labels might be used but are considered as an [-exception. We believe that-] {+exception of the packet filter. We believe that+} a granularity at transport layer protocol state-level (syn, syn/ack, ack, etc.) is not [-required. --] {+required for in-path signaling. ·+} Source/destination IPv4 and IPv6 addresses [---] {+·+} Port numbers (possibly including ranges and a list of port numbers) [---] {+H. Tschofenig et. al. [Page 17] Internet Draft CASP NATFW 3 March 2003 ·+} Transport protocol (for example TCP, UDP) [---] {+·+} SPI (for IPSec protected data traffic) [---] {+·+} Identifiers for AH and ESP (Protocol numbers, next headers fields) A NAT object returned to the signaling message initiator contains the same attribute types. The NAT object is included as a payload in the Status object. A signaling message originator may also use the NAT [-H. Tschofenig et. al. [Page 17] Internet Draft CASP Midcom 23 October 2002-] object to request a particular NAT binding to take place. The same object is used for this purpose. There are only two actions defined for a policy rule: "allow / no logging" (default) and "allow / logging". The first action does not require additional objects to be included other than the [-Traffic Selector.-] {+packet filter.+} This is the default action. If a "allow / logging" action has to be specified then the Logging Action [-object-] {+object,+} defined in [-8-] {+9,+} has to be included. This action creates log entries whenever the rule was triggered. End hosts are usually not allowed to specify this behavior because it could be used for a denial of service attack to cause log files to grow quickly and without bounds. Note that a single [-Traffic Selector-] {+packet filter+} might also specify a range or ports. Furthermore it is also possible to specify more than one [-Traffic Selector object-] {+policy rule+} within a single signaling [-message. 8-] {+message (e.g. for off-path signaling). This issue, however, requires further investigation. 9+} Objects The following objects are used by the [-CASP-Midcom-] {+CASP-NATFW+} client protocol: [-8.1-] {+9.1+} Logging Action This object indicates which [-Traffic Selector(s)-] {+packet filter(s)+} want to have logging specified. Note that end host are usually not allowed to specify this behavior for in-path signaling. It [-might, however,-] {+might however+} be requested within the network or in case of off-path signaling. (TBD: Some investigation is required to evaluate whether this action is really required.) [-8.2-] {+9.2+} ApplicationID This object contains an identifier to provide more information about the data for which the policy rule is installed. Application-level firewalls and firewalls with stateful inspection are able to use this information. Providing a wrong application identifier for a given data traffic would then cause a processing failure. Such a behavior is more secure than a traditional packet filter firewall. Note {+however+} that encrypted [-end-to-end-] {+end-to- H. Tschofenig et. al. [Page 18] Internet Draft CASP NATFW 3 March 2003 end+} traffic might reduce this advantage to some degree. A local security policy might indicate that this information is required before creating policy rules. A missing ApplicationID object would then cause a "Application ID require" RESPONSE message with an error code is returned. [-8.3-] {+9.3+} Next The Next object indicates the next request that the signaling message receiver should generate if the incoming message was successfully processed. Section [-6-] {+7+} shows possible combinations of messages. For [-H. Tschofenig et. al. [Page 18] Internet Draft CASP Midcom 23 October 2002-] example, a CREATE message might contain a Next object which is set to CREATE causing another create message to be returned. Such a message flow would represent a bi-directional reservation. A frequently used object is the response object providing indications about a previously submitted message. [-8.4-] {+9.4+} Authorization Token This object is used as described in Figure 5 of Section [-3.4.-] {+4.4.+} More description will be added in the near future (see Section [-11). 8.5-] {+13). 9.5+} CMS Credential Object This object allows user specific cryptographic credentials to be transmitted [-some-] {+to specific+} CASP peers (or networks) along the path. Figure 4 describes a scenario where such an object is required. Attributes included in this object are also briefly mentioned in Section [-3.3. 8.6-] {+4.3. 9.6+} Time This object indicates that filters should be installed somewhere in the near future. This might be required in the context of in-advance QoS reservation for a conferencing scenario. If this object is not present, the current time is used. [-8.7 Version-] {+9.7 Age+} The [-version indication-] {+Age object+} is used to quickly determine whether any of the {+NSLP+} object has changed (for example [-Traffic Selector), without having-] {+packet filter),+} to [-do-] {+avoid+} a bit-by-bit comparison. The [-Version-] {+Age+} object might be useful for messages which refresh established state information only. Uniqueness of the [-Version-] {+Age+} object is only required [-for-] {+only within+} a session. Whenever state information has to be modified then a new value has to be placed in the [-Version-] {+Age+} object. A [-high-resolution-] {+high- resolution+} timestamp is typically used for this purpose. [-8.8-] {+9.8+} Status {+H. Tschofenig et. al. [Page 19] Internet Draft CASP NATFW 3 March 2003+} The Status object is used to deliver status information inside the RESPONSE message. This object might return error notifications or information about installed [-Traffic Selectors-] {+packet filters+} (e.g. NAT-Object). Delivering [-Traffic Selector-] {+packet filter+} information is helpful for application {+(such as SIP, H323, MEGACO, MGCP etc. )+} that need to deliver IP address, protocol type and port information to the initiator in case of NATs along the path. [-One such protocol is SIP. 9-] {+10+} Basic Protocol Behavior [-H. Tschofenig et. al. [Page 19] Internet Draft CASP Midcom 23 October 2002-] The following message flows try to show the basic protocol behavior and possible combinations regarding sender- and receiver-initiated messages flows, [-uni-directional/bi-directional Traffic Selectors,-] {+uni-directional or bi-directional packet filters,+} different trust assumptions and NAT and/or [-Firewall-] {+firewall+} traversal. The subsequently shown figures do not include message flows for next-peer discovery (for example using the Scout protocol). [-9.1-] {+10.1+} Receiver-Initiated Message Flow with Firewalls The following message flow shows the protocol behavior in case of a receiver-initiated signaling message exchange with two administrative domains (Network A and B) and two firewalls located at the borders. For the message flow a peer-to-peer trust relationship is assumed. Cryptographic credentials which support end-to-middle authentication (Host A-to-FW 2) can be included by Host A into the PATH message. The usage of receiver-initiation has the advantage that Host B has to assist in policy rule installation at Firewall B. In Figure 7 the sender indicates {+in the PATH message+} which policy rule to install by adding this information to the [-Traffic Selector.-] {+packet filter.+} Host A uses the IP address 139.23.203.23 and the destination IP address (Host B) is 17.12.23.5. Note that the transport protocol is not mentioned since it is not helpful. The first firewall (FW 1) installs the indicated policy rule [-(Traffic Selector-] {+(packet filter+} with [-actional-] "allow / without [-logging").-] {+logging" action).+} The message is forwarded to the next CASP aware node (FW 2). Because of the peer-to- peer trust assumption FW 2 trusts FW1 for the correctness of the provided parameters. The identity of the signaling message originator might be included in the signaling messages addressed toward the other end host. Policy rules are installed at both firewalls. When the signaling message reaches Host B then a CREATE message is returned in response and [-included-] {+includes+} the same [-Traffic Selector-] {+packet filter+} (unmodified). Note that the [-Traffic Selector-] {+packet filter+} is always directional (especially for the CREATE message in response to a PATH message this is applicable). The CREATE message installs the policy rules at the two firewalls. The CREATE message finally reaches Host A who can immediately start to transmit data traffic towards Host B. [-The following issues arise with the description of the message flow of Figure 7: - Should Traffic Selector information included in the PATH and CREATE message. Traffic Selector information in the PATH message could be temporarily stored at middleboxes (in this firewalls). The CREATE message would then only refer to existing state information.-] H. Tschofenig et. al. [Page 20] Internet Draft CASP [-Midcom 23 October 2002-] {+NATFW 3 March 2003+} +------------------------------+ +-----------------------------+ | +------+ +------+ | | +------+ +--------+ | | |Host A| Network | FW 1 | | | | FW 2 | Network | Host B | | | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | +-+--+-------------------+-----+ +----+-----------------+----+-+ [-|Path(TS=-] {+|Path(PF=+} | | | |(src=139.23.203.23, | | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |--------------------->| | | | [-|Path(TS=-] {+|Path(PF=+} | | | |(src=139.23.203.23,| | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |------------------>| | | | [-|Path(TS=-] {+|Path(PF=+} | | | |(src=139.23.203.23, | | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |--------------------->| | | [-|Create(TS=-] {+|Create(PF=+} | | | |(src=139.23.203.23, | | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |<---------------------| | [-|Create(TS=-] {+|Create(PF=+} | | | |(src=139.23.203.23,| | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |<------------------| | [-|Create(TS=-] {+|Create(PF=+} | | | |(src=139.23.203.23, | | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |<---------------------| | | | Data Traffic (unidirectional) | |================================================================>| Figure 7: Receiver-Initiated Message Flow with Firewalls H. Tschofenig et. al. [Page 21] Internet Draft CASP [-Midcom 23 October 2002 - It does not seem to be useful to have a stateless version-] {+NATFW 3 March 2003 The following issues arise with the description+} of the [-PATH message. Do we want-] {+message flow of Figure 7: · Should packet filter information included in the PATH and CREATE message. packet filter information in the PATH message could be temporarily stored at middleboxes (firewalls in this example). The CREATE message would then only refer to existing state information. · It does not seem to be useful to have a stateless version of the PATH message. Do we want+} to support such a stateless version? [---] {+·+} If the Path message fails then no policy rules are installed. The signaling message flow has to be [-restart.-] {+restarted.+} Figure 7 does not contain NATs, micro-/macro-mobility specific message flows or any form of tunneling. Hence no [-Traffic Selector modification-] mid-path {+packet filter modification+} is [-necessary. Such-] {+necessary, otherwise such+} a [-Traffic Selector-] {+packet filter+} modification would be [-required otherwise. Entities-] {+required. Entities,+} which are aware of micro-/macro-mobility protocols (for example a MAP or a home [-agent)-] {+agent),+} are no middleboxes in the traditional sense. Since they have an impact on the [-Traffic Selector-] {+packet filter+} and on the data traffic it would be necessary to treat them as artificial middlebox to properly address flow identifications along the path. If no such treatment takes place then the wrong policy rules are installed at firewalls with the consequence that the entire protocol interaction is useless. In this description we assume that [-Traffic Selector-] {+packet filter+} attributes are based on information used for routing (i.e. IP addresses). [-9.2-] {+10.2+} Sender-Initiated Message Flow with Firewalls The following message flow shows the protocol behavior in case of a sender-initiated signaling message exchange with two administrative domains (Network A and B) and two firewalls (FW 1 and FW 2). No NAT and other devices requiring modifications to the [-Traffic Selector-] {+packet filter+} are used. This message flow also assumes a peer-to-peer trust relationship. Cryptographic credentials which support end-to-middle authentication (Host A-to-FW 2) can be included by Host A into the CREATE message. The message flow in Figure 8 is similar to Figure 7. The CREATE message contains the [-Traffic Selector-] {+packet filter+} and immediately (after authentication, authorization and verification) causes the installation of policy rules. The signaling message sender might request a RESPONSE message. In case of NATs along the path such a RESPONSE message is very useful to return NAT binding information. This scenario does not require [-Traffic Selector-] {+packet filter+} modification along the path. No NAT binding is returned with the optional RESPONSE message. [-The following issue arises with the description of the message flow of Figure 8: - If a verification error is caused during the CREATE message processing then some firewalls might have installed policy rules whereas others have never seen the signaling message. A RESPONSE message indicating an error could leave installed state in place or cause already established state to be removed automatically.-] H. Tschofenig et. al. [Page 22] Internet Draft CASP [-Midcom 23 October 2002-] {+NATFW 3 March 2003+} +------------------------------+ +-----------------------------+ | +------+ +------+ | | +------+ +--------+ | | |Host A| Network | FW 1 | | | | FW 2 | Network | Host B | | | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | +-+--+-------------------+-----+ +----+-----------------+----+-+ [-|Create(TS=-] {+|Create(PF=+} | | | |(src=139.23.203.23, | | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |--------------------->| | | | [-|Create(TS=-] {+|Create(PF=+} | | | |(src=139.23.203.23,| | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |------------------>| | | | [-|Create(TS=-] {+|Create(PF=+} | | | |(src=139.23.203.23, | | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |--------------------->| | | | [Response] | | | |<---------------------| | | [Response] | | | |<------------------| | | [Response] | | | |<---------------------| | | | Data Traffic (unidirectional) | |================================================================>| Figure 8: Sender-Initiated Message Flow with Firewalls [-9.3-] {+The following issue arises with the description of the message flow of Figure 8: · If a verification error is caused during the CREATE message processing then some firewalls might have installed policy rules whereas others have never seen the signaling message. A RESPONSE message indicating an error could leave installed state in place or cause already established state to be removed automatically. H. Tschofenig et. al. [Page 23] Internet Draft CASP NATFW 3 March 2003 10.3+} Receiver-Initiated Message Flow with a Firewall and a NAT The message flow in Figure 9 introduces a {+middlebox with+} NAT [-box-] {+functionality+} (NAT [-1)-] {+1), in addition to a firewall at Network B,+} along the path between Host A and Host [-B additional to a firewall at Network-] B. Note that NAT 1 might additionally have firewall functionality which would require to install {+pinhole opening and NAT binding+} policy [-rules in addition to to obtain a NAT binding.-] {+rules.+} The message flow assumes that Host A with source IP address 10.1.0.5 wants to transmit data traffic at source port 1200 (for example UDP / not shown in this example) to destination address 17.12.23.5 at destination port number 600. Host A does not requires a particular NAT [-H. Tschofenig et. al. [Page 23] Internet Draft CASP Midcom 23 October 2002 binding.-] {+binding, hence no NAT-Object is required within the initial PATH message. In any case a NAT binding will be included within the NAT-Object returned in the RESPONSE message.+} Instead the provided NAT binding is provided as a NAT-Object in response. If Host A would like to request a particular NAT binding then the [-NAT-Object-] {+NAT- Object+} has to be included in the initial PATH message. As soon as the signaling message reaches NAT 1 a NAT binding is requested and the result of this request is placed into the Traffic selector field (i.e. src ip address is changed from 10.1.0.5 to 139.23.203.30 and the sport is rewritten from 1200 to 5000). When the signaling messages is successfully processed by FW 2 and forwarded to Host B a CREATE message with the indicated [-Traffic Selector-] {+packet filter+} is returned. A copy of the received [-Traffic Selector-] {+packet filter+} is placed into the NAT-Object. By returning the NAT-Object [-information-] {+information,+} Host A is able to learn which IP address and port [-information-] {+, hence no NAT-Object+} is [-seen by Host B. This IP address and port information would then-] {+required within the initial PATH message. In any case a NAT binding will be+} included {+within the NAT- Object returned+} in [-for example a SDP of a SIP-] {+the RESPONSE+} message. The CREATE message is routed backwards toward Host A (since the path is pinned down). The exchange of end-to-end messages after a successful signaling message exchange might be required to exchange parameters about the subsequent data traffic. Finally Host A starts to transmit data packets to Host B. [-9.4-] {+10.4+} Sender-Initiated Message Flow with a Firewall and a NAT Figure 10 shows a sender-initiated signaling message flow whereby FW 2 in Network B initially rejects the signaling message due to an authentication/authorization failure. The returned RESPONSE message includes among the error code, information about the entity creating the error (in this case FW2@NetworkB) and optionally a challenge value. The challenge value allows Host A to either provide a freshness guarantee based on the challenge value and/or based on a timestamp. The usage of CMS allows Host A and Network B to use symmetric and asymmetric credentials for authentication. In any case a Credential object is attached to the CREATE signaling message. The Credential object securely binds a timestamp or a sequence number (to prevent replay [-attacks), identities, lifetime and possibly Traffic Selector information to the cryptographic credentials. Note that the RESPONSE message might return a NAT-Object if requested. Host A retransmits a new signaling message. After verification of the request and the credentials FW 2 forwards the message to Host B. As in previous examples Host B returns a RESPONSE message with a NAT-Object back to Host A. The message flow shows the following protocol features:-] H. Tschofenig et. al. [Page 24] Internet Draft CASP [-Midcom 23 October 2002-] {+NATFW 3 March 2003+} +------------------------------+ +-----------------------------+ | +------+ +------+ | | +------+ +--------+ | | |Host A| Network | NAT 1| | | | FW 2| Network | Host B | | | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | +-+--+-------------------+-----+ +----+-----------------+----+-+ [-|Path(TS=-] {+|Path(PF=+} | | | |(src=10.1.0.5, | | | | dst=17.12.23.5, | | | | sport=1200, [-|Path(TS=-] {+|Path(PF=+} | | | dport=600) |(src=139.23.203.23,| | |--------------------->| dst=17.12.23.5, | | | | sport=5000, [-|Path(TS=-] {+|Path(PF=+} | | | dport=600) |(src=139.23.203.23, | | |------------------>| dst=17.12.23.5, | | | | sport=5000, | | | | dport=600) | | | |--------------------->| | | | | | | [-|Create(TS=-] {+|Create(PF=+} | | | |(src=139.23.203.23, | | [-|Create(TS=-] {+|Create(PF=+} | dst=17.12.23.5, | | |(src=139.23.203.23,| sport=5000, | | | dst=17.12.23.5, | dport=600); | [-|Create(TS=-] {+|Create(PF=+} | sport=5000, | NAT-Object= | |(src=10.1.0.5, | dport=600); |(src=139.23.203.23, | | dst=17.12.23.5, | NAT-Object= | dst=17.12.23.5, | | sport=1200, |(src=139.23.203.23,| sport=5000, | | dport=600); | dst=17.12.23.5, | dport=600)) | | NAT-Object= | sport=5000, |<---------------------| |(src=139.23.203.23, | dport=600)) | | | dst=17.12.23.5, |<------------------| | | sport=5000, | | | | dport=600)) | | | |<---------------------| | | | | | | | For example: SIP Signaling | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | | | | | Data Traffic (unidirectional) | |================================================================>| Figure 9: Receiver-Initiated Message Flow with a Firewall and a NAT [-- End-to-Middle Authentication by including a CMS object-] {+attacks), identities, lifetime and possibly packet filter information to+} H. Tschofenig et. al. [Page 25] Internet Draft CASP [-Midcom 23 October 2002 +------------------------------+ +-----------------------------+ | +------+ +------+ | | +------+ +--------+ | | |Host A| Network |-] {+NATFW 3 March 2003 the cryptographic credentials. The RESPONSE message might return a NAT- Object if a+} NAT [-1| | | | FW 2| Network |-] {+was present along the path.+} Host [-B | | | +--+---+-] A [-+--+---+ | | +--+---+ B +---+----+ | +-+--+-------------------+-----+ +----+-----------------+----+-+ |Create(TS= | | | |(src=10.1.0.5, |Create(TS= | | | dst=17.12.23.5, |(src=139.23.203.23,| | | sport=1200, | dst=17.12.23.5, | | | dport=600) | sport=5000, | | |--------------------->| dport=600) | | | |------------------>| | | |Response(ErrorCode=| | |Response(ErrorCode= |"Auth. Required", | | |"Auth. Required", | FW2@NetworkB, | | | FW2@NetworkB, | challenge=0x7a..8,| | | challenge=0x7a..8, |<------------------| | |<---------------------| | | |Create(TS= | | | |(src=10.1.0.5, | | | | dst=17.12.23.5, |Create(TS= | | | sport=1200, |(src=139.23.203.23,| | | dport=600) | dst=17.12.23.5, |Create(TS= | | Credentials(...)) | sport=5000, |(src=10.1.0.5, | |--------------------->| dport=600) | dst=17.12.23.5, | | | Credentials(...)) | sport=1200, | | |------------------>| dport=600) | | | |--------------------->| | | | Response( | | | Response( | NAT-Object(...)) | | Response( | NAT-Object(...)) |<---------------------| | NAT-Object(...)) |<------------------| | |<---------------------| | | | | SIP Signaling | | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | | | | | Data Traffic (unidirectional) | |================================================================>| Figure 10: Sender-Initiated Message Flow with-] {+retransmits+} a [-Firewall-] {+new signaling message. After verification of the request+} and {+the credentials FW 2 forwards the message to Host B. As in previous examples Host B returns+} a [-NAT-] {+RESPONSE message with a NAT-Object back to Host A. The message flow shows the following protocol features: · End-to-Middle Authentication by including a CMS object+} (Credential object) to the signaling message after the authentication/authorization failure. If the Credential object is included into the first CREATE signaling message then no such [-H. Tschofenig et. al. [Page 26] Internet Draft CASP Midcom 23 October 2002-] error message is returned. [-However,-] {+However+} in that case replay protection can only be based on timestamps (loosely synchronized clocks). [---] {+·+} A NAT-Object is included in the RESPONSE message [-to let the signaling message initiator to return-] {+which provides information about+} the [-public IP address. --] {+NAT binding. ·+} The RESPONSE message indicating an error could also return a NAT- Object to provide initial information [-to-] {+about+} the [---] {+existence of a NAT. ·+} The same protocol operations can be used without NATs (only firewalls). [-9.5-] {+10.5+} Sender-Initiated NAT/Firewall Traversal with Authorization Token The next scenario is slightly more complicated in the sense that authorization information for Network B is provided by Host B. Host B first request an authorization token from an entity in the local network by some means. This token is then communicated to Host A using an end- to-end protocol such as SIP or HTTP. This token then provides the necessary trust for Network B to allow the CREATE message to install policy rules at FW 2. Note that this message flow is different compared to the scenario described in Figure 10. In this case no pre-established cryptographic credentials between Host A and Network B are present before the protocol is used between Host A and Host B. The sender-initiated message flow is similar to the above-described flows with the only exception that the Authorization Token is included. The token is removed at FW 2 after successful verification. [-9.6-] {+10.6+} Sender-Initiated Firewall Signaling only at the Access Network [-Sometimes people argue that the signaling message exchange should be done locally at the network access only because per-flow signaling messages are not processed in the core network. Instead of sending the signaling messages from one access network to the other whereby the signaling messages are transparent in the core each host transmits signaling messages independently in its own network. Although the concept sounds very simple at the first glance it turns out to be very complex in the generic case. Most difficulties appear because of the asymmetric routing architecture. Establishing policy rules in the uplink direction is fairly simple and requires only a mechanism which allows some sort of scoping (i.e. signaling messages have to terminate somewhere in the access network) without actually indicating the end- point. Casp provides means for scoping and local access network signaling. The installation of policy rules on the downlink direction is complicated because some topology information inside the network must be known in order to avoid policy rule creation at the-] H. Tschofenig et. al. [Page [-27]-] {+26]+} Internet Draft CASP [-Midcom 23 October 2002-] {+NATFW 3 March 2003+} +------------------------------+ +-----------------------------+ | +------+ +------+ | | +------+ +--------+ | | |Host A| Network | NAT 1| | | | FW 2| Network | Host B | | | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | +-+--+-------------------+-----+ +----+-----------------+----+-+ {+|Create(PF=+} | | | [-Authorization-] {+|(src=10.1.0.5, |Create(PF= |+} | | {+dst=17.12.23.5, |(src=139.23.203.23,|+} | | [-Token-] {+sport=1200,+} | {+dst=17.12.23.5,+} | | | [-Request-] {+dport=600)+} | {+sport=5000,+} | | [-|<---------------------|-] {+|--------------------->| dport=600)+} | | | [-Authorization-] {+|------------------>|+} | | {+|Response(ErrorCode=|+} | [-End-to-End-] {+|Response(ErrorCode= |"Auth. Required",+} | [-Token-] | {+|"Auth. Required",+} | {+FW2@NetworkB,+} | [-Communication-] | [-Response-] | {+FW2@NetworkB,+} | {+challenge=0x7a..8,|+} | [-(Authorization |--------------------->|-] | {+challenge=0x7a..8, |<------------------|+} | [-Token)-] {+|<---------------------|+} | | [-|<----------------------------------------------------------------| |Create(TS=-] {+|Create(PF=+} | | | |(src=10.1.0.5, | | | | dst=17.12.23.5, [-|Create(TS=-] {+|Create(PF=+} | | | sport=1200, |(src=139.23.203.23,| | | [-dport=600); Token)-] {+dport=600)+} | dst=17.12.23.5, [-|Create(TS=-] {+|Create(PF= | | Credentials(...))+} | [-|--------------------->|-] sport=5000, |(src=10.1.0.5, | {+|--------------------->| dport=600)+} | [-| dport=600); Token)|-] dst=17.12.23.5, | | [-|------------------>| sport=1200,-] | {+Credentials(...))+} | {+sport=1200,+} | | {+|------------------>|+} dport=600) | | | |--------------------->| | | | Response( | | | [-| NAT-Object(...)) | | |-] Response( [-|<---------------------| |-] | NAT-Object(...)) | | [-|-] Response( [-|<------------------| |-] | NAT-Object(...)) {+|<---------------------|+} | [-|-] {+NAT-Object(...)) |<------------------|+} | |<---------------------| | | | | SIP Signaling | | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | | | | | Data Traffic (unidirectional) | |================================================================>| Figure [-11:-] {+10:+} Sender-Initiated [-NAT/Firewall Traversal-] {+Message Flow+} with [-Authorization Token wrong devices. Hence there is-] a [-built-in risk to cause-] {+Firewall and a NAT Sometimes people argue that+} the [-protocol to fail (i.e. to install policy rules-] {+signaling message exchange should be done locally+} at the [-wrong location). H. Tschofenig-] {+network access only because per-flow signaling messages are not processed in the core network. Instead of sending the H. Tschofenig+} et. al. [Page [-28]-] {+27]+} Internet Draft CASP [-Midcom 23 October 2002 For the message flow described in Figure 12 we assume the following protocol behavior: --] {+NATFW 3 March 2003 +------------------------------+ +-----------------------------+ | +------+ +------+ | | +------+ +--------+ | | |Host A| Network | NAT 1| | | | FW 2| Network |+} Host {+B | | | +--+---++} A [-and Host-] {++--+---+ | | +--+---++} B [-initiate a bi-directional-] {++---+----+ | +-+--+-------------------+-----+ +----+-----------------+----+-+ | | | Authorization | | | | Token | | | | Request | | | |<---------------------| | | | Authorization | | | End-to-End | Token | | | Communication | Response | | | (Authorization |--------------------->| | | Token) | | |<----------------------------------------------------------------| |Create(PF= | | | |(src=10.1.0.5, | | | | dst=17.12.23.5, |Create(PF= | | | sport=1200, |(src=139.23.203.23,| | | dport=600); Token) | dst=17.12.23.5, |Create(PF= | |--------------------->| sport=5000, |(src=10.1.0.5, | | | dport=600); Token)| dst=17.12.23.5, | | |------------------>| sport=1200, | | | | dport=600) | | | |--------------------->| | | | Response( | | | | NAT-Object(...)) | | | Response( |<---------------------| | | NAT-Object(...)) | | | Response( |<------------------| | | NAT-Object(...)) | | | |<---------------------| | | | | SIP Signaling | | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | | | | | Data+} Traffic [-Selector establishment-] {+(unidirectional) | |================================================================>| Figure 11: Sender-Initiated NAT/Firewall Traversal+} with [-a scope restricted to the local-] {+Authorization Token signaling messages from one+} access network [-only. Without some sort of bi-directional signaling message exchange a sort of TRIGGER message is required-] to [-initiate a downlink Traffic Selection-] {+the other whereby the signaling messages are transparent in the core each host transmits signaling messages independently in its own network. Although the H. Tschofenig et. al. [Page 28] Internet Draft CASP NATFW 3 March 2003 concept sounds very simple at the first glance it turns out to be very complex in the generic case. Most difficulties appear because of the asymmetric routing architecture. Establishing policy rules in the uplink direction is fairly simple and requires only a mechanism which allows some sort of scoping (i.e. signaling messages have to terminate somewhere in the access network) without actually indicating the end- point. Casp provides means for scoping and local access network signaling. However the installation of policy rules on the downlink direction is complicated because some topology information inside the network must be known in order to avoid policy rule creation at the wrong devices. Hence there is a built-in risk to cause the protocol to fail (i.e. to install policy rules at the wrong location). For the message flow described in Figure 12 we assume the following protocol behavior: · Host A and Host B initiate a bi-directional packet filter establishment with a scope restricted to the local access network only. Without some sort of bi-directional signaling message exchange, a TRIGGER message is required to initiate a downlink Traffic Selection+} establishment. [---] {+·+} Based on the characteristics of {+local+} signaling message exchanges [-local-] at both access [-networks-] {+networks,+} assumptions about the topology must be made (or some topology information must be known). [---] {+·+} In this simplified message flow no NAT device is present. [---] {+·+} Host A has a-priori knowledge about the [-Traffic Selector-] {+packet filter+} for the inbound traffic (i.e. src=17.12.23.5 and sport=601). With the initial CREATE message Host A already supplies [-Traffic Selector-] {+packet filter+} information for the bi-directional reservation (i.e. the CREATE message by Host A is followed by another CREATE message from FW 1). To kept the CREATE signaling message within the local access network scoping is used. Indicating a particular IP address might also be possible but often the endpoint is unknown to the end host. As a result of successful processing a CREATE message is returned in response with the already provided [-Traffic Selector.-] {+packet filter.+} Optionally an end-to-end message communication might follow to transmit [-Traffic Selector-] {+packet filter+} information from Host A to Host B. In most cases some communication [-is, however,-] {+is however+} required. Similar as in Network A a CREATE message is initiated by the end host with the Next object set to another CREATE message. [-Finally if everything was successful data can be exchanged in both directions on port 5001<-601 and a 5000->600. 9.7 Sender-Initiated NAT and Firewall Traversal within the Access Network The message flow described in Figure 13 extends the description in Figure 12 by using a uni-directional signaling exchange. As a consequence of this extension a TRIGGER message is required to cause a downlink signaling message to be sent within Network B. In order to avoid this message Network B could intercept the end-to-end message exchange to trigger a signaling message to Host B. However, this approach might suffer from the problem to be able to read and evaluate end-to-end signaling messages.-] H. Tschofenig et. al. [Page 29] Internet Draft CASP [-Midcom 23 October 2002-] {+NATFW 3 March 2003+} +------------------------------+ +-----------------------------+ | +------+ +------+ | | +------+ +--------+ | | |Host A| Network | FW 1 | | | | FW 2 | Network | Host B | | | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | +-+--+-------------------+-----+ +----+-----------------+----+-+ [-|Create(TS=(src=139.23.205.5,-] {+|Create(PF=(src=139.23.205.5,+} | | | dst=17.12.23.5, sport=5000, dport=600); | | | [-Next=Create(TS=(src=17.12.23.5,-] {+Next=Create(PF=(src=17.12.23.5,+} | | | dst=139.23.205.5,sport=601,dport=5001)); | | | Scope=NetworkA) | | | |--------------------->| | | [-|Create(TS=-] {+|Create(PF=+} | | | |(src=17.12.23.5, | | | | dst=139.23.205.5, | | | | sport=601, | | | | dport=5001)) | | | |<---------------------| | | | | End-to-End | | | | Communication | | | | [-(TS)-] {+(PF)+} - Optional | | |<--------------------------------------------------------------->| | [-|Create(TS=(src=17.12.23.5,-] {+|Create(PF=(src=17.12.23.5,+} | | | dst=139.23.205.5, sport=601, dport=5001);| | | [-Next=Create(TS=(src=139.23.205.5,-] {+Next=Create(PF=(src=139.23.205.5,+} | | | dst=17.12.23.5, sport=5000, dport=600)); | | | Scope=NetworkB) | | | | |<---------------------| | | [-|Create(TS=-] {+|Create(PF=+} | | | |(src=139.23.205.5, | | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600)) | | | |--------------------->| | Data Traffic (bi-directional) | |<===============================================================>| Figure 12: Sender-Initiated Firewall Signaling only at the Access Network [-Additionally-] {+Finally if everything was successful data can be exchanged in both directions on port 5001<-601 and a 5000->600. 10.7 Sender-Initiated NAT and Firewall Traversal within the Access Network H. Tschofenig et. al. [Page 30] Internet Draft CASP NATFW 3 March 2003 The message flow described in Figure 13 extends the description in Figure 12 by using a uni-directional signaling exchange. As a consequence of this extension a TRIGGER message is required to cause a downlink signaling message to be sent within Network B. In order to avoid this message Network B could intercept the end-to-end message exchange to trigger a signaling message to Host B. However this approach might suffer from the problem to be able to read and evaluate end-to-end signaling messages. In addition,+} a NAT device is used in Network A which requires Host A to request a NAT binding and the corresponding NAT-Object which is then communicated to Host B. Using the [-Traffic Selector-] {+packet filter+} information inside the NAT-Object Host B learns the public IP address and port information of the data traffic transmitted by Host A. [-H. Tschofenig et. al. [Page 30] Internet Draft CASP Midcom 23 October 2002-] The access network signaling message exchange requires some topology information as explained in previous figures. The TRIGGER message must cause a downlink signaling message to be initiated by a network device which where the data traffic of Host A is sent through. {+This particular issue will be explained in more detail in a future version of the document.+} A even more difficult example would address a topology where each network is equipped with a NAT. The same is true for [-Traffic Selector-] {+packet filter+} installation for data traffic flowing in both directions with one or two NATs. [-10-] {+11+} Security Considerations Installing packet filters to one or more firewalls is a security sensitive process. Security protection of signaling messages is necessary in order to defeat a number of threats. This section gives a brief discussion of possible threats and addresses their corresponding countermeasures. [-10.1-] {+11.1+} Threats Denial of Service: Denial of service attacks can be launched by modifying messages used during the discovery process. A client could then be forced to contact a "wrong" firewall which is outside the data path. Furthermore it is possible to flood a firewall with bogus request and thereby cause massive state and computational resources to be allocated as part of the key exchange process. Furthermore an adversary can modify the [-Traffic Selector-] {+packet filter+} of a request to cause a large number of packet filters to be allocated. An adversary might also remove administrator installed packet filters which are not related [-to previous packet filter installations by users. Man-in-the-Middle: MITM attacks are possible during the discovery process where the entity of a firewall is discovered. In this case the user might be convinced to communicate with a firewall which is not the case. Many of these attacks are related to the discovery mechanism and therefore also described in [1]. Further threats which are not specific to the scout mechanism but also related to the next-hop discovery mechanism require further investigation (such as SLP, DHCP, DNS, etc.). The authors of some of these configuration mechanisms have already identified potential vulnerabilities and provide the corresponding security protection. Eavesdropping: An eavesdropper might be able to learn some installed packet filters by listening to the signaling message communication between a client and a firewall. Furthermore it-] H. Tschofenig et. al. [Page 31] Internet Draft CASP [-Midcom 23 October 2002-] {+NATFW 3 March 2003+} +------------------------------+ +-----------------------------+ | +------+ +------+ | | +------+ +--------+ | | |Host A| Network | NAT 1| | | | FW 2 | Network | Host B | | | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | +-+--+-------------------+-----+ +----+-----------------+----+-+ [-|Create(TS=-] {+|Create(PF=+} | | | |(src=192.168.1.5, | | | | dst=17.12.23.5, | | | | sport=5000, | | | | dport=600); | | | | Scope=NetworkA) | | | |--------------------->| | | |Response( | | | |NAT-Object= | | | |(src=139.23.203.30, | | | | dst=17.12.23.5, | | | | sport=8000, | | | | dport=600)) | End-to-End | | |<---------------------| Communication | | | | (NAT-Object) | | |<--------------------------------------------------------------->| | | [-|Trigger(TS=-] {+|Trigger(PF=+} | | | |(src=139.23.205.30, | | | | dst=17.12.23.5, | | | | sport=8000, | | | | dport=600); | | | | Scope=NetworkB) | | | |<---------------------| | | [-|Create(TS=-] {+|Create(PF=+} | | | |(src=139.23.205.30, | | | | dst=17.12.23.5, | | | | sport=8000, | | | | dport=600)) | | | |--------------------->| | Data Traffic (uni-directional) | |================================================================>| Figure 13: Sender-Initiated NAT and Firewall Traversal within the [-Access Network might-] {+Access Network to previous packet filter installations by users. Man-in-the-Middle: MITM attacks are possible during the discovery process where the entity of a firewall is discovered. In this H. Tschofenig et. al. [Page 32] Internet Draft CASP NATFW 3 March 2003 case the user might be convinced to communicate with a firewall which is not the case. Many of these attacks are related to the discovery mechanism and therefore also described in [1]. Further threats which are not specific to the scout mechanism but also related to the next-hop discovery mechanism require further investigation (such as SLP, DHCP, DNS, etc.). The authors of some of these configuration mechanisms have already identified potential vulnerabilities and provide the corresponding security protection. Eavesdropping: An eavesdropper might be able to learn some installed packet filters by listening to the signaling message communication between a client and a firewall. Furthermore it might be possible to learn an exchanged authorization tokens between the two entities or between entities along the path. Since the session identifier is used to uniquely identify state established along entities along the path an adversary might reuse this identifier to refer to existing state information. Integrity Violation: By modifying a request message, an adversary can delete installed firewall filters, install filters using a different authorization identity or to create filters with a large lifetime. Masquerading: An adversary might gain information by querying installed packet filters at a firewall by masquerading the identify of a real user. This might be used for subsequent attacks. Rogue Firewall: An adversary at a compromised firewall might exploit an existing trust relationship to install or remove filters at other firewalls. Furthermore it is possible to return a NAT object with wrong information causing subsequent data traffic to be send to an arbitrary location. Unauthorized Access: A regular user might install firewall filters although he is not allowed because of missing authorization. Administrators are usually very concerned about installing packet filters from users access from an external network. Replay Attacks: An adversary might eavesdrop CASP-NATFW signaling messages and use them later for a replay attack. Furthermore an adversary might be able to collect authorization tokens and reuse them in a different context or later in time to open holes into a firewall. H. Tschofenig et. al. [Page 33] Internet Draft CASP NATFW 3 March 2003 Privacy Violation: Adversaries can learn about the NI and NR's identities participating in the message exchange by eavesdropping information exchanged between the two end- systems. Especially authorization tokens exchanged between end-systems outside the CASP protocol (as explained in Section 4.4) represent a vulnerability. 11.2 Countermeasures To prevent the above-listed attacks a number of countermeasures are taken: Denial of Service: To limit denial of service attacks a number of countermeasure were taken. First the scout protocol (and other configuration mechanisms) experience some protection to prevent basic attacks. Furthermore it is necessary to mutually authenticate and authorize both peers after establishing a transport layer connection as described in [1]. Since the authentication and key exchange protocol requires state and computational resources it has to+} be [-possible-] {+resistant against denial of service attacks. When transmitting CASP-NATFW specific information protection of the requests itself is necessary+} to [-learn-] {+prevent an adversary from object modification which otherwise would cause unpredictable behavior. Man-in-the-Middle: MITM attacks during the discovery phase are prevented by secure configuration mechanisms. The scout protocol experiences limited security protection by its nature. However+} an {+authentication and+} authorization [-token exchanged between-] {+step is required after learning+} the [-two entities or between entities along-] {+identity of+} the [-path. Since-] {+next CASP peer. MITM adversaries will experience difficulties launching a successful attack after transport layer connection establishment because of+} the [-session identifier-] {+signaling message protection. Eavesdropping: Eavesdropping of signaling messages+} is [-used-] {+prevented by using either IPSec ESP (without NULL encryption) or by using TLS (with encryption cipher-suites). It is therefore not possible+} to [-uniquely identify state establish along entities along the path-] {+learn authorization tokens, session identifiers or other firewall packet filter specific information that might be useful for+} an adversary {+eavesdropping on for example a wireless link. With the suggested security protection eavesdropping is therefore only possible at CASP-NATFW aware nodes participating in the signaling message exchange. This is, however, intentional and required for the operation of the protocol. Integrity Violation: Modifying the content of signaling packets is prevented by either IPSec or TLS. Exchanged information+} H. Tschofenig et. al. [Page [-32]-] {+34]+} Internet Draft CASP [-Midcom 23 October 2002 might reuse this identifier-] {+NATFW 3 March 2003 thereby experiences both confidentiality as well as integrity protection. The usage of integrity protection with IPSec ESP is strongly recommended. Masquerading: Spoofing an identity+} to [-refer-] {+be able+} to [-existing state information. Integrity Violation: By modifying a request message an adversary can-] delete [-installed firewall filters, install filters using a different authorization identity-] or [-to create filters with a large lifetime. Masquerading: An adversary might gain information by querying-] {+query+} installed packet [-filters at a firewall-] {+filter information is prevented+} by [-masquerading-] {+authentication of+} the [-identify or a real user. This might be used for subsequent attacks.-] {+originator (i.e. data origin authentication) of transmitted signaling messages. For the establishment of the required security associations mutual authentication is assumed.+} Rogue [-Firewall:-] {+CASP-NATFW Node: Firewalls are security sensitive network devices.+} An adversary [-at-] {+can use a compromised firewall in a number of ways. To prevent+} a compromised firewall [-might exploit an existing trust relationship-] to [-install or remove filters at-] {+harm+} other [-firewalls. Furthermore it-] {+firewalls, trust might be limited and strong verification of request migh